strategygameaddict
Programmer
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
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