Forum

Hello

I am using V2.54 of ProfUis.

My application can be used as an embedded application in Internet Explorer. The communication between the OLE Container (IE) and the OLE server (my app) seems to work a little differently from the "normal" scenario.

The following image (please remove "removeme" from the URL) shows my scenario:

http://download.ierax.removeme.ch/focusproblem.jpg#@lt;/p>

The red circle shows a button that opens a menu. The green circle shows a combo box.

When you open the menu and click into the caption of the Internet Explorer the menu remains open. If you drop down the combo box and you click into the caption of the Internet Explorer the combo box closes.

I could live with that but if you close the Internet Explorer by pressing the "X" box while the red circled menu is still open my application crashes at the following call stack:

>    ProfUIS254ud.dll!CExtPopupMenuWnd::PassMsgLoop(bool bEnableOnIdleCalls=false)  Line 8192 + 0xb bytes    C++

     ProfUIS254ud.dll!CExtPopupMenuSite::_Done()  Line 586 + 0xc bytes    C++

     ProfUIS254ud.dll!CExtPopupMenuSite::~CExtPopupMenuSite()  Line 431    C++

     ProfUIS254ud.dll!`dynamic atexit destructor for ’CExtPopupMenuSite::g_DefPopupMenuSite’’()  + 0xd bytes    C++

     ProfUIS254ud.dll!_CRT_INIT(void * hDllHandle=0x00760000, unsigned long dwReason=0, void * lpreserved=0x00000001)  Line 417    C

     ProfUIS254ud.dll!__DllMainCRTStartup(void * hDllHandle=0x00760000, unsigned long dwReason=0, void * lpreserved=0x00000001)  Line 509 + 0x11 bytes    C

     ProfUIS254ud.dll!_DllMainCRTStartup(void * hDllHandle=0x00760000, unsigned long dwReason=0, void * lpreserved=0x00000001)  Line 459 + 0x11 bytes    C

     NTDLL.DLL!7788806c()    

     [Frames below may be incorrect and/or missing, no symbols loaded for NTDLL.DLL]   

     NTDLL.DLL!7788a980()    

     KERNEL32.DLL!77e994c1()    

     KERNEL32.DLL!77e96a5b()    

     NTDLL.DLL!778ac166()    

     KERNEL32.DLL!77e78280()    

     KERNEL32.DLL!77e90c5b()    

     NTDLL.DLL!7788740d()    

     KERNEL32.DLL!77e90cf2()    

     KERNEL32.DLL!77e90b91()    

     msvcr80d.dll!__crtExitProcess(int status=0)  Line 684    C

     msvcr80d.dll!doexit(int code=0, int quick=0, int retcaller=0)  Line 596 + 0x9 bytes    C

     msvcr80d.dll!exit(int code=0)  Line 398 + 0xd bytes    C

     cpView.exe!__tmainCRTStartup()  Line 599    C

     cpView.exe!wWinMainCRTStartup()  Line 403    C

     KERNEL32.DLL!77e989d5()    

in the statement at line 8192:

    // Process all the messages in the message queue

    while( PeekMessage(&msg, NULL, 0, 0, PM_NOREMOVE) )

    {

        if( !AfxGetThread()->PumpMessage() )   <<<======= IT CRASHES HERE ===================

        {

            PostQuitMessage(0);

            return;

        } // if( !AfxGetThread()->PumpMessage() )

    } // while( PeekMessage(&msg, NULL, 0, 0, PM_NOREMOVE) )

I assume that there is no thread anymore because this call comes very late and the MFC might already be shut down.

- Can I fix this somehow without changing the source?

- If I do have to fix the source I would prefer a solution that would close the menu

- If that can not be done I guess I would have to check the result of AfxGetThread if is NULL

Thanks for your help.

Thomas

Thank you very much. It works now. I have put CancelMenuTracking into CWinApp::ExitInstance which is too late and causes another assertion but putting it into the WM_DESTROY handler of the main frame works fine. It looks a little strange when the application has gone but the menu is still visible before it is closed as the very last window but I can live with that..



Thanks again



Thomas

The CExtPopupMenuWnd::CancelMenuTracking() destroys the currently opened popup menu windows. This action should be linked to the destruction event of the main window in a ActiveX project or EXE project. You did this right. The IE server does not broadcast messages like WM_CANCELMODE to any windows before it releases some COM controls and this is the real source of the problem.

It’s absolutely not difficult to generate the following "DLL hell" like kind of problem: the window procedure or handler methods of some window are implemented in some DLL and invoked but the DLL is already unloaded.

The following situation is potentially possible:

1) A Prof-UIS popup menu is displayed on the screen.
2) IE becomes closed and your control is destroyed.
3) It’s even possible your DLL and Prof-UIS DLLs are unloaded before WM_DESTROY messages are delivered to the open popup menu windows.

You can invoke the CExtPopupMenuWnd::CancelMenuTracking() static method when your COM control is destroyed.