Problems using wxWidgets (wxMSW) within multiple DLL instances

Question

Preface

I'm developing VST-plugins which are DLL-based software modules and loaded by VST-supporting host applications. To open a VST-plugin the host applications loads the VST-DLL and calls an appropriate function of the plugin while providing a native window handle, which the plugin can use to draw it's GUI. I managed to port my original VSTGUI code to the wxWidgets-Framework and now all my plugins run under wxMSW and wxMac but I still have problems under wxMSW to find a correct way to open and close the plugins and I am not sure if this is a wxMSW-only issue.

Problem

If I use any VST-host application I can open and close multiple instances of one of my VST-plugins without any problems. As soon as I open another of my VST-plugins besides my first VST-plugin and then close all instances of my first VST-plugin the application crashes after a short amount of time within the wxEventHandlerr::ProcessEvent function telling me that the wxTheApp object isn't valid any longer during execution of wxTheApp->FilterEvent (see below). So it seems to be that the wxTheApp objects was deleted after closing all instances of the first plugin and is no longer available for the second plugin.

bool wxEvtHandler::ProcessEvent(wxEvent& event)
{
    // allow the application to hook into event processing
    if ( wxTheApp )
    {
        int rc = wxTheApp->FilterEvent(event);
        if ( rc != -1 )
        {
            wxASSERT_MSG( rc == 1 || rc == 0,
                          _T("unexpected wxApp::FilterEvent return value") );

            return rc != 0;
        }
        //else: proceed normally
    }

    ....
}

Preconditions

1.) All my VST-plugins a dynamically linked against the C-Runtime and wxWidgets libraries. With regard to the wxWidgets forum this seemed to be the best way to run multiple instances of the software side by side.

2.) The DllMain of each VST-Plugin is defined as follows:

// WXW
#include "wx/app.h"
#include "wx/defs.h"
#include "wx/gdicmn.h"
#include "wx/image.h"

#ifdef __WXMSW__
#include <windows.h>
#include "wx/msw/winundef.h"

BOOL APIENTRY DllMain
( HANDLE hModule,
  DWORD ul_reason_for_call,
  LPVOID lpReserved )
{
        switch (ul_reason_for_call)
        {
            case DLL_PROCESS_ATTACH:
     {
               wxInitialize();
          ::wxInitAllImageHandlers();
      break;
     }
            case DLL_THREAD_ATTACH:
                    break;
            case DLL_THREAD_DETACH:
                    break;
            case DLL_PROCESS_DETACH:
                    wxUninitialize();
                           break;
        }

    return TRUE; 
}

#endif // __WXMSW__

class Application : public wxApp {};
IMPLEMENT_APP_NO_MAIN(Application)

Question

How can I prevent this behavior respectively how can I properly handle the wxTheApp object if I have multiple instances of different VST-plugins (DLL-modules), which are dynamically linked against the C-Runtime and wxWidgets libraries?

Best reagards, Steffen

Answer 1

We had similar issues using a LSP created with wxWidgets when an wxWidgets application loaded our DLL. Check for NULL == wxTheApp before calling ::wxInitialize().

Pseudo code:

BOOL APIENTRY DllMain(HANDLE hModule, DWORD dwReason, LPVOID lpReserved)
{
    switch(dwReason) {
     case DLL_PROCESS_ATTACH :
      if(NULL == wxTheApp) {
       ::wxInitialize();
      }
      break;
    }
}

Also, I suggest doing as little possible in your DllMain() as possible, e.g. move wxInitAllImageHandlers() elsewhere if possible. Additionally, you may wish to track if you called ::wxInitialize() to pair up with ::wxUninitialize()