[MFC] - Creation de librairie statique contenant du code MFC

Bonjour,

Je développe une application MFC. Pour un besoin d'installation pratique, il est impératif que cette application soit liée statiquement aux mfc.
Lors du développement, il est prévu de pouvoir réutiliser le code de certaines fonctions qui devront donc être placées dans une librairie statique. Ces fonctions utilisent parfois des classes MFC.

J'ai l'impression de me mélanger les pinceaux lors de ce développement:

• J'arrive à paramétrer l'appli pour être liées statiquement aux MFC
• J'arrive à créer ma librairie statique, que je rempli de fonctions,
• Je place bien le .h de la librairie dans le code source de l'appli,
• J'ajoute le lien à .lib dans le code source de l'appli(j'ai essaye par un #pragma ou directement dans les options du projet),
• J'ai un message m'indiquant qu'il ne trouve pas la fonction (voir ci dessous).

Est-ce bien la bonne procedure ? Sinon, qu'ai-je loupé ?

Message:

Citation:

---

Erreur 1 error LNK2019: symbole externe non résolu "void __cdecl BNetwork::WakeUp(class ATL::CStringT<wchar_t,class StrTraitMFC<wchar_t,class ATL::ChTraitsCRT<wchar_t> > >)" (?WakeUp@BNetwork@@YAXV?$CStringT@_WV?$StrTraitMFC@_WV?$ChTraitsCRT@_W@ATL@@@@@ATL@@@Z) référencé dans la fonction "public: void __thiscall CTestXLSDBDlg::OnPosteAllumer(void)" (?OnPosteAllumer@CTestXLSDBDlg@@QAEXXZ) D:\Programmation\Projets\ELGestion\trunk\TestXLSDB\TestXLSDBDlg.obj

---

Combien de fois il faut que je dise qu'exporter des classes C++, C'EST MAL. :cry::cry::cry:

Votre problème n'a rien à voir avec les MFC.

Le linker cherche, et ne trouve pas, la méthode avec la signature "void __cdecl BNetwork::WakeUp(class ATL::CStringT<wchar_t,class StrTraitMFC<wchar_t,class ATL::ChTraitsCRT<wchar_t> > >)".

- "__cdecl", si, lors de la compilation de la lib, la convention d'appel par défaut n'est pas "__cdecl", vous avez perdu.
A moins, bien sûr que vous avez explicitement déclaré les conventions d'appel de chacune de vos méthodes et fonctions. Mais j'en doute. :mrgreen:

- "class ATL::CStringT", si, lors de la compilation de la lib, la classe Cstring n'est pas transformé en ATL::CStringT, vous avez perdu.
Il faut regarder du côté des options de compilation de la lib.

- "wchar_t", si, lors de la compilation de la lib, la constante de compilation "UNICODE" ou équivalent n'est pas définie, vous avez perdu.

- "StrTraitMFC", si, lors de la compilation de la lib, StrTraitMFC n'est pas "le trait" par défaut de la classe template ATL::CStringT, vous avez perdu.

...

Exporter des classes C++, C'EST MAL, C'EST MAL, C'EST MAL. Et ce n'est pas une règle à l'emporte pièce. Et votre problème en est l'illustration.

P.S.: vous avez perdu. :aie::aie::aie:

Soit c'est mal, voir très mal.

Maintenant que faire ? Comment exporter ces fonctions qui font références à des classes ?
J'ose espérer qu'il existe au moins une solution.

Si je ne dois pas exporter de classe, que puis-je faire pour exporter ce genre de fonction:

Code:

---

int Func(CString str, int nb);

---

Ne pas se mettre en Multi-threaded Debud DLL peut aussi régler ce genre de désagréments il me semble.
Essaye d'utiliser /MTd et non /MDd si c'est le cas.

Courage.

Vouloir exporter des classes, c'est obliger les utilisateurs de cette librairie à un compilateur, voir à une version du compilateur, correspondant à celui qui à généré le dll.
Cela oblige aussi les utilisateurs de cette librairie à utiliser des options de compilations compatibles entre la compilation de la librairie et celle du code utilisateur.
Vous devrez donc spécifier le compilateur nécessaire à l'utilisation de votre librairie, voir fournir plusieurs versions de votre librairie en fonction du compilateur, de sa version et des options de compilation à supporter. Bon courage. :calim2:
Le .h de votre librairie devra aussi détecter les options de compilations lors de son inclusion et générer une erreur de compilation quand il détectera des options et constantes de compilations incompatibles. Il faut faire au moins un minimum, comme la vérification du type de C-Runtime, la remarque de TheGzD en est l'illustration. Cette vérification doit être faites automatiquement à la compilation, avec l'inclusion du .h dans un projet.

Citation:

---

Si je ne dois pas exporter de classe, que puis-je faire pour exporter ce genre de fonction:

Code:

---

int Func(CString str, int nb);

---

---

Pas mal le passage d'une string en paramètre avec recopie. :aie:
Pensez aux références const. :oops:

Ce n’est pas le plus compliqué comme fonction :

Code:

---

WINAPI int Func([in]LPCSTR str, [in]int nb);

---

Le [in], c'est pour la déco, mais c'est toujours utile de savoir le sens de passage des paramètres. Dans la même veine, spécifiez ce qui est modifiable, d'où le C de LPCSTR.

Rien ne vous empêche de spécifier des classes dans les .h de votre librairie qui encapsuleront vos fonctions dans des méthodes de classe. Mais les instances de ces classes seront générées dans du code compilé lors de l'utilisation de la librairie, pas au moment de la compilation de la librairie, donc avec des options compatibles avec le code utilisateur. Ces classes ne seront que des wrappers sans intelligence mais pouvant faciliter l’utilisation de la librairie. Elles n’ont pas à être les mêmes que celles utilisées dans le code de la librairie elle-même.

Il faudra donc que vous identifiez toutes les options et constantes de compilations qui influenceront le mangling de vos méthodes et que vous ajoutiez le code de vérification de ces options et constantes dans le .h de votre librairie.
Une fois cette tâche ingrate faites, il ne vous restera qu’à inclure votre .h dans le projet utilisateur. Lors de la compilation du projet utilisateur, les informations que vous avez distillées dans les messages d'erreur du code de vérification dans le .h devraient vous indiquer les options à ajouter ou à supprimer du projet utilisateur pour qu'ils soient compatibles avec la librairie.

En un mot vous devez contrôler options de compilations du code utilisateur dans le .h de la librairie, mais il faut absolument que vous maîtrisiez un minimum les pré-requis nécessaires à l'utilisation de votre lib C++.

Citation:

---

qu'exporter des classes C++, C'EST MAL. :cry: :cry: :cry:

---

Bis, ter ... :roll:

Citation:

---

Combien de fois il faut que je dise qu'exporter des classes C++, C'EST MAL.

---

8O C'est quelle compagne ça!!!!

Qui a dit qu'exporter des classes C++ c'est mal?

A quoi servent les DLLs d'extension MFC?

Si vous travaillez avec MFC pourquoi se compliquez avec les versions de compilo utiliser votre Visual Studio.

On peut avoir des solutions de projets qui sont essentiellement des dlls d'extension MFC contenant des classes de bases réutilisables pour une application MFC (exe)

Par exemple on peut avoir une solution de 4 projets:

dans une dll d'extension MyBase.dll on a :

Code:

---

1 2 3 4 5 6 7

class AFX_EXT_CLASS CMyBaseWinApp : public CWinAppEx { ... }; class AFX_EXT_CLASS CMyBaseMainFrame : public CMDIFrameWndEx { ... }; class AFX_EXT_CLASS CMyBaseDocument : public CDocument { ... }; class AFX_EXT_CLASS CMyBaseTreeView : public CTreeView { ... }; class AFX_EXT_CLASS CMyBaseDockablePane : public CDockablePane { ... }; class AFX_EXT_CLASS CMyPersonnalMfcClass : public CObject { ... };

---

dans une autre dll d'extension MyExtend.dll on a :

Code:

---

1 2 3 4 5 6 7

class AFX_EXT_CLASS CMyRichWinApp : public CMyBaseWinApp { ... }; class AFX_EXT_CLASS CMyRichMainFrame : public CMyBaseMainFrame { ... }; class AFX_EXT_CLASS CMyRichDocument : public CMyBaseDocument { ... }; class AFX_EXT_CLASS CMyRichTreeView : public CMyBaseTreeView { ... }; class AFX_EXT_CLASS CMyRichDockablePane : public CMyBaseDockablePane { ... }; class AFX_EXT_CLASS CMyRichPersonnalMfcClass : public CMyPersonnalMfcClass { ... };

---

dans une application MFC MySimpleApp.exe on a :

Code:

---

1 2 3 4 5 6 7

class AFX_EXT_CLASS CSimpleWinApp : public CMyBaseWinApp { ... }; class AFX_EXT_CLASS CSimpleMainFrame : public CMyBaseMainFrame { ... }; class AFX_EXT_CLASS CSimpleDocument : public CMyBaseDocument { ... }; class AFX_EXT_CLASS CSimpleTreeView : public CMyBaseTreeView { ... }; class AFX_EXT_CLASS CSimpleDockablePane : public CMyBaseDockablePane { ... }; class AFX_EXT_CLASS CSimplePersonnalMfcClass : public CMyPersonnalMfcClass { ... };

---

dans une autre application MFC MyPowerApp.exe on a:

Code:

---

1 2 3 4 5 6 7

class AFX_EXT_CLASS CPowerWinApp : public CMyRichWinApp { ... }; class AFX_EXT_CLASS CPowerMainFrame : public CMyRichMainFrame { ... }; class AFX_EXT_CLASS CPowerDocument : public CMyRichDocument { ... }; class AFX_EXT_CLASS CPowerTreeView : public CMyRichTreeView { ... }; class AFX_EXT_CLASS CPowerDockablePane : public CMyRichDockablePane { ... }; class AFX_EXT_CLASS CPowerPersonnalMfcClass : public CMyPersonnalMfcClass { ... };

---

Voici les principes d'utilisation efficaces des dlls sans se perdre avec les *.h ou les lib ou les problèmes de référencement entre projets. D'ailleurs je pouvais même ajouter des dll .NET comme des projets dans la même solution et qui soit exploitable par ces 4 projets natives mais qui deviendraient mixte dans ce cas. Mais restons en là d'abord au monde du natif.

1. Project Dependencies
Il faut régler le problème de dépendances des projets dans la configuration de votre solution. MyBase.dll vient en premier, MyExtend.dll vient en second ensuite les exe MySimpleApp.exe en troisième et MyPowerApp.exe en quatrième. Ainsi lors de la compilation de la solution (je n'ai pas dis du projet) les projets qui la composent sont compilés dans le bon ordre.

2. Les includes
Puisque les dlls sont aux services des exe. Il est préférable de ranger la définition de chacune de vos classes exportables dans des fichiers séparés.

Par exemple dans MyBase.dll on a :
CMyBaseWinApp dans son MyBaseWinApp.h
CMyBaseMainFrame dans son MyBaseMainFrame.h
CMyBaseDocument dans son MyBaseDocument.h
etc...

Et ensuite réunir l'ensemble de ces includes dans un seul fichier MyBase.h comme

Code:

---

1 2 3 4 5 6 7

// MyBase.h #pragma once #include "MyBaseWinApp.h" #include "MyBaseMainFrame.h" #include "MyBaseDocument.h" etc

---

Idem pour la dll MyExtend.dll

Au final pour ce qui est des includes nous n'avons que 2 fichiers MyBase.h et MyExtend.h

3. Paramétrages des output des projets
Ici il est maintenant question de paramétrer les sorties des projets de votre solution.
Vous devez vérifier ou configurer vos projets de manière à ce que leurs output soient produits aux mêmes endroits. Afin d'éviter à un projet de réclamer un output dont il dépend (par exemple une librairie qu'il ne voit pas)
Dans les options de chaque projet il faut définit un output directory commun généralement General > Output Directory : votre répertoire (debug)
Toujours dans les options Linker > Advanced > Import Library : le path de vos lib

4. Référencer les includes
Puisque MyExtend.dll dépend de MyBase.dll il faut inclure son unique fichier MyBase.h dans le stdAfx.h du projet MyExtend.dll

Code:

---

1 2 3 4

// stdAfx.h de MyExtend.dll ... #include "..\Mybase\MyBase.h"

---

Code:

---

1 2 3 4

// stdAfx.h de MySimpleApp.exe ... #include "..\Mybase\MyBase.h"

---

Code:

---

1 2 3 4 5

// stdAfx.h de MyPowerApp.exe ... #include "..\Mybase\MyBase.h" #include "..\MyExtend\MyExtend.h"

---

En effet le stdAfx.h est le meilleur endroit.

5. Référencer les librairies
Nous savons que les 4 projets sont dépendants dans l'ordre suivant
MyBase.dll > MyExtend.dll > MySimpleApp.exe > MyPowerApp.exe

pour MyExtend.dll
Linker > Input > Additional Dependencies : MyBase.lib

pour MySimpleApp.exe
Linker > Input > Additional Dependencies : MyBase.lib;

pour MyPowerApp.exe
Linker > Input > Additional Dependencies : MyBase.lib;MyExtend.lib


Bon je crois que je n'ai rien oublié. Compilez la solution, définissez le projet le projet de démarrage et lancer l'exécution de votre Power MFC Application!!!

Mon silence n'est pas dû à un oubli de cliquer sur le résolu, mais bien d'une réflexion, qui, je le vois aux messages riches précédents est partagée.

Tout d'abord, je tiens à remercier Bacelar et Gabrielly pour le temps passé à apporter une réponse précise et claire.

Je retiendrai de tout ceci que pour établir une bibliothèque statique partagée par tous (compilo divers et variés, voir avariés;)), il ne faut pas exporter des classes c++.

Maintenant, comme bien souvent, cette règle n'est pas une règle absolue, et pour une équipe qui développe dans le même environnement (même IDE ou même compilo), cela peut être envisagé. Dans ce cas toutefois, il faudra veiller à la bonne configuration des options de compilation (appel __cdecl, UNICODE ou pas, compatibilité des string, ...).

Pour ce qui est des bibliothèques partagées concernant les MFC, à moins que je dise une grosse bêtise et dans ce cas certains me corrigeront très certainement, comme il s'agit de MFC, elle ne concerne que Visual Studio, et rentrerait donc dans le cas n°2: une équipe avec le même compilo.

Au passage, Gabrielly, je garde ta réponse sous le coude: c'est presque digne d'un article complet. Toutefois, elle ne répond pas précisement, à mon besoin de bibliothèque statique.

Citation:

---

Je développe une application MFC. Pour un besoin d'installation pratique, il est impératif que cette application soit liée statiquement aux mfc.
Lors du développement, il est prévu de pouvoir réutiliser le code de certaines fonctions qui devront donc être placées dans une librairie statique. Ces fonctions utilisent parfois des classes MFC.

---

Qu'est-ce qui te contraint d'avoir une bibliothèque statique?
Les packages de redistribution des dlls VC++ sont disponibles.

Citation:

---

Envoyé par Gabrielly

Qu'est-ce qui te contraint d'avoir une bibliothèque statique?
Les packages de redistribution des dlls VC++ sont disponibles.

---

La contrainte est d'avoir un fichier executable point. Pas de dll, de fichier d'installation ou autre, juste l'utilitaire.

Citation:

---

A quoi servent les DLLs d'extension MFC?

---

A faire une architecture de plug-Ins bien plus rudimentaires que celles utilisant COM ou d'autres Framework comme MEF ou d'IoC.
Voir à implémenter des mécanismes de globalisation d'une application.

Donc, ça ne va pas très loin. Surtout que l'exportation de classes C++ utilisant le Runtime MFC, ce qui réduit considérablement (et c'est un euphémisme) le spectre d'utilisation de celles-ci.

Citation:

---

La contrainte est d'avoir un fichier executable point. Pas de dll, de fichier d'installation ou autre, juste l'utilitaire.

---

C'est le genre de contrainte qui ne tient pas vraiment la route. Un exécutable dépend toujours de quelque chose, à moins de faire un driver BIOS. :aie:
Sous Windows (mode user, sous-système Win32), vous dépendrez toujours de kernel32.dll.
Les utilitaires de génération de MSI et WindowsInstaller permettent de facilement installer, de manière fiable, des applications, même les plus complexes.

Si vous insistez, vérifiez donc les options de compilations des différents projets pour qu'ils soient compatibles. Référez vous à mes remarques dans mon premier post.

Citation:

---

A faire une architecture de plug-Ins bien plus rudimentaires que celles utilisant COM ou d'autres Framework comme MEF ou d'IoC.
Voir à implémenter des mécanismes de globalisation d'une application.

---

En quoi l'usage des dlls d'extension MFC est-elle rudimentaire? Et surtout par rapport à COM qui est d'une couche inférieure à celle des MFC.

Citation:

---

Donc, ça ne va pas très loin. Surtout que l'exportation de classes C++ utilisant le Runtime MFC, ce qui réduit considérablement (et c'est un euphémisme) le spectre d'utilisation de celles-ci.

---

Quelle est la techno (et si nous restons microsoftiens) qu'on ne peux pas empaqueter dans une dll MFC????
et ensuite l'exporter comme une classe MFC tout entière!!!!
et enfin l'intégrer de façon transparente dans une architecture document-vue des MFC???

S'il faut élargir le spectre d'utilisation dans l'usage des composants .NET qui sont récents par rapport aux MFC.

1. On peux par exemple développer en C++/CLI une dll .NET contenant des User Control comme une listview .NET, un webbrowser .NET, un DataGridView .NET, un ReportViewer .NET que j'appelle My.UI.Design.dll

2. Ensuite on développe une dll d'extension MFC contenant plusieurs CWinFormsView pour chacun des objets vues .NET. que j'appelle My.UI.Host.dll

3. Et enfin j'intégre cette dll d'extension MFC dans l'architecture des documents-vues MFC (par exemple une application MDI) où l'utilisateur final et même le développeur ne peut même pas s'imaginer que les belles de vues de .NET sont hoster par des childframes MFC d'une dll d'extension.

Et d'ailleurs la dll My.UI.Host.dll accompagner de My.UI.Design.dll peut servir tout celui qui veut rester dans les MFC pour deux objectifs principaux.
a) Bénéficier du support document vue des MFC
b) Bénéficier d'une expérience utilisateur enrichie que fournissent ces composants .NET.

Ainsi dire que l'on ne peut pas aller très loin et bien tu as tors. La plateforme MFC n'est pas aussi fermer que tu le penses.

Un développeur peut se passer des fonctionnalités d'impressions offert par la CView en hostant directement un ReportViewer dans une CWinFormsView.

C'est peut être dans la tête que le spectre n'est pas assez élargie.

[FAQ VC++]Comment exploiter efficacement l'exportation des classes C++

Citation:

---

Envoyé par Nicolas Bauland

Je retiendrai de tout ceci que pour établir une bibliothèque statique partagée par tous (compilo divers et variés, voir avariés;)), il ne faut pas exporter des classes c++.

---

il est tout de même possible de mettre des classes dans une bibliothèque statique qui soit instanciées par du code externe...
par contre tu parles de "compilateur divers et variés", si tu fais une .lib statique avec MFC elle ne sera pas exploitable avec d'autres compilateurs exception faite de Visual C++ de Microsoftt

Citation:

---

Envoyé par Nicolas Bauland

Lors du développement, il est prévu de pouvoir réutiliser le code de certaines fonctions qui devront donc être placées dans une librairie statique. Ces fonctions utilisent parfois des classes MFC.

---

J'essaie de comprendre :D :
1-tu veux faire une biblio statique qui utilise les MFC par exemple pour afficher des fenêtres , gérer un framework etc...
2-ce fichier .lib tu veux pouvoir l'exploiter avec d'autres compilateurs ( par exemple MinGW), faire un SDK en quelque sorte.
De telle sorte qu'un autre programmeur puisse appeler les fonctions et instancier des classes de cette bibliothèque ?

Je pense que cela ne fonctionnera pas parce que tu auras besoin/moi j'aurai besoin des fichiers .lib/.cpp des MFC livrés avec Visual Studio , par exemple si moi je veux faire un projet avec ton fichier .lib.
D'ou le message d'erreur de classes non trouvées

Citation:

---

Envoyé par Nicolas Bauland

Pour ce qui est des bibliothèques partagées concernant les MFC, à moins que je dise une grosse bêtise et dans ce cas certains me corrigeront très certainement, comme il s'agit de MFC, elle ne concerne que Visual Studio, et rentrerait donc dans le cas n°2: une équipe avec le même compilo.

---

absolument ; sauf si tu distribues le code source des MFC pour être exploité par un autre compilateur ce qui est interdit par Microsoft :mrgreen:
Par exemple avec Watcom C++( qui n'existe plus) on pouvait faire aussi des projets MFC parce que le code source MFC était livré avec.

Citation:

---

Envoyé par bacelar

C'est le genre de contrainte qui ne tient pas vraiment la route. Un exécutable dépend toujours de quelque chose, à moins de faire un driver BIOS. :aie:
Sous Windows (mode user, sous-système Win32), vous dépendrez toujours de kernel32.dll.

---

non il voulait simplement dire qu'il ne veut pas être dépendant des runtimes dll MFC

Citation:

---

Envoyé par Gabrielly

Qu'est-ce qui te contraint d'avoir une bibliothèque statique?
Les packages de redistribution des dlls VC++ sont disponibles.

---

si cette bibliothèque statique encapsule les MFC ou bien fait appel aux MFC ce n'est pas possible de l'exploiter autrement qu'avec VC++.
Parce que dans cette bibliothèque statique, les appels à des méthodes et les références pointent sur le code source MFC.

Citation:

---

En quoi l'usage des dlls d'extension MFC est-elle rudimentaire? Et surtout par rapport à COM qui est d'une couche inférieure à celle des MFC.

---

"d'une couche inférieure", oui mais langage agnostique, avec des conceptions objets bien plus sophistiquées, comme l'agrégation, les Monikers, les types autodescriptifs via les TLB, le late-binding (ancêtre de la reflection), DCOM pour les applications réparties, etc...

<MODE PAULO LA SCIENCE> Les MFC sont antérieure à COM de près de 10 ans :aie:</MODE PAULO LA SCIENCE>

dlls d'extension MFC rudimentaire : OUI.:aie:

Citation:

---

et enfin l'intégrer de façon transparente dans une architecture document-vue des MFC

---

Bin oui, mais si je veux utiliser une application Qt, WPF, Win32, je fais comment. :aie:

Citation:

---

C'est peut être dans la tête que le spectre n'est pas assez élargie.

---

Je suis peut-être un peu borné, mais une application MFC est très, mais très loin d'être le Framework de Hosting graphique ultime.
Pas de composition d'application par IoC ou fichier de configuration, pas de programmation par aspect (pour les logs pas exemple). Etc…
Réduire l'utilisation d'un composant logiciel à être hébergé dans une application MFC ets, pour moi, rédhibitoire.

Citation:

---

Envoyé par bacelar

<MODE PAULO LA SCIENCE> Les MFC sont antérieure à COM de près de 10 ans </MODE PAULO LA SCIENCE>

---

Quelques extraits :

http://fr.wikipedia.org/wiki/MFC

Citation:

---

La Microsoft Foundation Class (MFC) est une bibliothèque de classes en C++ encapsulant l'API Win32 (écrite en C) de Windows. Sa première apparition date de 1992. Elle offre également un framework de développement de type Document/Vue inspirée du motif de conception modèle-Vue-Contrôleur (MVC).

---

http://fr.wikipedia.org/wiki/Component_Object_Model

Citation:

---

Pour COM : La précédente technologie Microsoft orientée objet fut Object Linking and Embedding (OLE) 1.0, qui a été construit sur les Dynamic Data Exchange (DDE) et spécifiquement conçus pour les documents composés (par exemple lorsqu'un tableau est inséré dans un document Word). Des changements opérés sur le tableau Excel seront propagés dans le document Word. Cela fut introduit par Word et Excel en 1991 et dans Windows 3.1 un an plus tard. De même en 1991, Microsoft introduisit les contrôles Visual Basic, ou VBX grâce à Visual Basic 1.0.

---

Donc COM (OLE) a vu le jour avant MFC.

Citation:

---

Citation:
et enfin l'intégrer de façon transparente dans une architecture document-vue des MFC

Bin oui, mais si je veux utiliser une application Qt, WPF, Win32, je fais comment.

---

-Les MFC sont une enveloppe des Win32 donc une surcouche (Il suffit d'examiner simplement les sources)
-Pour Qt cette techno est non Microsoft donc ça ne m'intéresse pas.
-Pour WPF, eh bien je suis ravi de te dire que cette matiné tu m'as poussé à connaitre WPF. Et j'ai le plaisir de t'annoncer que j'ai devant moi une application MFC qui intégre bel et bien des composants WPF dans ses childframes. Et donc WPF n'est pas exclus.

Voici la petite cuisine :
Une solution MFC_WPF composé de trois projets
1. Un Projet C# HostingWpfUserControlInWf WPF User Control Library où Je design mon user control WPF
2. Un Projet C++/CLI WpfUserControlHost Windows Forms Control Library où j'inclus dans la surface de mon user control un System::Windows::Forms::Integration::ElementHost
3. Un Projet MFC SDI MfcPowerHost MFC Application de type SDI dont la classe CView est remplacé par une CWinFormsView

Quelles résultat :mouarf:
Je vais balancer ça dans ma contribution à la faq VC++ ;)

Citation:

---

Je suis peut-être un peu borné, mais une application MFC est très, mais très loin d'être le Framework de Hosting graphique ultime.

---

J'ai pas dit que les MFC est l'ultime Framework de Hosting Graphique mais plutôt qu'on peut hoster des composants ( et en particulier Microsoft ) dans des fenêtres MFC.

http://pics.imagup.com/member4/1289312302_MFC_WPF.jpg
http://pics.imagup.com/member4/1289312519_MFC_WPF2.jpg

J'adore les MFC :mouarf:

[FAQ VC++]Comment héberger des Windows Forms Controls dans des vues MFC?

[FAQ VC++]Quelle est la clé d'intégration de la technologie WPF dans les MFC?
:D

Excusez de revenir sur le thread mais je suis tellement émerveillé :mrgreen: je viens de créer un player WPF hoster dans les MFC à partir d'une source XAML

[FAQ VC++]Comment consommer du XAML dans une application MFC?

Vive les MFC
:D

Citation:

---

Donc COM (OLE) a vu le jour avant MFC.

---

Là vous êtes très mal honnête.
OLE n'est pas COM.

Par analogie avec les MFC.
MFC 1.0 est une surcouche à Win16 (1992)
MFC 2.1 est une surcouche à Win32 (1993)

OLE 1.0 utilise DDE (1992)
OLE 2.0 utilise COM (1994)

si COM = OLE 1.0 alors Win32 = MFC 1.0.
Si qui, vous me l'accorder est absolument faux.

1992 < 1994 donc COM est plus récent que les MFC.

Les MFC n'était qu'une simple bibliothèque graphiques, bien faible devant sa concurrente directe OWL, avec d'immondes hacks comme des table de routage de message utilisant des pointeurs de fonction non typé ou la quasi absence de méthodes virtuelles dans ses classes pour des problèmes de taille mémoire des objets, important en Win16 mais bien futile sous Win32/Win64 et 4Go de RAM.

COM était d'une conception bien plus avancé et totalement novatrice (avec CORBA comme prédécesseur tout de même).

Il y a 2-3 ans d'écart entre les deux sorties, mais d'un point de vue conception, il y a au moins une décennie.

Mes explications suivante vont montrez cet écart en utilisant vos propres exemples.

Citation:

---

-Les MFC sont une enveloppe des Win32 donc une surcouche (Il suffit d'examiner simplement les sources)

---

Le routage des WM_COMMAND, la sérialisation des objets etc... n'ont aucun rapport avec un quelconque concept Win32. Et que dire de afxbeginthreadex ou autre AFX_MANAGE_STATE, toute une tambouille dont les MFC ont le secret.

Citation:

---

-Pour Qt cette techno est non Microsoft donc ça ne m'intéresse pas.

---

Merci pour les autres, mais il n'y a pas que Microsoft qui fait des choses sous Windows.

Citation:

---

-Pour WPF, eh bien je suis ravi de te dire que cette matiné tu m'as poussé à connaitre WPF. Et j'ai le plaisir de t'annoncer que j'ai devant moi une application MFC qui intégre bel et bien des composants WPF dans ses childframes. Et donc WPF n'est pas exclus.

---

Oui, et comment le lien entre WPF/Winforms et MFC est-il fait ?
Avec vos chères exports C++ et autre AFX_EXT_CLASS ?

Vous êtes étonné par la facilité d'intégration, mais vous la devez aux concepts initiés par COM et pas au MFC, comme des types auto-descriptifs via méta-données ou l'aggregation pour implémenter des proxys transparents etc. . Il est aussi simple d'intégrer des classes .NET dans une application NON MFC, du moment que le framework de développement supporte COM.

CWinFormsView colle des adhérences à la version dynamiques des MFC, encore une fois, ce n’est pas propre comme intégration.

Maintenant que vous connaissez WPF, essayez de n'utiliser que WPF.
Vous verrez que vous ne serez pas nostalgique des MFC.