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. #1
    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 Comment créer une API C++ ?
    Bonjour,

    Je travaille actuellement sur une application en C++. J'aimerais créer une API pour cette application qui me permettrait d'utiliser ses fonctions depuis l'extérieur. En effet, j'aimerais pouvoir utiliser cette API pour créer des plugins en C++ pour cette application.
    Je sais qu'il me faudra créer une bibliothèque, cependant je ne sais pas trop comment m'y prendre pour ne rendre accessibles que certaines de mes méthodes. Par exemple, j'ai une classe "Calculateur", et j'aimerais que seules quelques-unes de ses méthodes soient disponibles dans l'API. J'aimerais (si possible) éviter la duplication de code, et je ne veux pas modifier le code source de mon application.

    Quelles sont les possibilités pour créer cette API?

    Merci !

  2. #2
    Expert éminent sénior
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Février 2005
    Messages
    5 058
    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 058
    Points : 12 093
    Points
    12 093
    Par défaut
    J'aimerais créer une API pour cette application qui me permettrait d'utiliser ses fonctions depuis l'extérieur.
    "extérieur", c'est très flou, extérieur du module binaire, extérieur du processus, extérieur de la session, extérieur de la machine, etc...

    En effet, j'aimerais pouvoir utiliser cette API pour créer des plugins en C++ pour cette application.
    On va dire extérieur du module binaire alors ?
    Des plugins sous forme de dll/so et non d'exécutables ?

    Clairement, le C++ n'est pas le bon choix pour faire des modules binaires interopérables.

    La norme C++ ne spécifie pas d'ABI ni de règles de décoration des noms des symboles.
    Résultat, chaque module binaire exportant une API C++ n'est compatible qu'avec les binaires compilés avec le même compilateur, voir la même version du compilateur.
    Et en plus, il faut que les options de compilation, d'édition de lien, les versions des librairies tierces utilisés etc... soient compatibles entre elles lors de la compilation module utilisateur client de l'API et lors de la compilation du module implémentant l'API.

    En gros, à moins de faire soi-même les plugins du programme, en même temps que le programme et avec aucune chance de pouvoir les modifier après, c'est mort en C++.
    Cela rend l'architecture de plugins complètement sans intérêt pour moi.

    Le plus raisonnable, c'est d'implémenter une API C ou d'un autre langage spécifiant clairement son ABI et son mécanisme d'exportation.
    Faire une API C en C++, c'est pas très compliqué, c'est juste utiliser les séquences quand vous déclarez et implémentez les fonctions qui devront être accessibles depuis l'extérieur du module binaire.
    extern "C", ce charge de dire qu'il faut utiliser les conventions de décoration des noms des symboles à la C et pas à la C++, pour les conventions d'appels et autres détails d'API, chaque compilateur fait sa tambouille (à potasser dans la documentation de la chaine de compilation).

    Il existe des Framework, tel que COM (Common Object Model), ou XCOM sous Mozilla, ou MSF pour "simplifier" la construction de modules interopérables.
    Mais c'est pas le genre de framework qu'on utilise pas "après coup".
    Ils imposent des manières de faire très strictes.

    La manière de faire la plus basique, c'est d'imposer au module binaire du plugins d'avoir une fonction exportée à la C ( donc une API C) qui permet à l'exécutable de fournir un ensemble de pointeur de fonction C (toujours pour avoir une API C) que le code du plugins pourra appeler au moment "opportun".

    Je sais qu'il me faudra créer une bibliothèque
    Une Dll/so vous voulez dire ?

    cependant je ne sais pas trop comment m'y prendre pour ne rendre accessibles que certaines de mes méthodes.
    Heu, là, il n'y a rien de plus trivial, vous ne mettez pas ces méthodes dans l'API, c'est tout.

    Par exemple, j'ai une classe "Calculateur", et j'aimerais que seules quelques-unes de ses méthodes soient disponibles dans l'API.
    Si c'est une API C, c'est vous qui données l'ensemble des fonctions qui seront exportés (à vous de faire le wapping entre la fonction C et la méthode C++)
    Si c'est une API C++, ce que je vous décourage instamment de faire, il suffit de faire dériver "Calculateur" d'une Interface/Classe de base "ICalc" qui ne contient que les méthodes pertinentes pour le plugins. Vous ne fournissez que des "ICalc" dans l'API, et voilà.

    J'aimerais (si possible) éviter la duplication de code,
    Je veux mon nveux !!!!

    et je ne veux pas modifier le code source de mon application.
    Heu, c'est le genre de feature qu'on ajoute sur un coin de table, le jour de la Release.
    Cela aurait dû être pris en compte lors de la conception de la solution logicielle.
    Si vous n'êtes pas trop exigeant sur la fiabilité, la sécurité et la simplicité d'utilisation un bricolage à base de pointeur de fonction ne devrait pas trop modifier votre code, s'il est bien conçu.

    Quelles sont les possibilités pour créer cette API?
    Beaucoup, mais commencez par faire simple.

  3. #3
    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,

    Tout d'abord merci pour votre réponse.

    Je viens dans un premier temps apporter quelques éclaircissements sur mon problème. Je reprends actuellement une application réalisée en C++, qui n'a pas été pensée pour accueillir un système de gestion de plugins. Si cela est possible, je ne suis pas contre le fait de réaliser ce système (ou une partie) et/ou l'API de cette application dans un langage plus adapté.
    Quel langage me conseilleriez-vous? Le C# serait-il un bon choix par exemple?

    D'autre part, j'ai déjà codé le système de gestion des plugins (ceci dit je suis prête à le reprendre dans un autre langage si cela vaut le coup), et les plugins sont effectivement des .dll chargés durant l'exécution, et j'utilise déjà l'astuce du "extern C".
    Ma question touchait à l'API, car en cherchant des moyens de créer cette API je me retrouvais effectivement confrontée à de nombreux problèmes et questionnements:
    - la nécessaire compatibilité des compilateurs, sauf en utilisant extern C,
    - le choix entre linkage intern et extern (je pense que intern est le mieux pour l'API?),
    - le fait de devoir conserver toute l'application, qui est très lourde, pour créer cette librairie,
    - la mise à jour de mon application et donc de ma librairie entraînant une mise à jour du plugin, ce qui ne les rend pas très indépendants et diminue les avantages d'un système de plugins,
    - ...
    Je me suis alors demandé si mon approche était la bonne pour cette API.

    Depuis hier, j'ai commencé à coder mon API en ajoutant un fichier api.h et un fichier api.cpp, qui instancie les classes nécessaires et appelle leurs méthodes (un genre de wrapper donc). Je l'ai linké en statique, sans utiliser "extern C" (je ne sais pas comment m'y prendre en statique à vrai dire).

    Voilà donc où j'en suis, toutes les suggestions seront les bienvenues! J'apprends en faisant ce projet, donc recommencer et tenter d'autres approches ne me fait pas peur.

    J'ai également une question plus avancée:
    Est-il possible de faire communiquer un plugin avec l'application qui l'a chargé? Je m'explique: imaginons que mon application ait une classe "Config", singleton, qui contienne des infos en "temps réel" (selon les dernières modifications de l'utilisateur pendant l'exécution de l'application), est-il possible d'accéder à l'instance de cette classe depuis mon plugin?

    Merci à vous !

  4. #4
    Expert éminent sénior
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Février 2005
    Messages
    5 058
    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 058
    Points : 12 093
    Points
    12 093
    Par défaut
    Ok, merci d'avoir un peu plus défini le cadre du problème.
    Mais vous n'êtes pas très causeux/volubile sur le cahier des charges ou les contraintes des plugins (partage de fenêtre, multi-threading, sens des fonctions de callback, langages possibles pour l'implémentation, etc...)
    En fonction de ces critères, des approches sont viables ou complètement illusoires.

    Je reprends actuellement une application réalisée en C++
    Quels framework et bibliothèques ont été utilisés pour la réaliser ? (Qt? MFC? COM? XCOM? WinForms? Win32? DirectX? OpenGL? ILogView? etc...)
    qui n'a pas été pensée pour accueillir un système de gestion de plugins.
    Mais peut-être que les framework utilisés y ont pensé, eux.
    Si cela est possible, je ne suis pas contre le fait de réaliser ce système (ou une partie) et/ou l'API de cette application dans un langage plus adapté.
    Faudrait commencer déjà par savoir de quoi on dispose avant de commencer à refaire des roues carrées.
    Mixer les langages, c'est sympa, mais faire simple, c'est le principal.

    Quel langage me conseilleriez-vous?
    Commencez par voir toute les possibilités qu'offre votre langage, qu'offrent les Framework déjà utilisé et ce qu'offre les framework du langage qui sont compatibles avec ceux déjà utilisé.
    Le C# serait-il un bon choix par exemple?
    Pour faire du COM ou une migration du C++ vers du C++/CLI oui, sinon non pas vraiment.

    et j'utilise déjà l'astuce du "extern C"
    Ce n'est pas une astuce, c'est comme ça qu'on utilise et publie une API C depuis une Dll codée en n'importe quoi.
    C'est l'API qui est C, le reste on s'en cogne en quoi c'est fait.

    - la nécessaire compatibilité des compilateurs, sauf en utilisant extern C,
    L'extern C, c'est la méthode bas-niveau, où tous les détails comme la gestion du multi-threading, le partage de fenêtre, les callback, etc... reste à faire, c'est basique.
    Vous pouvez aussi utiliser des frameworks dédiés ou non (Qt, MFC, etc...) pour faire des plugins.

    - le choix entre linkage intern et extern (je pense que intern est le mieux pour l'API?),
    Pouvez-vous être plus précis ? je ne vois pas de quoi vous parlez.

    - le fait de devoir conserver toute l'application, qui est très lourde, pour créer cette librairie,
    Il n'est pas rare que la mise en place de plugins permette de réarchitecturer une application monolithique pour en faire une application "composite" bien plus souple et évolutive.

    - la mise à jour de mon application et donc de ma librairie entraînant une mise à jour du plugin,
    Ce n'est pas obligatoire. En fonction des technologies utilisées et en faisant attention à la conception des API, il est tout à fait possible de maintenir la compatibilité ascendante.

    ce qui ne les rend pas très indépendants et diminue les avantages d'un système de plugins,
    C'est pour cela qu'il faut faire attention aux technologies utilisées et bien concevoir les API pour les rendre facilement évolutives.

    Je me suis alors demandé si mon approche était la bonne pour cette API.
    Mais quelle approche ???

    Depuis hier, j'ai commencé à coder mon API en ajoutant un fichier api.h et un fichier api.cpp, qui instancie les classes nécessaires et appelle leurs méthodes (un genre de wrapper donc). Je l'ai linké en statique, sans utiliser "extern C" (je ne sais pas comment m'y prendre en statique à vrai dire).
    Heu, là, je ne sais pas où vous voulez en venir. Si le cpp est compilé avec le projet, je ne vois pas où est vraiment votre "plugIns".
    En "extern C", vous n'avez pas accès à des classes, juste à des fonctions libres et des variables globales.
    Si vous utilisez les extensions Visual Studio pour l'exportation de classes, vous vous retrouverez avec une API C++, avec tous les problèmes que cela implique.
    Convertir une classe et son ensemble de méthode en un ensemble de fonctions libres ayant un paramètre "HANDLE/void*" opaque supplémentaire permet de facilement wrapper des classes C++ dans une API C.

    Voilà donc où j'en suis, toutes les suggestions seront les bienvenues! J'apprends en faisant ce projet, donc recommencer et tenter d'autres approches ne me fait pas peur.
    Mais c'est quoi vos contraintes/ cahier des charges ???
    Sinon, une API C bien conçu et c'est dans la boite.

    Est-il possible de faire communiquer un plugin avec l'application qui l'a chargé?
    Oui, sans problème, vous fournissez une API de callback comme paramètre d'une des fonctions que le plugIns doit implémenter (par "API de callback", un ensemble de pointeur de fonction C).

    est-il possible d'accéder à l'instance de cette classe depuis mon plugin?
    Oui, sans problème, mais vous devez prendre le pli de ne plus raisonner en objet mais en C (ou en C coloré à la POO via des HANDLE pour remplacer les this) quand vous devez passer à travers de l'API C.
    C'est facile en plus avec un singleton.
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
     
    extern "C"
    {
        typedef struct Info{
            char* valeur1;
            char* valeur2;
            int32 valeur3;
        }
     
        Info* getConfigInfo(){
            return Config::Instance.getInfo();
        }
    }
    Attention à bien fixer toutes les options possibles lors de la compilation de la définition de la structure "Info" pour qu'elle ne varie pas en fonction du compilateur (alignement, sizeof des types utilisés, le pragma pack, etc...).

    Vous passez le pointeur sur la fonction "getConfigInfo" au plugins pour qu'il s'en serve.

  5. #5
    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
    Merci pour votre réponse, je vais donc donner plus de détails.

    Les plugins seraient sous la forme d'une fenêtre supplémentaire, par dessus la fenêtre principale. Il faut simplement qu'ils puissent utiliser les fonctionnalités du logiciel (via l'API) et accéder aux données courantes.

    L'application est en C++ et utilise MFC. Comment fonctionnerait grosso modo un système de plugins fait avec MFC? Les plugins eux-mêmes devraient utiliser MFC également?

    - le choix entre linkage intern et extern (je pense que intern est le mieux pour l'API?),
    Je parlais du choix entre bibliothèque dynamique ou statique pour mon API.

    - la mise à jour de mon application et donc de ma librairie entraînant une mise à jour du plugin,
    Ce que je veux dire ici c'est que, par exemple, si mon logiciel propose une fonction de calcul, et que celle-ci évolue dans la version suivante de mon logiciel, alors l'API sera à la traîne. Y a-t-il un moyen d'appeler les fonctions courantes du logiciel ? (En gros juste établir la communication entre le plugin et le logiciel en cours d'exécution, et pouvoir utiliser toutes les fonctionnalités du logiciel dans le plugin).


    Mais quelle approche ???
    La création de l'API via un fichier api.cpp et un api.h, dans le projet de mon application + la création de plugins en .dll utilisant cette API.


    Depuis hier, j'ai commencé à coder mon API en ajoutant un fichier api.h et un fichier api.cpp, qui instancie les classes nécessaires et appelle leurs méthodes (un genre de wrapper donc). Je l'ai linké en statique, sans utiliser "extern C" (je ne sais pas comment m'y prendre en statique à vrai dire).
    Heu, là, je ne sais pas où vous voulez en venir. Si le cpp est compilé avec le projet, je ne vois pas où est vraiment votre "plugIns".
    J'ai codé les fichiers api.cpp et api.h pour faire l'API, pas pour faire un plugin. Les plugins sont sous forme de .dll. Il faut bien ajouter ces deux fichiers api.cpp et api.h à mon application principale pour pouvoir créer ma librairie API, en livrant à l'utilisateur le .lib ainsi généré et le api.h ? Ou bien ça n'est pas la méthode à utiliser ?
    Du coup je résume ce que j'ai fait pour que ce soit plus clair:
    - une application C+++/MFC
    - dans cette application, des fichiers api.cpp et api.h pour mon API, et j'exporte le tout en .lib et fournis le api.h
    - un plugin manager, intégré à l'application, qui vient load les plugins
    - des plugins en .dll


    Mais c'est quoi vos contraintes/ cahier des charges ???
    Difficile de vous donner les éléments clefs, ne sachant pas ce qui est déterminant pour choisir une bonne approche pour cette API et ce système de plugins. Le projet lui-même n'est pas totalement fixé puisque je découvre au fur et à mesure les différentes possibilités et les choix à faire. Si ce n'est toujours pas clair, pourriez-vous me poser des questions plus précises, ou bien me donner des exemples de choix selon différents cas ? Merci !

    est-il possible d'accéder à l'instance de cette classe depuis mon plugin?
    Le problème de cette solution c'est que pour accéder aux différentes classes de mon application C++, je vais devoir tout recoder sous forme de struct etc ?



    Merci !

  6. #6
    Expert éminent sénior
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Février 2005
    Messages
    5 058
    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 058
    Points : 12 093
    Points
    12 093
    Par défaut
    OK, ça va être beaucoup beaucoup plus simple du coup.
    De l’embarra du choix, vous tombez dans "c'est comme ça et pas autrement".

    L'application est en C++ et utilise MFC.
    MFC implique des contraintes assez strictes sur l'utilisation du mulit-threading, des ressources, de la manière de charger "correctement" les Dll, etc...

    Les plugins seraient sous la forme d'une fenêtre supplémentaire, par dessus la fenêtre principale.
    Donc "mélange" de l'IHM de plug-ins avec celle de l'application.(le seul fait de vouloir rester au dessus de la fenêtre de l'application, c'est déjà un "mélange").
    MFC, la bibliothèque les plus "obsédé du contrôle que je connaisse" (elle colle son code en subclassing de fenêtre Kernel dans toutes les fenêtres de l'application), là, vous êtes dans la mouise si vous ne respectez pas SES règles.

    En gros, utilisez des Framework de plugins pour MFC et n'essayez pas de faire le votre, c'est un travail d'horloger pour avoir un truc qui explose pas à l'ouverture de la première fenêtre.

    Pas tester, mais mon ami Google me donne quelques résultats intéressants :
    https://github.com/tianrolin/Plugin
    https://www.codeproject.com/Articles...LL-plug-in-tec
    https://stackoverflow.com/questions/...fc-and-c-sharp(via COM/ActiveX voir ci-après)

    Bon, je pensais tomber sur plus de choses intéressantes avec Google mais, à la faiblesse du nombre de réponse, j'en déduis que les dernières versions des MFC, que je n'ai pas utilisé, n'ont pas trop axées leur évolution sur la mise en place de "Greffons/PlugIns" simples.
    MFC a toujours eu une approche très "isolationniste" vis à vis des autres technologies, la solution classique pour l'extensivité des applications MFC, c'est les Dll d’extension MFC :
    https://stackoverflow.com/questions/...fc-and-c-sharp
    La seule concession faite par les implémenteurs des MFC vers l'interopérabilité, c'est de supporter les composants COM/ActiveX s'ils disposent des interfaces qui vont bien.
    La possibilité d'héberger des contrôles .NET se fait indirectement via COM/ActiveX. Les composants .NET doivent être de composants COM "légal" pour s'intégrer dans une application MFC.

    Les Framework de Plus-Ins MFC doivent utiliser ces pauvres fonctionnalités d'interopérabilité pour essayer de faire leur job.
    Donc, commencez par évaluer ces Framework avant de vouloir faire une roue carrée.

    Il faut simplement qu'ils puissent utiliser les fonctionnalités du logiciel (via l'API) et accéder aux données courantes.
    Ce partager une IHM, c'est très loin d'être simple.

    Comment fonctionnerait grosso modo un système de plugins fait avec MFC?
    Nativement, qu'avec des Dll d'extension ou le hosting de composant COM.
    Les Framework devraient planquer ça avec une API plus ergonomique.

    Les plugins eux-mêmes devraient utiliser MFC également?
    Oui, si c'est à base de Dll d'extention, non si c'est à base de COM/ActiveX.
    Pour les composants non graphique, c'est possible de faire quand C++ "de base" mais attention au multi-threading.

    Je parlais du choix entre bibliothèque dynamique ou statique pour mon API.
    Un plug-ins, c'est un truc qu'on doit ajouter ou supprimer sans avoir à recompiler son exécutable, c'est donc forcement dans une Dll (bibliothèque dynamique), même si des parties du Framework d'interconnexion peuvent être en statique dans l'exécutable et/ou dans la Dll.

    Ce que je veux dire ici c'est que, par exemple, si mon logiciel propose une fonction de calcul, et que celle-ci évolue dans la version suivante de mon logiciel, alors l'API sera à la traîne. Y a-t-il un moyen d'appeler les fonctions courantes du logiciel ? (En gros juste établir la communication entre le plugin et le logiciel en cours d'exécution
    Oui, c'est une fonctionnalité de base de tout Framework de plug-Ins.
    Le Framework fourni à la Dll une API de Callback qui permet à la Dll d'appeler les fonctionnalités dans l'exécutable.
    Tant que la fonctionnalité de l'exécutable ne change pas d'API (nom et signature de la méthode de callback), les plug-ins seront compatibles avec les versions successives de l'exécutable (mais attention aux adhérences aux MFC qui pourraient casser la compatibilité en cas de modification de la version des MFC entre l'exécutable et les plus-ins)

    , et pouvoir utiliser toutes les fonctionnalités du logiciel dans le plugin).
    Il faut qu'elles soient au préalable définies dans l'interface de Callback.

    La création de l'API via un fichier api.cpp et un api.h, dans le projet de mon application + la création de plugins en .dll utilisant cette API.
    "api.cpp" est dans l'exécutable ou dans le plug-ins ???
    Vous voulez partager du code (.cpp) entre l'exécutable et le plug-ins ? Attention à la dépendance très forte que cela implique (même compilateur, options compatibles, ...)
    Regardez les exemples dans les Framework. Chacun a sa manière de faire.

    Il faut bien ajouter ces deux fichiers api.cpp et api.h à mon application principale pour pouvoir créer ma librairie API, en livrant à l'utilisateur le .lib ainsi généré et le api.h ? Ou bien ça n'est pas la méthode à utiliser ?
    Regardez les exemples dans les Framework. Chacun a sa manière de faire.(BIS)
    Mais, généralement, un .h devrait faire l'affaire.

    Du coup je résume ce que j'ai fait pour que ce soit plus clair:
    - une application C+++/MFC
    - dans cette application, des fichiers api.cpp et api.h pour mon API, et j'exporte le tout en .lib et fournis le api.h
    - un plugin manager, intégré à l'application, qui vient load les plugins
    - des plugins en .dll
    OK, sauf le .lib qui n'est pas forcement utile, voir en fonction du Framework utilisé.

    Le problème de cette solution c'est que pour accéder aux différentes classes de mon application C++, je vais devoir tout recoder sous forme de struct etc ?
    Voyez ce qu'offrent les Framework, mais s'ils sont très permissifs sur ce sujet, il y a de bonne chance que cela implique un couplage fort entre l'exécutable et les plug-ins, à moins de se baser sur un standard binaire de représentation des données comme l'offre COM/ActiveX.

  7. #7
    Rédacteur/Modérateur


    Homme Profil pro
    Network game programmer
    Inscrit en
    Juin 2010
    Messages
    7 113
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : Canada

    Informations professionnelles :
    Activité : Network game programmer

    Informations forums :
    Inscription : Juin 2010
    Messages : 7 113
    Points : 32 958
    Points
    32 958
    Billets dans le blog
    4
    Par défaut
    N'ayant pas tout lu, est-ce qu'une simple interface exploitable via REST dans le logiciel ne serait pas suffisant et convenable ?
    Pensez à consulter la FAQ ou les cours et tutoriels de la section C++.
    Un peu de programmation réseau ?
    Aucune aide via MP ne sera dispensée. Merci d'utiliser les forums prévus à cet effet.

  8. #8
    Expert éminent sénior
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Février 2005
    Messages
    5 058
    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 058
    Points : 12 093
    Points
    12 093
    Par défaut
    N'ayant pas tout lu, est-ce qu'une simple interface exploitable via REST dans le logiciel ne serait pas suffisant et convenable ?
    Heu, partager une IHM client lourd (MFC) juste avec des requêtes REST ? Pour moi, c'est un challenge de chez challenge.

  9. #9
    Expert éminent sénior

    Femme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Juin 2007
    Messages
    5 186
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Juin 2007
    Messages : 5 186
    Points : 17 126
    Points
    17 126
    Par défaut
    Mais partager de quoi construire l'interface dans le programme, ca doit se faire, non?

    En général, il est assez simple de créer une interface qui utilise la partie du code interne qu'on veut exposer, et de n'exposer que cette interface.
    On parle de "API wrapper". Cette surcouche peut être écrite en extern "C", de façon à permettre une utilisation plus souple depuis l'extérieur.

    As-tu vraiment besoin que le plugin crée les composants de l'interface graphique?
    Regarde notepad++, la majorité de ses plugins fonctionnent sans objet graphique qui leur soit propre, juste une map de noms vers des pointeurs de fonction, pour constituer le menu déroulant des extensions.
    Mes principes de bases du codeur qui veut pouvoir dormir:
    • Une variable de moins est une source d'erreur en moins.
    • Un pointeur de moins est une montagne d'erreurs en moins.
    • Un copier-coller, ça doit se justifier... Deux, c'est un de trop.
    • jamais signifie "sauf si j'ai passé trois jours à prouver que je peux".
    • La plus sotte des questions est celle qu'on ne pose pas.
    Pour faire des graphes, essayez yEd.
    le ter nel est le titre porté par un de mes personnages de jeu de rôle

  10. #10
    Rédacteur/Modérateur


    Homme Profil pro
    Network game programmer
    Inscrit en
    Juin 2010
    Messages
    7 113
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : Canada

    Informations professionnelles :
    Activité : Network game programmer

    Informations forums :
    Inscription : Juin 2010
    Messages : 7 113
    Points : 32 958
    Points
    32 958
    Billets dans le blog
    4
    Par défaut
    Non mais le but initial semble d'être uniquement de pouvoir utiliser des fonctionnalités de l'appli via des "plugins". Quoi que veuille dire cette phrase et cache le terme de plugin.
    Dans mon premier job, on avait des machines embarquées et on avait créé une API Rest pour récupérer des stats et pouvoir utiliser des services de la machine via une simple connexion réseau sur celle-ci.
    Proposer une API pour un tel engin peut passer par une API Rest. Et puisqu'une telle API utilisera du XML ou JSON en général (sinon faut consulter), c'est très facilement attaquable via n'importe quel langage.
    Et ça me parait pas plus fou que de vouloir transformer son appli en lib ou que sais-je pour pouvoir utiliser une partie de l'implémentation ou ajouter une gestion de modules à une telle boîte bien opaque.
    Pensez à consulter la FAQ ou les cours et tutoriels de la section C++.
    Un peu de programmation réseau ?
    Aucune aide via MP ne sera dispensée. Merci d'utiliser les forums prévus à cet effet.

  11. #11
    Expert éminent sénior
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Février 2005
    Messages
    5 058
    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 058
    Points : 12 093
    Points
    12 093
    Par défaut
    Dans l'absolu, @ternel et @Bousk, vous n'avez pas tord, mais les MFC, c'est très spécial.

    MFC dispose d'un ensemble d'outils d'aides à la conception d'IHM comme des Designer Graphiques ou des outils de localisations des chaines de caractères, etc...
    Si vous voulez toujours avoir recours à cet outillage, il est nécessaire de respecter les pré-requis des MFC, pour que tout "baigne dans l'huile".
    Cela implique d'utiliser leurs manières de faire, en matière de création de thread, de création de fenêtre, de gestion des ressources (segment de code, où les MFC colle les définitions des IHM, entre autres), etc...

    Les MFC disposent d'un ensemble important de fonctions intégrées comme la gestion des interfaces type MDI, à la Office, à la Visual Studio, les menu à la Office, Look And Feel variables, etc..., qui ne fonctionnent correctement que si on respecte leurs manières de faire.
    Les MFC sous-classes toutes les fenêtres créées dans un processus, que vous le vouliez ou non, via le Hooking de la création des fenêtres. Si vous faites votre tambouille dans un coin, si vous n'êtes pas conscient de cela, ça va vous faire tout drôle.

    Etc...

    Donc, avant de faire une méthode "de base", il faut être conscient de tout ce qu'apporte les MFC et qu'il faudra bien intégrer dans le plus-Ins, via une boite à outils qu'il faudra fournir aux développeurs de Plug-ins, ou que les framework de création de plug-ins MFC devraient fournir.

    Dans la "philosophie" MFC, qu'un plus-ins soit lié aux MFC, au même compilateur, en utilisant les réglages MFC (et pas d'autres), c'est la norme.

    Donc, doit-on contrevenir à la "norme" MFC dans l'architecture cible de la solution ???
    C'est un choix qui est très très loin d'être gratuit.

    Mais partager de quoi construire l'interface dans le programme, ca doit se faire, non?
    Oui, mais c'est pas du tout adapter aux outils qu'offrent les MFC.

    En général, il est assez simple de créer une interface qui utilise la partie du code interne qu'on veut exposer, et de n'exposer que cette interface.
    Les MFC utilisent massivement les "ressources" pour la création de fenêtre, et les "ressources" de votre application ne sont pas celles de votre plug-ins. Dans ces conditions, difficile de faire une API "simple".

    On parle de "API wrapper". Cette surcouche peut être écrite en extern "C", de façon à permettre une utilisation plus souple depuis l'extérieur.
    Les MFC ajoutes beaucoup de contraintes même si vous utilisez extern "C", il faut que vos thread soient STA, le passage des "ressources" d'un module à un autre n'est pas transparent, la gestion des messages Windows doivent être déléguées à la pompe à message de l'application, etc...
    C'est, pour moi, une fausse liberté que d'utiliser une API bas-niveau 'extern "C"'.

    As-tu vraiment besoin que le plugin crée les composants de l'interface graphique?
    Très bonne question, car s'il n'y a pas d'interface graphique à créer, MFC est bien moins relou.

    Regarde notepad++, la majorité de ses plugins fonctionnent sans objet graphique qui leur soit propre, juste une map de noms vers des pointeurs de fonction, pour constituer le menu déroulant des extensions.
    Il y a une conception très soignée à la base, que les outils MFC ne favorisent pas, doux euphémisme.

    @Bousk, pourquoi ne pas utiliser le protocole SNMP qui est dédié à ce genre de chose ???

  12. #12
    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 à tous pour l'intérêt que vous portez à ce sujet.

    Je veux effectivement que les plugins gèrent eux-même leur interface graphique, car ces interfaces pourront être très différentes, selon le choix de la personne qui écrira tel ou tel plugin. Cependant, le fait qu'il faille le même compilateur me gêne énormément, c'est une énorme contrainte à mettre sur les personnes qui voudront écrire des plugins.

    En ce moment je m'intéresse à la librairie "DynObj", sans savoir si elle sera compatible avec MFC. Au moins j'apprends pas mal de choses sur les problèmes de compatibilité entre compilateurs etc. (https://www.codeproject.com/Articles...Plugin-Objects)

    Le fait de mettre mon application sous forme de librairie vient du fait que pour l'instant, je ne sais pas du tout comment avoir une véritable api, qui me permettrait d'utiliser les fonctionnalités de mon appli "en direct". J'ai cherché des infos sur les fonctions de callback mais pour l'instant rien de concluant/que je comprenne. C'est donc une solution temporaire...

    Pourriez-vous m'aider sur les points suivants:
    - y a-t-il une solution "compatible avec MFC" qui m'éviterait ces problèmes de compatibilité entre compilateurs?
    - je ne trouve aucune info / tuto sur les frameworks de plugins MFC
    - créer une véritable API qui appelle des fonctions "en direct", peut-être en comprenant les fonctions de callback, et éventuellement leur fonctionnement avec MFC


    Merci !

  13. #13
    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
    Salut,
    Citation Envoyé par SheepSheep Voir le message
    Je veux effectivement que les plugins gèrent eux-même leur interface graphique, car ces interfaces pourront être très différentes, selon le choix de la personne qui écrira tel ou tel plugin. Cependant, le fait qu'il faille le même compilateur me gêne énormément, c'est une énorme contrainte à mettre sur les personnes qui voudront écrire des plugins.
    En fait, cette contrainte sera surtout due à ta politique de diffusion de ton projet:

    Si tu rends les sources de ton projet disponible (quelle que soit la licence utilisée), cette contrainte est inexistante : toute personne disposant d'outils permettant de compiler ton projet (et des connaissances pour le faire) pourra choisir de le compiler avec ses propres outils et de compiler de même les plugins qu'il développe.

    (note qu'il ne faut pas confondre "avoir la possibilité de le faire" et "avoir facile à le faire" )

    Par contre, si ta politique de diffusion consiste à ne fournir que l'exécutable compilé et les informations qui permettent d'ajouter un plugin aux gens, là, il n'auront pas le choix de l'outil à utiliser. Ce sera donc à toi d'indiquer très clairement quel outil ils doivent prendre

    La grosse question sans réponse sera alors de savoir combien de gens seront d'accord d'installer l'outil que tu leur impose dans le seul but de pouvoir développer un plugin à eux. Mais une chose est sur, une réponse de normand sera sans doute "beaucoup moins que si tu laisses à chacun le choix des outils utilisés"

    C'est bien sur simplifié à outrance, mais c'est déjà "une bonne base" de réflexion
    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

  14. #14
    Expert éminent sénior

    Femme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Juin 2007
    Messages
    5 186
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Juin 2007
    Messages : 5 186
    Points : 17 126
    Points
    17 126
    Par défaut
    Cette réponse est à tempérer avec une autre question:
    Qui peut vouloir écrire un plugin pour cette application?

    J'entends par là que si l'application ne sert qu'en interne, il est raisonnable d'imaginer que les utilisateurs peuvent se mettre d'accord.
    Mes principes de bases du codeur qui veut pouvoir dormir:
    • Une variable de moins est une source d'erreur en moins.
    • Un pointeur de moins est une montagne d'erreurs en moins.
    • Un copier-coller, ça doit se justifier... Deux, c'est un de trop.
    • jamais signifie "sauf si j'ai passé trois jours à prouver que je peux".
    • La plus sotte des questions est celle qu'on ne pose pas.
    Pour faire des graphes, essayez yEd.
    le ter nel est le titre porté par un de mes personnages de jeu de rôle

  15. #15
    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 ternel Voir le message
    Cette réponse est à tempérer avec une autre question:
    Qui peut vouloir écrire un plugin pour cette application?

    J'entends par là que si l'application ne sert qu'en interne, il est raisonnable d'imaginer que les utilisateurs peuvent se mettre d'accord.
    Tout à fait...

    Et on peut même alors partir du principe que ce sera l'équipe de dev qui créera les plugins, et, partant de là, qu'il y a de fortes chances pour qu'ils disposent tous des mêmes outils. Ce qui devrait lever "de fait" la restriction
    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

  16. #16
    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
    Pour des raisons dépassant ma volonté, seul l'exécutable sera distribué. Cependant, des utilisateurs "extérieurs" pourront être amenés à écrire des plugins.

    Je suis persuadée qu'il existe des solutions convenables pour ce genre de cas (cf bibliothèque DynObj). Avez-vous des pistes?

    Je précise que les plugins n'ont pas de contraintes en termes de langage/ bibliothèque utilisés pour l'instant, mais ils doivent être compatibles avec l'application en C++/MFC.

  17. #17
    Expert éminent sénior
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Février 2005
    Messages
    5 058
    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 058
    Points : 12 093
    Points
    12 093
    Par défaut
    En fait, cette contrainte sera surtout due à ta politique de diffusion de ton projet:
    Vous n'êtes pas aussi libre que ça, les MFC impliquent des modes de déploiement particulier, qui impose bien des chose au niveau de la chaine de compilation.

    cf bibliothèque DynObj
    Très intéressant, mais il se base sur des pré-requis qui, selon moi, ne sont pas dans la norme.
    J'ai connu bien des compilateurs qui ne fonctionnaient pas avec des pré-requis, mais les normes changent et les compilateurs ne sont pas forcement dans la norme et changent aussi.
    Le caractère "universel" de la solution me semble un peu optimiste.
    La solution est quand même assez élégante mais elle a un niveau de complexité qui me fait quand même penser qu'on n'est plus très loin de COM.
    Pourquoi investir du temps et prendre des risques sur une obscure librairie qui donne un peu moins de fonctionnalité que COM, un peu plus facile à utiliser que COM (mais ça se discute), mais qui donne une solution cross-plateforme qui ne vous servira pas ?
    Peut-être aider à comprendre COM, car, in fine, la solution proposée et dans la même philosophie que COM, mais COM est un standard de fait de M$ avec bien plus de ressources et de "support".

    @SheepSheep, je pense que vous vous posez mal les contraintes.
    Le fait de pouvoir utiliser n'importe quel langage ne devrait pas complexifier le travail des personnes qui dispose du même langage, du même compilateur, etc...

    Moi, j'aurais une approche bien plus pragmatique.
    Plutôt que de raisonner dans l'absolu, il faut faire au plus simple, avec ce que l'on a déjà, selon moi.

    Une application MFC s'étend traditionnellement via des Dll MFC d'extension.
    Cela est extrêmement confortable et nous disposons de tous les services qu'offre cette architecture d'extension, avec quelques contraintes en terme d'outils de génération (MFC compatibles entre elles).
    Il faut bien comprendre que dans le contexte d'application MFC, ce sont des contraintes extrêmement peu limitative.
    Moi, on me demande de faire une simple extension à une application MFC, j'ai VS2017 Community (gratuit et avec les dernières MFC), et je suis obligé d'utiliser une simple API C, une API via un obscure framework C++, ou même d'utiliser COM, ça me ferait copieusement chier.
    Même si vous voulez une API low-level, fournissez toujours le moyen d'étendre simplement votre application.
    Et là, pas d'embrouille de threading et autre sous-classement de fenêtre.

    Si je veux faire mon chieur et que je veux utiliser mes outils/langages/framework pour étendre votre application.
    Si vous me donnez une API COM qui est bien conçue pour faire mes petites affaires, je serais contant car je pourrais facilement faire mes trucs.
    Si j'utilise des outils pas foutu de consommer ou d'implémenter facilement des API COM, c'est que je suis un putain de Neandertal qui méritait de disparaître.
    Et là aussi, pas d'embrouille de threading et autre sous-classement de fenêtre (si je respecte les règles des MFC).

    Si je suis une mijaurée qui veut pas parlé au grand méchant COM mais en C++ "standard", pour éviter des emmerdes, utilisez un Framework "Spéciale MFC" (contrairement à DynObj) pour que les problèmes de threading eu autres sous-classement soit correctement géré par ce Framework "Spéciale MFC". (cf. les liens de mon 3ème post)

    Si vous voulez montrer que vous avez des "cojones", vous pouvez toujours tenter d'adapter des framework non MFC comme DynObj pour les MFC, voir vous en faire un from scratch.
    Mais là, faudra être béton sur les avantages de ce NMH par rapport aux solutions "clé en mains" (Extension MFC, composants COM) qui devront justifier l'énorme coup/travail que cela représente.

  18. #18
    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
    D'accord, je vais me pencher sur les extensions dll MFC dans ce cas.

    Connaissez-vous de bonnes ressources à ce sujet? (avec exemples, tutoriels, etc) Notamment pour appeler des fonctions de l'appli principale depuis le dll d'extension MFC.

    J'ai une question très importante pour mon projet: il semble qu'il faille forcément recompiler l'appli principale lorsqu'on veut ajouter un .dll MFC, y a-t-il une alternative? Cela ne sera pas possible dans mon cas

    Quelles sont les contraintes de compilateur exactes avec cette solution? (Je parle de la compatibilité entre le compilo qui a compilé l'appli et celui qui compile l'extension: exactement le même, versions différentes possibles ?..) Où trouver ces infos ?



    De plus, où puis-je mieux me renseigner sur les contraintes imposées par MFC vis-à-vis des threads, interfaces graphiques, .. ? Afin de mieux comprendre pourquoi utiliser une autre méthode pour mes plugins poserait problème.

    Merci !

  19. #19
    Expert éminent sénior
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Février 2005
    Messages
    5 058
    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 058
    Points : 12 093
    Points
    12 093
    Par défaut
    Connaissez-vous de bonnes ressources à ce sujet? (avec exemples, tutoriels, etc) Notamment pour appeler des fonctions de l'appli principale depuis le dll d'extension MFC.
    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).
    Bin moi, je me prendrait pas la tête pour la version Dll d'extension MFC, soit j’appelle des méthodes de la classe dérivée de CWinApp (un simple cast de la valeur de retour de AfxGetApp et c'est dans la boite)
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
     
    class CWinAppApi : CWinApp
    {
       void MethodeAccessibleParPlugIns1(...){...}
       void MethodeAccessibleParPlugIns2(...){...}
    }
     
    class CWinAppMonApplication : CWinAppApi 
    {
     ...
    }
    Soit, si j'ai besoin de faire du travail sur la base de chaque document en faisant la même chose que pour CWinApp mais avec le résultat de "CFrameWnd::GetActiveDocument".

    Un exemple d'intégration d'IHM :
    https://www.codeproject.com/Articles...enu-Interfaces

    il semble qu'il faille forcément recompiler l'appli principale lorsqu'on veut ajouter un .dll MFC, y a-t-il une alternative?
    Où avez-vous lu cela ?

    Quelles sont les contraintes de compilateur exactes avec cette solution?
    La documentation sur l'utilisation des Dll d'extension MFC en parle pas mal.
    En gros, ne pas mélanger les Dll ni les versions de Visual Studio et suivre à la lettre les réglages demandés. (C'est un peu restrictif, mais vos mieux pas trop faire d’acrobaties)

    De plus, où puis-je mieux me renseigner sur les contraintes imposées par MFC vis-à-vis des threads, interfaces graphiques
    En gros, il faut les mêmes contraintes que pour des Dll "normales" et il y en a déjà beaucoup (C-Runtime compatible ou isolation mémoire, même version des librairies qui définissent les types passés en paramètre de l'API, etc...)
    Plus, si vous faites des choses avec l'IHM, tout le code MFC n'est pas très thread-safe donc on utilise l'api MFC pour créer des threads qui ne poseront pas de problème avec les objets MFC :
    https://msdn.microsoft.com/fr-fr/lib...or=-2147217396
    Si vous créez des fenêtres via des API non MFC comme "CreateWindow", préparez-vous à vous battre avec un rouleau compresseur qu'est MFC pour imposer ses routines sur les vôtres.

  20. #20
    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
    Merci pour ces informations.


    J'ai lu à plusieurs endroits qu'il faudrait nécessairement inclure le header du DLL d'extension MFC dans le projet de l'application principale. Par exemple ici: "All you'll ever need to do to use you extension DLL is just include it's header in your application" ( https://www.codeproject.com/Articles...-Extension-DLL ). Ceci impliquerait évidemment de recompiler l'application principale.

    Y a-t-il une autre méthode ? (Par exemple, avec une interface commune à tous les plugins?)
    Je n'arrive pas à trouver d'exemple pour ce cas, et j'ai du mal à partir de rien je vous avoue..

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