Проблемы с использованием WxWidgets (wxMSW) в течение нескольких экземпляров DLL

Question

Предисловие

Я занимаюсь разработкой VST-плагинов, которые DLL на основе программных модулей и загружаются VST-поддержки хост-приложения. Чтобы открыть VST-плагин, хост-приложения загружают VST-DLL и вызывают соответствующую функцию плагина, предоставляя собственный дескриптор окна, который плагин может использовать для рисования его графического интерфейса. Мне удалось перенести мой оригинальный код VSTGUI в wxWidgets-Framework, и теперь все мои плагины работают под wxMSW и wxMac, но у меня все еще есть проблемы с wxMSW, чтобы найти правильный способ открытия и закрытия плагинов, и я не уверен, что это проблема только с wxMSW.

Проблема

Если я использую любое приложение VST-хост можно открывать и закрывать несколько экземпляров одного из моих VST-плагинов без каких-либо проблем. Как только я открою еще один из моих VST-плагинов, помимо моего первого VST-плагина, а затем закрою все экземпляры моего первого VST-плагина, приложение сработает после короткого промежутка времени в функции wxEventHandlerr :: ProcessEvent, сообщив мне, что объект wxTheApp больше не действует во время выполнения wxTheApp-> FilterEvent (см. ниже). Похоже, что объекты wxTheApp были удалены после закрытия всех экземпляров первого плагина и больше не доступны для второго плагина.

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 
    } 

    .... 
} 

Предпосылками

1.) Все мои VST-плагины динамически связанные против С-Время воспроизведения и библиотеки WxWidgets. Что касается форума wxWidgets , это, по-видимому, лучший способ запуска нескольких экземпляров программного обеспечения бок о бок.

2.) DllMain каждого VST-плагин определяется следующим образом:

// 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) 

Вопрос

Как я могу предотвратить такое поведение, соответственно, как я могу правильно обрабатывать объект wxTheApp, если я имеют несколько экземпляров различных VST-плагинов (DLL-модулей), которые динамически связаны с библиотеками C-Runtime и wxWidgets?

Лучшие reagards, Штеффен

Answer 1

Мы имели аналогичные вопросы, используя LSP, созданные с WxWidgets, когда приложение WxWidgets загрузили наш DLL. Проверьте для NULL == wxTheApp перед вызовом :: wxInitialize().

Псевдо код:

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

Кроме того, я предлагаю делать так же мало возможно в вашем DllMain(), как это возможно, например, переместите wxInitAllImageHandlers() в другом месте, если это возможно. Кроме того, вы можете отслеживать, если вы вызвали :: wxInitialize() для сопряжения с :: wxUninitialize()

Answer 2

Я столкнулся с аналогичной проблемой, но с плагинами Acrobat. При настройке наших плагинов Acrobat на Acrobat X (10) нам пришлось удалить код, связанный с ADM (Acrobat Dialog Manager - используется для кросс-платформенного графического интерфейса на Acrobat 7, 8 & 9. Удалено с Acrobat X) и используйте другой графический интерфейс.

Acrobat SDK поставляется с образцами использования wxWidgets как кросс-платформенной платформы, поэтому мы возглавили этот путь (мы поддерживаем MAC & Windows). Плагин архитектуры Acrobat очень похож на тот, который вы описали выше: dll (для плагинов Acrobat расширение двоичного файла - * .api), которые динамически загружаются основным процессом (exe), и их функции вызывается в документе , предопределенный порядок.

Поскольку пример Acrobat wxWidgets был написан с 2,8.12, и из-за того, что это стабильная версия, мы решили НЕ использовать версию 2.9.x.

Итак, мы статически связали наши плагины (всего 3 разных плагинов) с библиотеками wx2.8.12 и выяснили, что если 3 из них установлены, то два загруженных последних не работают. Под этим я подразумеваю - наши пользовательские wxFrames, wxWindows & wxDialogs, принадлежащие к этим двум плагинам, были испорчены (как кто-то пытался их стереть, с резиной :-)).

Копаем глубоко, мы сузили его до того, что первый загружаемый плагин инициализирует wxWidgets, а второй нет, хотя явный вызов wxInitialize(). Что-то там пошло не так.

Здесь я забыл упомянуть - в плагине Acrobat вы не можете изменить функцию DllMain(), поэтому инициализация wx выполняется в функции «Plugin Init()».

Только для того, чтобы быть чистым. Wx libs статически связаны с * .api-файлами, поэтому каждый должен иметь «копию» самостоятельно и не влиять друг на друга.

Использование Google для 2-3 FULL дней Мне удалось найти this сообщение , в котором предлагается применить патч this (только для 2.8x). Я верю (или надеюсь), что версия 2.9.x не страдает от этой проблемы (у нее не было возможности проверить ее).

BTW - Патч - это только один файл, который очень четкий, поэтому читайте код, чтобы понять его, и быть спокойным, что это не наносит вреда довольно легко.

Я надеюсь, что другие, использующие wx 2.8.x и страдающие от одной и той же проблемы, найдут это.

Омри