Problèmes d'utilisation wxWidgets (wxMSW) dans plusieurs instances de DLL

Question

Préface

Je développe des plugins VST qui sont des modules logiciels basés sur les DLL et chargé par les applications hôtes VST support. Pour ouvrir un plug-in VST, les applications hôtes chargent la DLL VST et appellent une fonction appropriée du plugin tout en fournissant un handle de fenêtre natif, que le plugin peut utiliser pour dessiner son interface graphique. J'ai réussi à porter mon code original VSTGUI vers le wxWidgets-Framework et maintenant tous mes plugins fonctionnent sous wxMSW et wxMac mais j'ai encore des problèmes sous wxMSW pour trouver une manière correcte d'ouvrir et de fermer les plugins et je ne suis pas sûr que ce soit un problème avec wxMSW uniquement.

Problème

Si j'utilise une application VST-hôte, je peux ouvrir et fermer les instances multiples d'un de mes plugins VST sans aucun problème. Dès que j'ouvre un autre de mes plugins VST en plus de mon premier plugin VST puis que je ferme toutes les instances de mon premier plugin VST, l'application se bloque après un court laps de temps dans la fonction wxEventHandlerr :: ProcessEvent me disant que l'objet wxTheApp n'est plus valide lors de l'exécution de wxTheApp-> FilterEvent (voir ci-dessous). Il semble donc que les objets wxTheApp ont été supprimés après la fermeture de toutes les instances du premier plugin et ne sont plus disponibles pour le 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 
    } 

    .... 
} 

Préalables

1.) Tous Mes plugins VST une dynamique Linked contre le C-Runtime et les bibliothèques wxWidgets. En ce qui concerne le forum wxWidgets , cela semblait être le meilleur moyen d'exécuter plusieurs instances du logiciel côte à côte.

2.) Le DllMain de chaque VST plug-in est défini comme suit:

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

Comment puis-je empêcher ce comportement, respectivement comment puis-je gérer correctement l'objet wxTheApp si je avoir plusieurs instances de différents plug-ins VST (modules DLL), qui sont dynamiquement liés aux bibliothèques C-Runtime et wxWidgets?

Les meilleurs reagards, Steffen

Answer 1

Nous avons eu des problèmes similaires à l'aide d'un LSP créé avec wxWidgets lorsqu'une application wxWidgets chargé notre DLL. Vérifiez NULL == wxTheApp avant d'appeler :: wxInitialize().

Code Pseudo:

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

Aussi, je suggère de faire aussi peu possible dans votre DllMain() que possible, par exemple déplacez wxInitAllImageHandlers() ailleurs si possible. En outre, vous pouvez suivre si vous avez appelé :: wxInitialize() pour jumeler avec :: wxUninitialize()

Answer 2

J'ai rencontré un problème similaire mais avec des plugins Acrobat. Lors de l'ajustement de nos plugins Acrobat à Acrobat X (10), nous avons dû supprimer le code associé à ADM (Acrobat Dialog Manager - Utilisé pour être une infrastructure GUI multiplateforme sur Acrobat 7, 8 & 9. Supprimé avec Acrobat X) et utiliser un cadre GUI différent.

Acrobat SDK est fourni avec des exemples d'utilisation de wxWidgets comme framework multiplate-forme. Nous nous y sommes pris (nous supportons MAC & Windows). L'architecture de plugin d'Acrobat est très similaire à celle décrite ci-dessus: dlls (pour les plugins Acrobat, l'extension de fichier binaire est * .api) chargés dynamiquement par un processus principal (exe) et leurs fonctions sont appelées dans un document , ordre prédéfini. Étant donné que l'exemple Acrobat wxWidgets a été écrit avec 2.8.12 et que cette version est stable, nous avons décidé de ne PAS utiliser la version 2.9.x en cours. Nous avons donc lié statiquement nos plugins (3 plugins différents) aux bibliothèques wx2.8.12 et avons découvert que si 3 d'entre eux étaient installés, les deux qui étaient chargés en dernier ne fonctionnaient pas. Par ce que je veux dire - Nos wxFrames personnalisés, wxWindows & wxDialogs appartenant à ces deux plugins ont tous été foiré (comme quelqu'un a essayé de les effacer, avec du caoutchouc :-)).

En creusant profondément nous avons réduit au fait que le premier plugin étant chargé, initialise wxWidgets et ce dernier pas, même si l'appel explicite à wxInitialize(). Quelque chose s'est mal passé ...

Ici j'ai oublié de mentionner - Dans un plugin Acrobat vous ne pouvez pas changer la fonction DllMain(), donc l'initialisation de wx est faite dans une "fonction Plugin Init()". Juste pour être clair - Les librairies wx sont statiquement liées aux fichiers * .api, donc chacune devrait avoir une "copie" et ne pas s'influencer les unes les autres.

En utilisant Google pour 2-3 jours complets j'ai réussi à trouver this post , qui a suggéré d'appliquer this patch (pour 2,8x seulement !!!). Je crois (ou espère) que la version 2.9.x ne souffre pas de ce problème (n'a pas eu la chance de le vérifier). BTW - Le patch est un seul fichier qui est très clair, donc lire le code pour le comprendre et être calme qu'il ne fait pas de mal est assez facile.

J'espère que d'autres utilisateurs de wx 2.8.x et souffrant du même problème le trouveront.

Omri