In-depth analysis of the relationship between the MFC-handle and the object

In-depth analysis of MFC-Relationship between handles and objects
In Windows, many objects are presented to developers in the form of handles. For example, the window handle (hwnd) and the drawing device (HDC. Then, most API functions focus on these handles. Such as showwindow, setwindowtext, and textout. The first parameter of these API functions is usually the handle. However, in the C ++ system, such access to details of things often violates the encapsulation spirit. Therefore, MFC has made a lot of encapsulation classes to hide these details. Such as cwnd and CDC. Through these class exposure methods, you can directly operate the handle without caring about it.
However, today's topic is not here. The following is the real content.
According to the C ++ theory, the creation and destruction of encapsulated handles should be completed by the class itself, and the outside world does not understand the details. But in MFC, is that true? At least this is not the case with cwnd. hwnd is not completely under the control of cwnd. As I mentioned in the previous chapter, MFC has a large number of global variables, one of which is a map table of hwnd and cwnd. The location of this map table is hard to find. The Global Object afx_module_state is mentioned in the previous chapter. One of its members is afx_module_thread_state. Inside afx_module_thread_state, there is a group of map tables, m_pmaphwnd is one of them:
Chandlemap m_pmaphwnd;
Chandlemap * m_pmaphmenu;
Chandlemap * m_pmaphdc;
Chandlemap * m_pmaphgdiobj;
Chandlemap * m_pmaphimagelist;
Have you seen it? It is difficult to find out, but MFC provides the global function afxmaphwnd, which can be easily obtained by calling this function wherever it is.
So what is the role of this table? In fact, it is very simple, although in MFC, all objects are dealing with objects. However, MFC also needs to deal with Windows systems. Windows only gives you a handle. How can we find the corresponding class through these handles? You can easily solve this problem by using the map table.
For example, in Windows message mechanism, when wndproc receives a message, it will only get a target window of hwnd. How can we find a matching class? Search from m_pmaphwnd. By calling the static member function fromhandlepermanent of cwnd, we can easily find the cwnd class corresponding to hwnd from the map table.
The implementation of fromhandlepermanent is also very simple. First, find m_pmaphwnd through afxmaphwnd, then find the cwnd pointer corresponding to hwnd through the member function lookuppermanent of m_pmaphwnd, and finally return it.
When was m_pmaphwnd created? When the first window is created, the attach function of cwnd is called. The following shows the specific function implementation:
Bool cwnd: attach (hwnd hwndnew)
{
If (hwndnew = NULL) return false;
Chandlemap * pmap = afxmaphwnd (true); // create map if not exist
Pmap-> setpermanent (m_hwnd = hwndnew, this );
Return true;
}
Note that the input parameter afxmaphwnd is called to be true, which means that when map does not exist, it is created. Let's take a look at the implementation of afxmaphwnd:
Chandlemap * Pascal afxmaphwnd (bool bcreate)
{
Afx_module_thread_state * pstate = afxgetmodulethreadstate ();
If (pstate-> m_pmaphwnd = NULL & bcreate)
{
Pstate-> m_pmaphwnd = new chandlemap (runtime_class (cwnd ),
Constructdestruct <cwnd>: Construct, constructdestruct <cwnd>: destruct,
Offsetof (cwnd, m_hwnd ));
}
Return pstate-> m_pmaphwnd;
}
Afxmaphwnd first finds this pointer from the point we mentioned above. If the pointer is null and bcreate is true, a new chandlemap is created. It's very simple, isn't it?