Qt/MFC Migration Framework tool: properly exiting DLL?

Question

I'm using the Qt/MFC Migration Framework tool following this example: http://doc.qt.nokia.com/solutions/4/qtwinmigrate/winmigrate-qt-dll-example.html

The dll I build is loaded by a 3rd party MFC-based application. The 3rd party app basically calls one of my exported DLL functions to startup my plugin and another function to shutdown my application. Currently I'm doing nothing in my shutdown function.

When I load my DLL in the 3rd party app the startup function is called and my DLL starts successfully and I can see my message box. However if I shutdown my plugin and then try to start it again I get the following error:

Debug Error!

Program: <my 3rd party app>
Module: 4.7.1
File: global\qglobal.cpp
Line: 2262
ASSERT failure in QWidget: "Widgets must be created in the GUI
thread.", file kernel\qwidget.cpp line 1233

(Press Retry to debug the application)

Abort Retry Ignore

This makes me think I'm not doing something to properly shutdown my plugin. What do I need to do to shut it down properly?

UPDATE: http://doc.qt.nokia.com/solutions/4/qtwinmigrate/winmigrate-walkthrough.html says:

The DLL also has to make sure that it can be loaded together with other Qt based DLLs in the same process (in which case a QApplication object will probably exist already), and that the DLL that creates the QApplication object remains loaded in memory to avoid other DLLs using memory that is no longer available to the process.

So I wonder if there is some problem where I need to somehow keep the original DLL loaded no matter what?

User User · Accepted Answer · 2011-03-01T23:23:20

I GOT THIS WORKING! After many frustrating hours working on this I got it working. I was using the code provided in the Qt/MFC Migration documentation which has:

 BOOL WINAPI DllMain( HINSTANCE hInstance, DWORD dwReason,
                      LPVOID /*lpvReserved*/ )
 {
     static bool ownApplication = FALSE;

     if ( dwReason == DLL_PROCESS_ATTACH )
         ownApplication = QMfcApp::pluginInstance( hInstance );
     if ( dwReason == DLL_PROCESS_DETACH && ownApplication )
         delete qApp;

     return TRUE;
 }

This structure would work for a single load of my plugin DLL, but failed on subsequent loads. I don't believe DllMain is the correct place to call pluginInstance (at least for my use-case). I think the problem was that my 3rd party app only calls DllMain a single time and does not unload the DLL until the application quits. Thus when I started my plugin and then shut it down and then started it again, the QApplication initialized by the call to pluginInstance was still hanging around. I think my 3rd party app starts separate threads each time my plugin is started up, so when I started my plugin the second time it was a new thread but still trying to use the original QApplication setup in DllMain (the DLL still being loaded). Hence my error because it was new thread trying to write to the GUI.

The 3rd party MFC app which I am building expects two exports in my DLL, Startup() and Shutdown(), which it calls at the relevant times.

So instead of doing what the walkthrough suggests, I did as follows (pseudocode):

extern "C" __declspec(dllexport) void Startup()
{
  QMfcApp::pluginInstance( 3rdPartyApp::GetPluginHandle() );
  QWinWidget win( 3rdPartyApp::GetParentWindow() );
  win.showCentered();
  QMessageBox::about( &win, "About", "Hello World" );
}

 extern "C" __declspec(dllexport) void Shutdown()
{
  qApp->quit();
  delete qApp;
}

This is fine for a single plugin, but if I create multiple plugin's I'm not sure how well this will work because of the event loop integration I think there should only be a single QApplication across all plugins (based on my reading of the Qt/MFC documentation).

Qt/MFC Migration Framework tool: properly exiting DLL?

2 Answers