Citation:
qui affiche lui-même une fenêtre en plus de la fenêtre principale. Comme MFC gère tout ça,
Heu, MFC gère pas grand chose, c'est plus à toi de faire tout le sale boulot, comme montré dans les exemples donc j'ai posté les URLs.
Citation:
Cependant, je m'attaque maintenant à la question de l'API. J'ai créé une classe Api dans mon application principale,
OK, donc mon laïus sur :
Citation:
Dans une application MFC, il y a 2 objets cardinaux, l'objet application (dérivé de CWinApp) et l'objet Document (qui peut être en plusieurs exemplaires dans une application multi-document).
Vous vous en foutez.
L'idée n'est peut-être pas génial, mais je vois pas où vous voulez aller avec votre classe "Api" sortie de nulle-part.
Pouvez-vous m'expliquer comment fonctionne votre classe pour faire communiquer votre Dll avec le code existant dans l'application ???
En informatique, il n'y a pas de magie, et si ça tombe en marche, c'est pas bon signe.
Avec mon
Code:
1 2 3 4 5 6 7 8 9 10
| class CWinAppApi : CWinApp
{
void MethodeAccessibleParPlugIns1(...){...}
void MethodeAccessibleParPlugIns2(...){...}
}
class CWinAppMonApplication : CWinAppApi
{
...
} |
La fonction MFC "AfxGetApp" renvoie l'objet CWinApp de l'application, qu'il me reste à caster dans le type attendu (CWinAppApi) pour avoir mon singleton DANS L'APPLICATION.(Une ch'tit gestion du versioning de l'API ne ferait pas de mal ici).
Citation:
et j'essaie de l'instancier depuis mon extension pour pouvoir appeler ses méthodes, sans succès.
Si vous instanciez un machin dans une Dll, elle sera accessible que dans le code qui a instancié le machin.
Les globales (c'est mal) du programme ne se mélangent pas avec les globales de la Dll.
Donc, je vois pas où vous voulez en venir avec vos "Solutions".
Citation:
Solution 1: Façon facile
Ouais, en gros, vous instanciez une variable globale dans la Dll. Il se fait comment le lien avec l'application ???
Citation:
Ici aucun fichier .dll n'est créé après compilation, je ne sais pas pourquoi !
Ok, mais c'est dans quelle fonction que vous avez ces machins ???
Parce que si c'est dans du code mort, le compilateur, lui, s'il n'y a que du code mort, il prend même pas la peine de générer une Dll (vue qu'il n'y a rien à exporter).
Citation:
Solution 2: Avec une méthode statique pour obtenir l'instance d'Api (qui est un singleton dans cette version)
Heu, ouais, mais ce singleton, c'est qu'une globale dans la Dll, pas dans l'application, non ?
Citation:
Ici j'ai une erreur de link. C'est peut-être lié au fait que l'instance d'Api est initialisée dans Api.cpp (auquel mon extension n'a pas accès), enfin je ne sais pas trop.
Si vous initialisez votre instance dans la Dll, c'est normal qu'il gueule, vu qu'il ne dispose pas du code source pour l'instancier.
Ce n'est pas à la Dll d'instancier l'objet qui fait le pont entre la Dll et l'application.
Pour revenir à ma solution à partir de votre classe Api :
Code:
1 2 3 4 5 6 7 8
|
/*static*/Api* Api::getApi()
{
return static_cast<Api*>(AfxGetApp());
}
Api* api = Api::getApi();
api->doStuff(); |
En modifiant un peu le code de l'application :
Code:
1 2 3 4 5 6 7 8 9 10 11 12 13
| class Api : CWinApp
{
virtual void doStuff() = 0;
}
class CWinAppMonApplication : Api
{
void doStuff() override
{
...
}
...
} |
(à l'arrache, sans tests)