C / C++ / MFC

class Derived: virtual public Base
{
...
};

#include <stdio.h>

class A
{
public:
	void abc()
	{
		printf("hello world");
	}
};




int main(int argc, char* argv[])
{
	void (A::*pf)()=&A::abc;
	A a;
	(a.*pf)();
	return 0;
}

A CWnd is really two distinct entities: a C++ object which you access using a CWnd* (typically this), and the Window object created by the system, which you access using a window hande (HWND). In order for MFC to make these two separate entities work like one, it must frequently find the HWND associated with a particular CWnd object, and or find the CWnd object associated with a particular HWND.

The first operation, mapping from CWnd to the associated HWND is easy (just look up the m_hWnd member variable). This works fine in any thread.

The second mapping, from HWND to CWnd* uses what is know as a handle map (a table which tracks which HWNDs were created by CWnd objets in that thread). This handle map is thread specific. Furthermore, since you can create HWNDs without even creating a CWnd object (e.g. dialog controls created by the dialog template), MFC sometimes creates generic temporary CWnd objects which you can use for the duration of a message handler to access these HWNDs via a CWnd object.

The GetParent() member function just calls the Windows API funtion ::GetParent (m_hWnd), which returns the HWND of the parent. MFC then uses the (thread specific) handle maps to get a CWnd object associated with the parent HWND. If the parent window was not created via a CWnd object in the same thread, this will a temporary generic CWnd object. So in your case, when the second thread calls GetParent() it gets a pointer to a temporary generic CWnd and NOT the CMyCWndDerivedClass object that created the parent HWND in the first thread. If you cast the CWnd pointer to a pointer your derived class, you'll acess whatever memory just happens to sit after the temporary CWnd object.

You can confirm this with

CWmd *pWnd = GetParent ();
ASSERT_KINDOF (CMyCWndDerivedClass, pWnd);

When working with multiple threads, it is much simpler to have only the original main thread responsible for the GUI. Worker threads can update data, and then use ::PostMessage() with an HWND to send a message the main thread (that created the HWND) that it should update its appearance. Since all windows messages are handled by the single GUI thread that creates all HWNDs, the handle maps work just as expected in a single threaded application. It you let multiple threads deal with HWNDs and CWnd objects directly, then you need to understand temporary and permanent handle maps AND when and how they are used by MFC. Believe me, the first approach is much simpler.


Stephen C. Steel
Kerr Vayne Systems Ltd.