Assertion failed on Webpad

[strategygameaddict]

I posted this in Handhelds, but really it belongs here:

We are running MFC on WINCE 4.1, and we keep seeing an assertion dialog that pops up from Wincore.cpp saying that the Windows handler is not found in the map. I included another dialog as the parent of this dialog as an attempt to resolve this issue, and now wce_FirstDlgProc hangs when it tries to send a message in the CWnd::CenterWindow method, because the hWndCenter that returns from ::GetWindow(m_hWnd, GW_OWNER) is a non null value, causing it to satisfy the condition that allows it to reach the code that invokes (HWND)::SendMessage. This prevents the thread from executing RunModalLoop in dlgcore.cpp.

The system never pops up this dialog when running in production mode, because only the webpad environment handles the ASSERT macro, but I have been tasked to resolve this issue on webpad, nonetheless. I thought that by adding a parameter to the constructor of this CDialog subclass that would specify the instance of the other CDialog subclass as the parent, it would resolve this ASSERT problem, because the PumpMessages method invoked by RunModalLoop was not finding a parent for this window, and was grabbing a global handle, which in turn was not located in it's map. The ASSERT macro is never reached as a result of the system hang, so I really cannot tell if this has even resolved the problem, although it appeared to do so at first. The dialog sets a timer, and this attempt to fix one problem has resulted in the dialog not handling the WM_TIMER messages.

If assigning the other Dialog subclass is not the answer to resolve this ASSERT macro failure, I really do not know what is. I have a feeling that I need to modify something in the .rc file to get this to work. I tried adding WS_CHILD to the Style of the Dialog IDD tag, but that didn't accomplish anything.

Thanks,
Dan

 

[strategygameaddict]

A bit of an update...I skipped past the ::SendMessage and still ran into the ASSERT macro failure. I also discovered that the Handle for the parent retrieved is actually automatically assigned as the handle for the Dialog that I was trying to set as the parent parameter, regardless of whether I pass this dialog in as the parent to the super constructor for CDialog. Because this dialog never gets attached to the presumptive parent, it does not find the handle for this dialog in the parent dialog's permanent map, which triggers the failure of the ASSERT macro.

This child dialog is running in a separate thread, so it correctly identifies the thread's main window, which happens to be the dialog that spawned the thread, as the parent. Hope this helps...