2009-09-08 10 views
2

Je travaille sur une application de console wxWidgets dans laquelle je veux appeler = une DLL C#, via le CLR. Malheureusement, l'application hiccups dans le code d'initialisation de l'application wxWidgets car OleInitialize échoue. L'erreur que je vois est une fenêtre pop-up indiquant simplement "Impossible d'initialiser OLE".OleInitialize échoue lorsque Common Lanuage Runtime est activé?

Il semble que ce problème est généralement évité en définissant le style d'appartement pour les threads en appliquant une directive au point d'entrée de l'application, mais je suis vraiment aux prises avec le point d'entrée que je cherche. Mon code C# est une DLL: il n'y a pas de point d'entrée spécifique. Le code compilé avec/CLR existe dans un fichier .lib qui est lié à mon application wxWidgets. wxWidgets définit réellement le WinMain dans leur code, et me permet de remplacer les comportements via l'implémentation de wxApp.

D'autres suggestions incluent la désactivation du support OLE dans wxWidgets mais dans ma version 2.8.6, la définition de wxUSE_OLE, wxUSE_CLIPBOARD, wxUSE_DATAOBJ, wxUSE_DRAG_AND_DROP sur 0 crée des éléments externes non résolus lors de la compilation de wxWidgets.

Est-ce que vous avez déjà rencontré ce problème et avez trouvé un travail efficace? Quelqu'un peut-il fournir des éclaircissements sur le point d'entrée que je dois modifier?

Répondre

1

Comme mentionné dans ma question, il s'agit d'un problème impliquant les paramètres de style de filetage entre l'application C++ et les valeurs par défaut du CLR. Ce fut apparemment un bug, une fois, et Microsoft a publié un correctif:

http://msdn.microsoft.com/en-us/library/s6bz81ya.aspx

recompilation l'exécutable utilise le CLR .lib activé avec/CLRTHREADATTRIBUTE: STA était suffisant pour éliminer les erreurs que je était en train de voir.