Discussion :

[RT222]

Bonjour,

Dans le cadre d'un de mes projets, je vais �tre amen� � utiliser les MFCs. Je souhaite d'abord les encapsuler dans des classes g�n�riques de ma conception afin de pouvoir proposer proprement et simplement d'autres impl�mentations avec des APIs diff�rentes si le besoin s'en fait sentir (comme le fait la SFML par exemple pour les diff�rents syst�mes qu'elle supporte, une m�me interface pour les impl�mentations Win/Mac/Unix).

Je me demande si les MFCs sont l'id�al pour �a. En effet, il s'agit d�j� d'une encapsulation de l'API Win32, et son architecture m'impose de nombreuses contraintes qui les rendent difficiles � impl�menter sous une interface g�n�rique (� cause des relations entres les diverses classes qui les composent entre autres). Mon plus gros probl�me est que les MFCs imposent d'utiliser une instance d�riv�e de la classe CWinAppEx, qui sert alors de point d'entr�e au programme. J'ai donc encapsul� cette classe elle aussi, mais �a ne fonctionne pas car pour respecter le sch�ma usuel des MFCs, il faudrait que je d�clare une instance de CWinAppEx dans mon programme, en dehors de mon encapsulation, ce que je ne peux faire. En effet, je ne veux pas qu'il y ait du code MFC dans mon programme, ce code doit imp�rativement �tre isol� dans une librairie � part r�serv�e aux MFCs. Si je cr�� cette instance dans ma libraire MFC, j'ai droit � un "error LNK1561: entry point must be defined" � la compilation, et si j'utilise mon propre main dans le programme principal, je me tape une exception.

Y a t-il un moyen de contourner ce probl�me? Ou devrais-je plut�t envisager d'encapsuler l'API Win32 directement au lieu des MFCs?

Autre petite question qui n'a rien � voir, mais que je me permet de poser quand m�me car je ne vais pas ouvrir un nouveau topic pour si peu, quel est le nom exact d'une structure de donn�e statique de ce genre en c++? N'y a t-il pas un moyen plus propre en C++ d'�crire ce genre de chose?

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
struct Param 
{
	const std::wstring	section;
	const std::wstring	entry;
	const std::wstring	value;
};
 
static Param	param_array[] =
{
	{ L"Display", L"ResX", L"1680" },
	{ L"Display", L"ResY", L"1050" },
	{ L"Display", L"BitDepth", L"32" },
	{ L"", L"", L"" },
};

Merci d'avance.

[TheGzD]

Bonjour,

Le soucis que tu rencontres doit venir des messages Windows. En effet pour que ton interface fonctionne il faut que ton application soit apte � recevoir les messages du syst�me (transmis aussi par l'UI), or lorsque tu encapsules la classe CWinAppEx tu casses le chainage entre la partie MFC de ton programme et le syst�me. Ceci est li� au fonctionnement de l'API Win32, donc MFC ou pas tu auras � mon humble avis � composer avec si tu veux d�velopper sous Windows. Sauf si tu optes pour une autre API graphique comme Qt qui rajoute une couche d'abstraction suppl�mentaire. Concernant le fonctionnement des messages sous Windows, tu pourras en savoir plus en consultant la MSDN.

Pour en revenir � ton probl�mes et essayer de t'en sortir je vois 2 possibilit�s :
- soit la couche MFC encapsule ton programme, et le chainage des messages est fait pour toi
- soit tu r�impl�mentes un pompe � message dans ta classe perso qui les retransmet � la partie MFC encapsul�e dans ton programme

Bon courage

[RT222]

Pas de QT pour moi. Ca me faciliterait certes la t�che au plus haut point, mais je tiens � rester au plus bas niveau possible.

Sinon, je me doutais que j'allais gal�rer avec les messages, mais malheureusement je n'en �tais m�me pas l�. Apr�s relecture de mon premier post, je me rends compte que j'ai �t� tout sauf clair dans la description de mon probl�me, et je m'en excuse. Je vous reformule donc �a plus clairement :

Je suis en train d'encapsuler les MFCs dans une librairie � part, destin�e � �tre link�e � mon projet principal. Le probl�me c'est que lorsque je d�clarais mon main dans ce dernier, il supplantait syst�matiquement le point d'entr�e des MFCs, alors que j'aurais voulu que ce soit le contraire qui se passe, les MFCs ne fonctionnant pas si l'on surplante leur point d'entr�e.

J'utilise l'imparfait parce qu'apr�s une bonne semaine de recherches et tests laborieux, j'ai enfin trouv� une solution qui fonctionne!

Je vous envoie en pi�ce jointe ma solution (pour Visual Studio 2010). J'ai �dulcor� le projet pour ne garder que le code en rapport avec mon probl�me, il est donc normal que �a soit tr�s succin. La solution contient trois projets :
-System_Abstraction : Ce projet (destin� � �tre compil� en tant que libraire) fourni une classe g�n�rique (classe Main) qui sera celle � laquelle on pourra avoir acc�s publiquement. Il contient en outre une interface (Main_Impl) qui est celle que devront respecter toutes les impl�mentations sp�cialis�es de cette libraire.
-System_MFC : Est lui aussi compil� en tant que librairie, et se charge de fournir l'impl�mentation MFC (classe Main_MFC) � partir de l'interface fournie par System_Abstraction.
-System_Test : Celui l� ne sert juste qu'� tester le bon fonctionnement de ma lib MFC et ne contient qu'un b�te main.

Le sch�ma suivit ici est directement inspir� de celui employ� par la SFML, dont le code source m'aura d�cid�ment appris bien des choses.

Ce qui se passe lors de l'ex�cution du projet :
Gr�ce � la globale un peu particuli�re d�finie dans main.h (autostart), la fonction pre_main est appel�e avant toute autre fonction (un grand merci � l'auteur de cet article). Elle cr�� alors une instance de la classe Main_MFC (qui est ma classe d�riv�e de CWinAppEx), qui sert ensuite de point d'entr�e au programme. Apr�s que le programme soit pass� par le point d'entr�e des MFCs, on � la fonction Run de la classe CWinAppEx que j'ai surcharg�e pour qu'elle appelle le main d�fini par l'utilisateur de la librairie. Tout est donc parfait et mes trois objectifs principaux sont remplis : les MFCs sont initialis�es correctement et fonctionnent parfaitement, le code accessible � l'ext�rieur de ma librairie est enti�rement g�n�rique et ne fait aucune mention aux MFCs, et l'utilisateur de la librairie peut red�finir son propre main sans probl�me.

Quelques point suppl�mentaires pour justifier ma solution :
-Les MFCs plantent syst�matiquement si l'on utilise un point d'entr�e personnalis�, il �tait donc imp�ratif de faire passer le point d'entr�e d�fini par l'utilisateur de la librairie apr�s celui des MFCs.
-Il n'y a pas moyen de faire instancier ma classe Main_MFC par l'utilisateur de la librairie, car si j'autorise le code de ce dernier � s�ex�cuter en premier, le programme ne passera jamais par le point d'entr�e des MFCs et on en revient au probl�me d�crit juste au dessus.
-J'aurais pu tout simplement d�clarer une instance de Main_MFC dans main.hpp, mais ce serait briser l'encapsulation d�sir�e des MFCs. En effet, main.hpp sera le seul header auquel on aura acc�s � l'ext�rieur de la lib, il ne doit donc contenir que du code g�n�rique sans rapport aucun avec l'impl�mentation sous-jacente!
-D�clarer une instance globale de Main_MFC dans ma librairie System_MFC ne suffit pas, car dans ce cas, le main d�fini par l'utilisateur de la lib surplante le point d'entr�e des MFCs.


Cependant, je suis persuad� qu'il y a largement moyen de faire �a de mani�re plus simple et plus propre, j�esp�re donc que quelqu'un jettera un �il � mon projet afin de m'aider � am�liorer mon code.

[Mat.M]

Bonjour,

Dans le cadre d'un de mes projets, je vais �tre amen� � utiliser les MFCs. Je souhaite d'abord les encapsuler dans des classes g�n�riques de ma conception afin de pouvoir proposer proprement et simplement d'autres impl�mentations avec des APIs diff�rentes si le besoin s'en fait sentir (comme le fait la SFML par exemple pour les diff�rents syst�mes qu'elle supporte, une m�me interface pour les impl�mentations Win/Mac/Unix).

pourquoi encapsuler les MFC dans des classes g�n�riques ??
MFC c'est sp�cifique � Microsoft, pas portable.
Par contre tu as le code source
Ce que tu veux faire c'est interdit parce que tu veux redistribuer les classes.

. Mon plus gros probl�me est que les MFCs imposent d'utiliser une instance d�riv�e de la classe CWinAppEx, qui sert alors de point d'entr�e au programme. J'ai donc encapsul� cette classe elle aussi, mais �a ne fonctionne pas car pour respecter le sch�ma usuel des MFCs, i

la classe de base c'est CObject et non CWinAppEx dans la hi�rarchie

l faudrait que je d�clare une instance de CWinAppEx dans mon programme, en dehors de mon encapsulation, ce que je ne peux faire. En effet, je ne veux pas qu'il y ait du code MFC dans mon programme, ce code doit imp�rativement �tre isol� dans une librairie � part r�serv�e aux MFCs.

je ne vois int�r�t � faire cela;
les MFC c'est en grande partie pour faire des applis fen�tr�es.
Tu peux tr�s bien faire des classes de fen�tre en win32 ce n'est pas si compliqu� que �a..

Y a t-il un moyen de contourner ce probl�me? Ou devrais-je plut�t envisager d'encapsuler l'API Win32 directement au lieu des MFCs?

oui et �a sera bien plus simple ; par exemple si tu veux faire une classe de ListBox , tu d�clares une classe de ListBox et dans le constructeur tu appelles CreateWindow()
Par contre c'est vrai que pour la gestion des messages �a risque d'�tre un peu probl�matique