IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

C++ Discussion :

Comment créer une API C++ ?


Sujet :

C++

  1. #21
    Expert éminent sénior
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Février 2005
    Messages
    5 059
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Conseil

    Informations forums :
    Inscription : Février 2005
    Messages : 5 059
    Points : 12 095
    Points
    12 095
    Par défaut
    Ok, pas de panic, @SheepSheep, tu me semble un peu perdu.
    Je pense que tu cherches un peu trop "générique", il faut focaliser tes recherches sur tes besoins précis.

    MFC est un Framework graphique d'assez bas niveau ( en terme d’abstraction ). Il ne propose pas pléthore de solutions intégrées pour faire des choses un peu "chiadé".
    On se retrouve souvent à faire tout le sale boulot nous même, à la main.
    Il y a donc plein de petit "hacks" que les personnes partagent, mais il faut avoir une certaine habitude pour connaitre l'intérêt et les limitations qu'ils ont.

    Le lien que tu as posté (https://www.codeproject.com/Articles...-Extension-DLL) ne fait que ce qui est clairement indiqué, simplifier l'utilisation de classes "packagées" dans une Dll (le fait que cela soit une Dll d'extention MFC permet d'utiliser les classes MFC dans les classes de bases et les paramètres des méthodes des classes exportées).
    Le fait que l'exécutable soit statiquement lié à la dll les contenant est un effet voulu. Ici, on n'est pas dans un "hack" pour faire des plugins, mais pour simplifier la réutilisation de classe dans différents projets.
    Attention aussi que la méthode montrée date un peu et qu'elle devrait être adaptée aux fonctionnalités maintenant offertes par les "nouvelles" version de Visual Studio.

    En n'utilisant pas un framework MFC pour plugins, vous n'imposez pas son utilisation, donc sa maitrise, aux concepteurs de PlugIns (bien qu'il est peut-être possible d'avoir des frameworks très bien conçus, qui soient transparents pour les concepteurs de PlugIns, mais vu le nombre restreint de framework MFC pour plugins, c'est pas sûr que ça existe).
    Mais vous vous retrouvez à vous même concevoir comment architecturer votre application pour l'utilisation de PlugIns.
    L'architecture des MFC est tel qu'il vaut mieux concevoir comment l'utilisateur se verra offrir ces extensions dans l'IHM et ainsi réduire les recherches sur la manière de faire :
    Simple intégration de menu :
    -> https://www.codeproject.com/Articles...enu-Interfaces
    Intégration dans le choix des types de document :
    -> https://www.codeproject.com/Articles...amically-loade
    Intégration plus poussée :
    -> https://www.codeproject.com/Articles...LL-plug-in-tec

    Plus vous intégrez le plugIns dans votre application, plus il y a de "contraintes" pour les concepteurs de PlugIns.
    Attention aussi que ces codes et ceux que vous trouverez souvent sur le Web sont généralement vieux et qu'il faut les adapter aux règles de codages et aux MFC/ATL actuelles.

    Je n'arrive pas à trouver d'exemple pour ce cas, et j'ai du mal à partir de rien je vous avoue..
    Commencez par voir comment intégrer des PlugIns dans l'IHM de votre application.

  2. #22
    Nouveau Candidat au Club
    Femme Profil pro
    Étudiant
    Inscrit en
    Septembre 2017
    Messages
    11
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Septembre 2017
    Messages : 11
    Points : 1
    Points
    1
    Par défaut
    Bonjour,

    Merci pour vos conseils. J'y ai réfléchi et j'ai décidé de faire un plugin sous forme de DLL d'extension MFC, qui affiche lui-même une fenêtre en plus de la fenêtre principale. Comme MFC gère tout ça, et que l'appli et l'extension sont très liées, il n'y a pas de souci à priori.
    Cette partie-là est donc réalisée.

    Cependant, je m'attaque maintenant à la question de l'API. J'ai créé une classe Api dans mon application principale, j'ai include son header dans mon extension, et j'essaie de l'instancier depuis mon extension pour pouvoir appeler ses méthodes, sans succès.

    Voici comment je m'y suis prise:



    Solution 1: Façon facile

    Api api;
    api.doStuff();

    Ici aucun fichier .dll n'est créé après compilation, je ne sais pas pourquoi !



    Solution 2: Avec une méthode statique pour obtenir l'instance d'Api (qui est un singleton dans cette version)

    Api* api = Api::getApi();
    api->doStuff();
    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.


    Voilà, du coup je n'arrive pas à utiliser mon Api pour l'instant.

    Merci.

  3. #23
    Expert éminent sénior
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    Octobre 2004
    Messages
    11 612
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : Octobre 2004
    Messages : 11 612
    Points : 30 611
    Points
    30 611
    Par défaut
    Attention, le contenu de ta dll dépend de ce que tu y mets, et, pour que la dll soit générée, il faut que tu en compiles le code.

    Typiquement, cela se règle au niveau des options du projet que tu crées, au moment où tu débutes ton projet.

    A priori, je dirais que tu dois choisir la sous-catégorie "MFC" dans visual-studio, puis que tu dois sélectionner le type dll d'extension.

    Je présumes qu'il y a aussi moyen de partir d'un projet vide, mais qu'il y aura tellement d'options à mettre en place par toi-même que tu préféreras éviter la manœuvre

    Mais comme je ne suis pas (et de très loin) le mieux placer pour t'expliquer comment créer une dll d'extension MFC, je vais laisser la place aux autres
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  4. #24
    Nouveau Candidat au Club
    Femme Profil pro
    Étudiant
    Inscrit en
    Septembre 2017
    Messages
    11
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Septembre 2017
    Messages : 11
    Points : 1
    Points
    1
    Par défaut
    Ah pardon, ce n'était pas assez précis mais j'ai en fait déjà réalisé la DLL d'extension, le lien avec l'application principale et l'affichage d'une fenêtre depuis la DLL. Merci tout de même !

    Maintenant je bloque sur l'appel des fonctions de mon Api (qui sert d'interface entre les fonctionnalités de mon application et la DLL) depuis la DLL. Le but étant que la DLL puisse utiliser des fonctionnalités de mon application.

  5. #25
    Expert éminent sénior
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Février 2005
    Messages
    5 059
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Conseil

    Informations forums :
    Inscription : Février 2005
    Messages : 5 059
    Points : 12 095
    Points
    12 095
    Par défaut
    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.

    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 :
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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).

    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".

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

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

    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 ?

    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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)

  6. #26
    Membre expérimenté
    Profil pro
    Inscrit en
    Février 2004
    Messages
    1 824
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2004
    Messages : 1 824
    Points : 1 544
    Points
    1 544
    Par défaut
    Hello,

    Ayant souvent développé des systèmes par plugins, il y a non pas un mais plusieurs sujets :

    L'API

    Ce que tu dois "imposer" aux développeurs de plugins doit être minimaliste. Ils doivent hériter d'une ou plusieurs classes et implémenter des fonctions minimales pour se concentrer sur le "métier" propre à leur plugin.

    Au dessus de ses fonctions primitives, tu peux, dans ton exécutable, avoir des comportements commun. Par exemple, tu va imposer aux plugins qu'ils implémentent "tourner à droite", "tourner à gauche", "avancer", "reculer", et toi dans l'exécutable tu va pouvoir implémenter "faire un créneau".

    Une bonne approche serait d'utiliser une fabrique pour charger dynamiquement les plugins qui auront tous une interface commune. Si l'API est à minima complexe et est décomposé en plusieurs interfaces, alors il te faut une couche d'abstraction, dans ce cas une fabrique abstraite est à privilégier.

    Perso j'utilise toujours une fabrique abstraite, c'est plus perrein

    Les entêtes / l'implémentation

    Le développeur de plugins ne doit compiler aucun élément de l'exécutable. Il doit include un "api.h" (appelle le comme tu veux) mais ne doit pas à avoir à compiler les définitions de fonctions exposées.

    Il y a deux approches :
    - Exposer des classes composées uniquement de fonctions virtuelles pures
    - Le pImpl ideom

    Perso j'utilise toujours le pImpl ideom pour faciliter l'usage de comportement plus haut niveau, communs à tous les plugins (faire un créneau)

    Le chargement dynamique

    - dlopen / dlsym / dlclose (il me semble) sous Linux
    - LoadLibrary et équivalents sous Windows

    La compilation

    Peut n'importe quel compilateur est utilisé pour générer les plugins, il faut juste une correspondance entre l'architecture visée par l'exécutable et celle visée par le plugin. En résumé, il faudra compiler autant de versions de plugins que de versions d'exécutables.

    Sous Windows je suis à la masse pour ça

    Le versioning

    Un plugin va partir d'une ou plusieurs interfaces qui tu exposeras. Il se peut que celles-ci évoluent avec le temps, rendant des plugins obsolètes.

    Dans ce cas il faut exposer un numéro de version dans les "api.h" (si ce nom te convient), numéro que devra exposer chaque plugin pour faire des vérifications lors du chargement par l'exécutable.

    Il faut donc déterminer une convention X.Y.Z où Z évolue sans impacts sur les plugins (du bugfix), Y rajoute des fonctionnalités et X rompt le contrat d'interface.

    Les éléments graphiques

    Imposer les MFC dans les plugins parce que l'exécutable utilise les MFC dénote un manque de cohésion, donc un couplage fort, et donc un problème d'architecture. Si c'est bien foutu tu exposeras une fonction style "Init(HWND)" ou "Init(long)" et le plugin utilise ce qu'il veut pour construire sa zone graphique.

    Résumé

    Face à ces différents sujets, je te conseille de définir l'API et d'implémenter un plugin directement au sein de l'exécutable. Ensuite commencer à la déporter dans une DLL (ou .so), et déjà tu devrais y voire un peu plus claire pour attaquer les autres sujets

    Bon courage
    "Heureusement qu'il y avait mon nez, sinon je l'aurais pris en pleine gueule" Walter Spanghero

  7. #27
    Expert éminent sénior
    Avatar de Médinoc
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Septembre 2005
    Messages
    27 369
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2005
    Messages : 27 369
    Points : 41 518
    Points
    41 518
    Par défaut
    Franchement sous Windows, même/surtout avec MFC, le plus sûr pour faire des plug-ins ayant une interface "objet" plutôt qu'une interface "C", c'est de faire ça sous forme d'interfaces COM (même si on n'en fait pas un composant COM, avec toutes les histoires d'inscrire la DLL dans le Registre).

    C'est ce qui isole le mieux entre les compilos (voire les langages) de l'appelant et de l'appelé. Et si l'interface est définie dans un fichier .idl (compilé avec MIDL.exe) ou dans un fichier .h avec les macros DECLARE_INTERFACE, ça marchera même depuis le C.
    Dans le cas d'un plug-in COM n'étant pas un composant, la DLL exportera juste une fonction, EXTERN_C IPluginInterface * STDCALL CreatePluginObject(PluginParameters const *);, et tout le reste se fera via l'interface COM.

    L'inconvénient, c'est que ça doit respecter les conventions COM, notamment, ça ne permet pas de faire un plug-in sous forme d'une classe qui hérite d'une classe abstraite de l'appelant, ce que les DLLs d'extension MFC permettent.
    SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.

    "Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
    Apparently everyone.
    -- Raymond Chen.
    Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.

  8. #28
    Expert éminent sénior
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Février 2005
    Messages
    5 059
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Conseil

    Informations forums :
    Inscription : Février 2005
    Messages : 5 059
    Points : 12 095
    Points
    12 095
    Par défaut
    @mister3957, tes remarques sont correctes dans l'absolu et vraisemblablement dans un contexte plus Linux, mais, pragmatiquement, c'est très loin d'être la solution la plus pérenne.

    Une application fait avec les MFC, ça se voit comme le nez au milieu de la figure, rien que visuellement.

    Donc, en temps que personne connaissant les MFC et leur "possibilités" d’extension, je trouverai un peu fort de café d'avoir à me palucher une API bricolée toute moisie plutôt que de me fournir 2/3 bricoles métiers spécifiques et de me laisser faire mon travail d'intégration aux MFC de l'application juste en suivant les règles admises pour ce genre d'intégration.

    Que l'application fournisse une API de plus "bas niveau" pour les malheureux qui ne dispose pas des MFC, pourquoi pas, mais que cela ne nivelle pas vers le haut la difficulté d'intégration.

    Ce que tu dois "imposer" aux développeurs de plugins doit être minimaliste.
    Donc laissez les développeurs MFC avoir le confort des MFC alors.

    Ils doivent hériter d'une ou plusieurs classes et implémenter des fonctions minimales pour se concentrer sur le "métier" propre à leur plugin.
    L'absence de normalisation du mangling C++ rend votre exécutable et votre plug-ins liés par la chaine de compilation sur vous partagez des classes, ou des fonctions en C++.

    Une bonne approche serait d'utiliser une fabrique pour charger dynamiquement les plugins qui auront tous une interface commune...
    Ceci est déjà une fonctionnalité intégrée aux MFC, qui imposent déjà ces mécanismes instanciation des éléments de son architecture Document/Vue (ou Frame/View/Document).
    Pas besoin de réinventer la roue.

    Peut n'importe quel compilateur est utilisé pour générer les plugins,
    Peut-être sous Linux où la C-Runtime est fournie par l'OS, mais sous Windows, chaque exécutable, chaque dll, peut potentiellement avoir sa propre C-Runtime, donc NON ce n'est pas anodin et ce type de contrainte est extrêmement complexe à faire car elle demande un cloisonnage ABSOLU de tous les éléments, alloués dans un module implique désalloué dans ce même module, les types simples doivent être compatibles etc...

    En résumé, il faudra compiler autant de versions de plugins que de versions d'exécutables.
    Et de compilateurs, et de C-Runtime possibles ( par version de VS, par version de l'OS, par version des patchs de l'OS), de version de compilateur, etc...
    Laisse tombé la neige.

    EDIT : Tout à fait d'accord avec le message de @Médinoc.
    Si on veut offrir des possibilités d'extension sans passer par les MFC, COM est un choix bien plus pertinents que des classes C++ "pures".
    Et rien n'interdit d'offrir les 2 types d'API : Extention MFC et composant COM.

  9. #29
    Membre expérimenté
    Profil pro
    Inscrit en
    Février 2004
    Messages
    1 824
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2004
    Messages : 1 824
    Points : 1 544
    Points
    1 544
    Par défaut
    Je disais juste que MFC est un choix de bibliothèque graphique parmi d'autres bibliothèques et que si c'est bien foutu, normalement, le découplage est de rigueur.

    Proposer un système de plugins avec des contraintes techno fortes est contradictoire
    "Heureusement qu'il y avait mon nez, sinon je l'aurais pris en pleine gueule" Walter Spanghero

  10. #30
    Expert éminent sénior
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Février 2005
    Messages
    5 059
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Conseil

    Informations forums :
    Inscription : Février 2005
    Messages : 5 059
    Points : 12 095
    Points
    12 095
    Par défaut
    Je disais juste que MFC est un choix de bibliothèque graphique parmi d'autres bibliothèques et que si c'est bien foutu, normalement, le découplage est de rigueur.
    T'en connais toi des bibliothèques graphiques qui permettent un vrai découplage ???
    Moi, je ne connais que COM/OLE Control/ActiveX.

  11. #31
    Expert éminent sénior
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    Octobre 2004
    Messages
    11 612
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : Octobre 2004
    Messages : 11 612
    Points : 30 611
    Points
    30 611
    Par défaut
    Citation Envoyé par bacelar Voir le message
    T'en connais toi des bibliothèques graphiques qui permettent un vrai découplage ???
    Moi, je ne connais que COM/OLE Control/ActiveX.
    Heu... Vous en connaissez, vous, des bibliothèques graphique bien foutues

    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  12. #32
    Membre expérimenté
    Profil pro
    Inscrit en
    Février 2004
    Messages
    1 824
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2004
    Messages : 1 824
    Points : 1 544
    Points
    1 544
    Par défaut
    Citation Envoyé par bacelar Voir le message
    T'en connais toi des bibliothèques graphiques qui permettent un vrai découplage ???
    Moi, je ne connais que COM/OLE Control/ActiveX.
    En vrai tu fais exprès de ne pas comprendre ?

    Tu peux très bien exposer un identifiant de fenêtre (HWND) et le mec hérite de ça avec ce qui lui plaît pour ses composants graphiques. Bon c'est sûr c'est pas ce qu'il y a de plus sympa à faire, ça impliquerait de devoir gérer d'éventuelles dépendances au sein du gestionnaire de plugin, ou alors d'imposer que chaque plugin passe par un installeur. Les deux se font.

    Ou sinon, dépendant du besoin, exposer une mini gestion d'interface (créer une fenêtre, mettre un bouton à telle position et avec telle callback pour recevoir les événements au sein du plugin, etc.) comme ça il n'y a pas de gestion propre au graphique au sein des plugins. Les composants peuvent être des classes à part, histoire que ça ne devienne pas une usine à gaz au sein de l'exécutable.

    J'ai déjà fait des trucs où l'interface était créée à partir de méta données contenus dans une base relationnelle, donc c'est possible, et sans utiliser COM/OLE Control/ActiveX, donc il n'y a pas qu'une solution.

    Faut voir le besoin et les contraintes, c'est tout
    "Heureusement qu'il y avait mon nez, sinon je l'aurais pris en pleine gueule" Walter Spanghero

  13. #33
    Expert éminent sénior
    Avatar de Médinoc
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Septembre 2005
    Messages
    27 369
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2005
    Messages : 27 369
    Points : 41 518
    Points
    41 518
    Par défaut
    Surtout que OLE Controls/Active X c'est lourd à apprendre par rapport au reste de COM (moi-même je n'en suis pas encore là).
    Une interface COM qui expose une méthode CreatePluginControl(HWND hWndParent, RECT* position), ça tend à être suffisant.
    SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.

    "Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
    Apparently everyone.
    -- Raymond Chen.
    Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.

  14. #34
    Expert éminent sénior
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Février 2005
    Messages
    5 059
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Conseil

    Informations forums :
    Inscription : Février 2005
    Messages : 5 059
    Points : 12 095
    Points
    12 095
    Par défaut
    Citation Envoyé par mister3957 Voir le message
    En vrai tu fais exprès de ne pas comprendre ?
    Peut-être, mais vous ne semblez pas prendre en compte des choses qui, pour moi, sont fondamentales, comme le fait que les MFC change la fonction de dispatching des message de toutes les fenêtres du processus, y compris celles créées par un potentiel login, ainsi que la zone mémoire "contexte" de la toutes les fenêtres.
    Et c'est le même bordel avec OpenGL ou DirectX.

    Donc, clairement, si vous utilisez les MFC, OpenGL ou DirectX, votre approche candide de passage d'un simple HWND de fenêtre parente va tomber à l'eau.
    Dans le meilleur des cas, la bibliothèque graphique utilisée par le plug-in sera partiellement inopérante ou aura un comportement difficile à comprendre sans savoir que la bibliothèque graphiques de l'exécutable a foutu un peu le merdier dans les données utilisées par la bibliothèque graphique du plug-in (ou par le pauvre développeur Win32 qui a essayé de mettre en place à la main un petit machin).
    Dans le pire, tout part en cacahouète, et c'est le cas le plus probable, et de loin.

    Votre approche candide, pour moi, ne fonctionne qu'avec du Win32 de base, ce qui n'est, pour moi, pas une bibliothèques graphiques digne de ce nom.

    Donc ma question
    T'en connais toi des bibliothèques graphiques qui permettent un vrai découplage ???
    n'était par de la pure rhétorique.
    En tout cas, c'est surement pas MFC, ni OpenGL ni DirectX.
    Win32, merci l'âge de pierre.

    Mais, de toute façon, comme l'exécutable utilise les MFC, le seul moyen fiable de le faire avec une solution "candide" est d'interdire la création de la moindre fenêtre dans le plug-ins et de demander à l'implémenteur du plug-ins de passer par une API de création de fenêtre fourni par l'exécutable. Merci la galère.

    Citation Envoyé par mister3957
    J'ai déjà fait des trucs où l'interface était créée à partir de méta données contenus dans une base relationnelle, donc c'est possible,
    On n'est d'accord que vous étiez dans un contexte uniquement Win32, non ?

    Faut voir le besoin et les contraintes, c'est tout
    Oui, et dans les contraintes, le fait que l'exécutable utilise les MFC et qu'il doit avoir une intégration graphique des 2 sources de fenêtres, invalide l'approche candide.

    Citation Envoyé par Médinoc
    Surtout que OLE Controls/Active X c'est lourd à apprendre par rapport au reste de COM (moi-même je n'en suis pas encore là).
    Il y a pas mal de surcouche et de Designer qui mâche pas mal le travail.
    C'est assez simple de faire une application "host" de ce type de contrôle si elle utilise les MFC.
    Et l'implémentation d'un composant ActiveX, c'est un peu tricky mais c'est toujours un peu la même chose et il y a plein d'exemple sur le NET.

  15. #35
    Membre expérimenté
    Profil pro
    Inscrit en
    Février 2004
    Messages
    1 824
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2004
    Messages : 1 824
    Points : 1 544
    Points
    1 544
    Par défaut
    Citation Envoyé par bacelar Voir le message
    On n'est d'accord que vous étiez dans un contexte uniquement Win32, non ?
    Non, pas uniquement, c'était Win32 / Linux / Mac, le minimum syndical pour diffuser des trucs grands publics, du B2C quoi
    "Heureusement qu'il y avait mon nez, sinon je l'aurais pris en pleine gueule" Walter Spanghero

  16. #36
    Expert éminent sénior
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Février 2005
    Messages
    5 059
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Conseil

    Informations forums :
    Inscription : Février 2005
    Messages : 5 059
    Points : 12 095
    Points
    12 095
    Par défaut
    Citation Envoyé par mister3957 Voir le message
    Non, pas uniquement, c'était Win32 / Linux / Mac, le minimum syndical pour diffuser des trucs grands publics, du B2C quoi
    On n'est donc bien dans du code Win32 sous Windows, donc pas une "vraie" bibliothèque graphique.
    Sous Linux/Mac, c'était une "vraie" bibliothèque graphique ?
    Si oui, j'airais pensé qu'elle aurait été utilisé partout pour ne pas se compliquer la vie => mais entraine dépendance entre application et plug-ins.
    Il y a une impossibilité d'utiliser une "vraie" bibliothèque graphique, non ?
    Des dll d'extension MFC sont hostable dans du Win32 mais il n'y a pas d'intégration graphique entre l'application et l'IHM du plug-in.

  17. #37
    Nouveau Candidat au Club
    Femme Profil pro
    Étudiant
    Inscrit en
    Septembre 2017
    Messages
    11
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Septembre 2017
    Messages : 11
    Points : 1
    Points
    1
    Par défaut
    Bonjour,

    Merci pour toutes vos réponses, j'explorerai donc ces différentes pistes.
    Pourriez-vous m'indiquer comment, dans chaque cas, vous vous y prendriez pour déboguer vos plugins?

    En effet le concepteur de plugin n'aura à sa disposition qu'une version debug de l'application.

    Dans le cas d'une DLL d'extension MFC, que je suis en train de tester pour l'instant, je n'arrive pas à déboguer ma dll simplement avec la version debug de l'appli.
    En effet, mon application charge tous les plugins depuis son dossier "Plugins" au début de son exécution, puis les propose dans une liste. L'utilisateur en choisit un et clique sur "lancer", le plugin s'exécute alors.
    Lorsque je veux déboguer ma DLL d'extension, je spécifie dans les réglages du projet qu'elle doit se lancer avec l'exécutable de mon appli. Cependant, même en plaçant le .dll dans le dossier "Plugins" de mon appli, mon appli ne charge aucun plugin (alors que cela fonctionne quand je lance l'appli d'habitude). Je ne peux donc pas lancer mon plugin et le déboguer.

  18. #38
    Expert éminent sénior
    Avatar de Médinoc
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Septembre 2005
    Messages
    27 369
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2005
    Messages : 27 369
    Points : 41 518
    Points
    41 518
    Par défaut
    Ça sent le problème de répertoire courant utilisé à la place du répertoire contenant l'application. Sous Windows, pour récupérer ce dernier, on utilise:
    Code C++ : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    TCHAR monBuffer[MAX_PATH] = _T("");
    GetModuleFileName(NULL, monBuffer, MAX_PATH); //Récupère le chemin du .exe
    PathRemoveFileSpec(monBuffer); //Retire le nom de fichier et le backslash qui le précède
    CString repertoireDeLExecutable(monBuffer);
    SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.

    "Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
    Apparently everyone.
    -- Raymond Chen.
    Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.

  19. #39
    Nouveau Candidat au Club
    Femme Profil pro
    Étudiant
    Inscrit en
    Septembre 2017
    Messages
    11
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Septembre 2017
    Messages : 11
    Points : 1
    Points
    1
    Par défaut
    Bonjour,

    En effet en ayant modifié mon code cela fonctionne: l'application même lancée depuis le débogage d'un plugin charge bien les plugins et les propose dans une liste. Si j'ai bien compris, le répertoire utilisé auparavant était celui depuis lequel on exécutait l'application? Je pensais que c'était celui où se trouvait l'exécutable de l'application. Merci en tous cas pour cette correction!

    Cependant, cela ne me permet toujours pas de déboguer ma DLL d'extension MFC (càd mon plugin). Je me doutait que ça ne fonctionnerait pas, car il n'y a pas vraiment de lien entre le débogueur et le plugin lancé depuis l'appli...

    Y a-t-il une méthode?

    Merci.

  20. #40
    Expert éminent sénior
    Avatar de Médinoc
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Septembre 2005
    Messages
    27 369
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2005
    Messages : 27 369
    Points : 41 518
    Points
    41 518
    Par défaut
    Au pire si tu n'arrives pas à faire marcher autrement, tu te fais une application de test dédiée...
    SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.

    "Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
    Apparently everyone.
    -- Raymond Chen.
    Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.

Discussions similaires

  1. Comment créer une dll Win32 sous Delphi ?
    Par Mickey.jet dans le forum Langage
    Réponses: 8
    Dernier message: 16/06/2005, 16h38
  2. Comment créer une connexion accès distant ?
    Par fredero dans le forum API, COM et SDKs
    Réponses: 6
    Dernier message: 08/06/2005, 23h31
  3. comment créer une image sous forme d'eclipse(ronde)
    Par unix27 dans le forum Balisage (X)HTML et validation W3C
    Réponses: 2
    Dernier message: 15/05/2005, 23h16
  4. [débutant] Comment créer une base ?
    Par laffreuxthomas dans le forum PostgreSQL
    Réponses: 3
    Dernier message: 14/12/2004, 23h12
  5. Comment créer une Table dans 1 Bdd ACCESS avec Builder??
    Par makandja dans le forum C++Builder
    Réponses: 6
    Dernier message: 17/03/2004, 21h21

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo