Windows objects, handles, and MFC objects
(22:11:34)
Reprinted
Tags:Windows objects Handle MFC object Miscellaneous |
Classification: MFC and Windows Programming |
Windows objects are identified by handles. The corresponding MFC class is the c ++ packaging of these handles. Windows objects in the memory must be identified by a unique handle, but not necessarily the corresponding MFC class objects in the memory. When you need to obtain the corresponding MFC class object of a Windows Object and the object does not exist in the memory, the system creates a temporary MFC class object and returns it to the user, and recycles it at a certain idle time. The following table lists Windows Object handles and their corresponding MFC classes:
Hwnd |
Cwnd and derived classes |
HDC |
CDC and derived classes |
Hmenu |
Cmenu |
Hpen, hbrush, hfont, hbitmap, hpalette, hrgn |
Cgdiobject |
Himagelist |
Cimagelist |
Socket |
Csocket |
If you have any of the preceding Windows Object handles, you can call the fromhandle function of the corresponding class to find the corresponding MFC object (the system maintains a Windows ing from the Windows Object handle to the MFC object for each thread, A persistent map and a temporary map). If you have the above MFC object, you can also obtain the corresponding windows object handle through the Public member variable of the MFC class. For example, if you specify an hwnd handle, you can use
Cwnd: fromhandle (hwnd ); |
To obtain the pointer to the cwnd object. If hwnd does not have a corresponding cwnd object, the system generates a temporary cwnd object associated with hwnd and returns a pointer to this object. After obtaining the cwnd object, you can use the public member m_hwnd of cwnd to obtain the handle of the window object.
If a temporary MFC object is generated when fromhandle is called, The ing between the handle and the MFC object is saved in the temporary map of the system. By default, cwinthread: onidle automatically calls the deletetempmap function for the MFC classes that support temporary handle ing. In the deletetempmap function, these temporary objects are disassociated with the handle and then destroyed. If you have a Windows Object handle, you can create a corresponding MFC object and associate the MFC object with the Windows Object handle. In this case, the MFC object establishes a ing relationship with the Windows Object. For example, for the following code:
Cwnd mywnd; Mywnd. Attach (hwnd ); |
Creates a hwing from hwnd to mywnd. After that, you call cwnd: fromhandle (hwnd) to return the pointer of the mywnd object. If the mywnd object is destroyed, its destructor will automatically destroy the Windows Object indicated by this hwnd by calling destroywindow. If this behavior is not expected, call the detach member function before mywnd is destroyed to remove the Association (ing) between the two, such as mywnd. Detach (). All temporary MFC objects and permanent MFC objects are maintained and managed in thread units. That is to say, one thread cannot access the MFC packaging class object of another thread, whether it is temporary or persistent. To pass these windows objects between different threads, they should always be passed through the handle type. Passing an MFC wrapped object from one thread to another may cause unexpected results. Because the MFC packaging class objects are managed by threads, multiple MFC objects may correspond to the same handle in different threads of the program. If the same thread has multiple MFC objects attach the same handle, which MFC object will be returned when fromhandle is called for the handle? Undefined behavior?