Discussion :

[Nico28]

Bonjour.

Excusez si je suis pas sur le bon forum, mais je pense que les modérateurs me déplacerons si nécessaire.

Voilà mon soucis. Je développe en C++ (Visual Studio) mais je perd beaucoup trop de temps sur les les interfaces en travaillant avec les MFCs.

Quelles sont les alternatives possibles ? (QT, GTK, ?).

Je veux dessiner des fenêtres, des boutons avec éventuellement des icones dedans et pouvoir changer la police de caractères, mettre des labels plus stylisés que les CStatic de base, bref des trucs plus funs.
Mais quand je travaille avec les MFC, je passe plus de temps à tenter de comprendre les mécanismes MFC qu'a m'occuper des réelles fonctionnalités de mon application (applications industrielles + traitements d'images).

Au risque d'en faire hurler certain, je développe des applications et pas du code pour du bouton. Ne prenez pas cela mal mais la réalité fait que pour être productif, je ne dispose pas de temps pour développer des jolis boutons. Je développe des algorithmes et des fonctions de traitements d'images (C, C++), je suis bon dans ma partie, mais passer des heures pour changer la taille et la couleur de la police de caractères dans un champ pour afficher un résultat, je trouve cela un peu dommage.

J'espérais que dans sa version 2008, Microsoft aurait intégré des labels, des boutons et des listes aussi facile à utiliser qu'en VB6 mais ce n'est pas le cas.

Alors où puis-je trouver mon bonheur ? QT, GTK, ou autres ...

Merci d'avance.

PS : je développe des applications commerciales et je suis disposé à payer pour trouver LA librairie qui me convient.

[ram-0000]

Je pense que quelleque soit la librairie que tu vas prendre, il te faudra un temps d'apprentissage.

Il y a maintenant quelques années que je pratique les MFC, je ne connais pas les autres libraries par fénéantise probablement car je n'ai pas envie de recommencer à apprendre mais je me trompe peut être.

Une fois que la philosophie des MFC est comprise, c'est plus facile mais c'est vrai qu'il faut du temps.

Un des avantages que je voie aux MFC, c'est qu'elles sont particulièrement bien intégrées à Visual Studio (éditeur de ressource, lien direct entre les classe et les dialogues, fonction des classes connues par l'environnement, ...

Deux excellents livres pour aller plus vite :
- le petzold pour comprendre les mécanismes de Windows (http://www.charlespetzold.com/oop/pw3.html)
- Programming Windows with MFC (http://www.microsoft.com/MSPress/books/1431.aspx)

[zabibof]

Personnellement, j'utilise wxWidgets et je trouve ça très bien , QT est pas mal aussi mais j'ai pas encore essayé.

Je pense que quelque soit la librairie que tu vas prendre, il te faudra un temps d'apprentissage.

+1

[Mat.M]

J'espérais que dans sa version 2008, Microsoft aurait intégré des labels, des boutons et des listes aussi facile à utiliser qu'en VB6 mais ce n'est pas le cas.

Alors où puis-je trouver mon bonheur ? QT, GTK, ou autres ...

Merci d'avance.

PS : je développe des applications commerciales et je suis disposé à payer pour trouver LA librairie qui me convient.

Je crois que tu te trompes totalement ! MFC a beaucoup de défaults mais toute la facilité de VB6 de jadis tu la perds dans bcp d'inconvénients de VB6.
Quant à Qt , GTK que je ne connais pas l'avantage de Qt c'est que c'est portable peut-être plus facile que MFC mais je ne sais pas si Qt s'intègre parfaitement avec la win32.
J'avais tenté de faire un projet avec la VCL et BCB je me suis arraché les cheveux de la tête pour faire des choses plus simplement avec MFC même si le code est plus lourdingue avec MFC.

Quel est ton type de projet ?

Mais quand je travaille avec les MFC, je passe plus de temps à tenter de comprendre les mécanismes MFC qu'a m'occuper des réelles fonctionnalités de mon application (applications industrielles + traitements d'images).

C'est pour une appli de traitement d'image ? Appli industrielle ?
Je déconseille les autres classes je ne sais pas si elles s'intégreront bien à moins de vouloir la portabilité à tout prix.

[Nico28]

Les applications en traitements d'images peuvent être du genre "controle de conformité", "présence/absence", ... Mais là n'est pas le problème.
C'est plutôt lorsqu'il s'agit de l'interface Homme/Machine.
Exemple :
Modifier la couleur de fond et le type de la police d'une case à cocher en fonction d'un résultat d'analyse.

Tant que tu n'as pas développé tes propres classes (ex : une case à cocher qui réponde à mes besoins), le développement est très long.

Et comme il me faut une multitude d'éléments d'interfaces, j'ai l'impresssion d'être face à une montagne de code à écrire, et ce code n'a rien à voir avec la fonction première de mon application.

EN cherchant sur différents sites de codes sources, on trouve des choses (le meilleur et le pire), mais là aussi, il faut du temps pour chercher, comprendre ce que les autres ont fait (ou voulu faire) ...

Finalement, la série des activeX intégrés à VB6 m'aideraient bien dans certains cas. J'avais regardé la série des activeX FM20.dll , mais il est interdit des les distribuer (!!).

Je crois en final, que doucement, je vais développer mes propres classes ...

[10_GOTO_10]

J'avais tenté de faire un projet avec la VCL et BCB je me suis arraché les cheveux de la tête pour faire des choses plus simplement avec MFC même si le code est plus lourdingue avec MFC.

J'avoue ne pas bien comprendre cet argument. La VCL a des tas de défauts, on est d'accord. Mais pas celui-là. S'il y a un domaine où justement la VCL tire son épingle du jeu, c'est celui du développement rapide d'application puisque justement elle a été concue pour ça.

Le cas qui nous préoccupe est celui-ci:

Exemple :
Modifier la couleur de fond et le type de la police d'une case à cocher en fonction d'un résultat d'analyse.

Et je ne vois pas bien comment le code pourrait être plus simple:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
MyCheckBox->Font->Name = "Courier New";  // Par exemple
MyCheckBox->Color = clBlue;

Etant par ailleurs très impliqué dans l'évolution de cette librairie, je serais assez curieux de comprendre pourquoi certains (tu n'es pas le seul) la qualifie d'usine à gaz. Est-ce la VCL elle-même ou l'EDI ?

[moldavi]

Bonjour.

As-tu essayé les Windows forms ?

[Mat.M]

Etant très impliqué dans l'évolution de cette librairie, je serais assez curieux de comprendre pourquoi certains (tu n'es pas le seul) la qualifie d'usine à gaz. Est-ce la VCL elle-même ou l'EDI ?

Attention ! Je n'ai jamais écrit que je jugeais selon tes dires la VCL comme "une usine à gaz" , il ne faut pas me faire dire ce que je n'ai pas dit ou écrit !
La VCL est un excellent framework je préfère même la VCL de très loin à .NET par exemple.
J'avais bossé dans une boite sur Lyon un des projets était client/serveur avec une appli Borland C++ Builder en frontal donc avec la VCL c'est un excellent outil et ça fonctionnait parfaitement bien.
De même que j'ai bossé dans une banque sur Paris j'ai du migrer un projet Delphi vers VB6 évidemment sous VB6 c'était merd..que
Maintenant si tu veux sortir des courbes faire du tracé graphique utiliser des HDC accéder au GDI plus aisément ce sera bien plus facile avec MFC..
Avec MFC tu peux faire des CScrollView avec splitter des CTreeView etc...
Avec la VCL faire une CScrollView c'est plus difficile.
La VCL a mes yeux comme les classes Java comme le framework .NET c'est trop abstrait et propose trop d'abstraction pour pouvoir utiliser la quintessence du GDI ou même les controles utilisateurs..
Dans la VCL c'est un peu comme les classes Java tout est encapsulé et verrouillé tu ne peux toucher à rien.
Et puis le support des objets /technologie COM avec la VCL ça fonctionne pas toujours bien.
Et puis est-ce que la VCL supporte l'architecture Document/Vue comme avec MFC, la sérialisation des classes ??
Peut-être qu'avec la dernière version oui mais quand j'ai commencé avec C++ Builder c'était pas le cas.

Et je ne vois pas bien comment le code pourrait être plus simple:

C'est évident qu'avec MFC on tape plus de ligne de code et c'est un peu lourd parfois..
Mais je préfère de très loin MFC surtout pour faire des graphismes afficher des bitmaps etc..
Je possède Visual C++ et Borland C++ Builder et de très loin je préfère prendre MFC..
Tu ne fais pas toujours ce que tu veux avec les autres frameworks j'en sais quelque chose.
Cela signifie que les gens chez Microsoft sont stupides alors et qu'ils continuent à soutenir une bibliothèque compliquée...mais si tel est le cas c'est qu'ils ont leurs raisons pour le faire..

[unmanos]

Haaa les MFC, Microsoft a arreter le support la dessus, c'est fini il faut passer a autre chose. Personnellement j'etais un fan des MFC sous VC6, mais depuis VC2002/2005 je trouve ca horrible!

Il existe pas mal de lib qui ont ete cite dans les posts precedent, personnellement quand j'ai besoin de faire ca je fais du C# (du vrai bonheur de faire une UI en C#, tres simple). Ensuite si tes algo sont en C++ il est tres simple de faire des interops C# / C++. Dans les 2 sens (genre ton prog C# qui apelle une fonction dans une DLL en C et qui prend en argument un pointeur de fonction pour le progress).

Par ex dans ta DLL declaration en C et implementation en C/C++:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
extern "C"
{
    typedef bool(__stdcall *ProgressCallBack)(int);
    __declspec(dllexport) void DoSomething(ProgressCallBack cb);
}

En C# ca donne:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
public class ManagedDLL
{
    public delegate bool ProgressCallBack(int percent_done);
    [DllImport("ManagedDLL")]
    public static extern void DoSomething(ProgressCallBack cb);
    [DllImport("ManagedDLL")]
}

De la tu peux apeller depuis C# ta fonction... Ca oblige a bien separer le fonctionnel de l'UI, ce qui n'est pas une mauvaise chose ^^ L'avantage du C# pour faire une UI, et l'avantage du C/C++ pour les algo performants. Que demande le peuple .

[Nico28]

Haaa les MFC, Microsoft a arreter le support la dessus, c'est fini il faut passer a autre chose. Personnellement j'etais un fan des MFC sous VC6, mais depuis VC2002/2005 je trouve ca horrible!

Il existe pas mal de lib qui ont ete cite dans les posts precedent, personnellement quand j'ai besoin de faire ca je fais du C# (du vrai bonheur de faire une UI en C#, tres simple). Ensuite si tes algo sont en C++ il est tres simple de faire des interops C# / C++. Dans les 2 sens (genre ton prog C# qui apelle une fonction dans une DLL en C et qui prend en argument un pointeur de fonction pour le progress).

Par ex dans ta DLL declaration en C et implementation en C/C++:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
extern "C"
{
    typedef bool(__stdcall *ProgressCallBack)(int);
    __declspec(dllexport) void DoSomething(ProgressCallBack cb);
}

En C# ca donne:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
public class ManagedDLL
{
    public delegate bool ProgressCallBack(int percent_done);
    [DllImport("ManagedDLL")]
    public static extern void DoSomething(ProgressCallBack cb);
    [DllImport("ManagedDLL")]
}

De la tu peux apeller depuis C# ta fonction... Ca oblige a bien separer le fonctionnel de l'UI, ce qui n'est pas une mauvaise chose ^^ L'avantage du C# pour faire une UI, et l'avantage du C/C++ pour les algo performants. Que demande le peuple .

Et oui, je le fais sans soucis, mais dans certains, ce n'est pas possible :
- trop de CallBack sur des fonctions d'acquisition d'images
- trop de pointeur qui decraient être "global".
Alors il faut faire des Dlls qui apellent des Dlls.

Cela fonctionne, mais c'est un peu lourd à gérer. Après cela, la seconde galère, ce sont les librairies qui supportent le C6 ou VC2003 mais pas 2005 et encore moins 2008 ....

Un pas en avant, 2 pas en arrière.

Pour info, petite parenthèse, je suis allé à Paris chez Eyrolle. Les bouquins sur VC6 et VB6 sont réédités !!
Le rayon C# est bien fourni mais pour le reste C++/CLI, c'est pas top.
On a un peu l'impression que les nouvelles techno, ...

[Mat.M]

Haaa les MFC, Microsoft a arreter le support la dessus, c'est fini il faut passer a autre chose. Personnellement j'etais un fan des MFC sous VC6, mais depuis VC2002/2005 je trouve ca horrible!

Aaah nom d'une pipe, non Microsoft n'a pas du tout arrêté le support des MFC mieux que cela il les a enrichies en rachetant des librairies d'éditeur tierce.
Regarde un peu les blogs de Farscape il en parle

[unmanos]

Aaah nom d'une pipe, non Microsoft n'a pas du tout arrêté le support des MFC mieux que cela il les a enrichies en rachetant des librairies d'éditeur tierce.
Regarde un peu les blogs de Farscape il en parle

Yes autant pour moi... je ne savais pas qu'il avait releaser la ribbon que je regarderais de plus pres des demain. Merci.

Mais comment expliquer que le support des MFC est si mauvais depuis Visual 2005? Franchement ca donne vraiment l'impression qu'il s'en fouttent et qu'ils mettent le packet uniquement sur .net !

[Nico28]

Mais comment expliquer que le support des MFC est si mauvais depuis Visual 2005? Franchement ca donne vraiment l'impression qu'il s'en fouttent et qu'ils mettent le packet uniquement sur .net !

Là, je suis d'accord. Peu ou pas d'évolution. Aucune adaptation aux nouvelles demandes et besoins des utilisateurs.
On parle de développement rapide, de temps de programmation, bref, plein de termes savants, mais rien avance.
Si, C#. Mais beaucoup de fabricant de matériel ne fournissent pas et ne fourniront pas de bibliothèques adaptées. Pourquoi ? c'est peut-être la question à poser !!

[Médinoc]

Quelles sont, exactement, ces "adaptations aux nouvelles demandes" qui manquent ?

Je suis déjà bien content d'avoir la séparation de CString entre ANSI et Unicode!

[Mat.M]

Là, je suis d'accord. Peu ou pas d'évolution. Aucune adaptation aux nouvelles demandes et besoins des utilisateurs.
On parle de développement rapide, de temps de programmation, bref, plein de termes savants, mais rien avance.

Je n'arrive pas à comprendre ta remarque : rien n'avance .
Peux-tu plus développer ? Merci

Si, C#. Mais beaucoup de fabricant de matériel ne fournissent pas et ne fourniront pas de bibliothèques adaptées. Pourquoi ? c'est peut-être la question à poser !!

Euh fournir des biblios adaptées en C# ?
Eh bien je crois que l'explication la plus basique c'est qu'avec C# et .NET on ne peut pas accéder au bas-niveau du moins il n'est pas aisé de gérer des Device Drivers

[Mat.M]

Mais comment expliquer que le support des MFC est si mauvais depuis Visual 2005? Franchement ca donne vraiment l'impression qu'il s'en fouttent et qu'ils mettent le packet uniquement sur .net !

Oui tu as parfaitement raison ;Microsoft semble mettre le paquet sur .NET.
Ceci dans une optique marketing ?
Parce que le développement c'est aussi un marché/segment économique , que les MFC ça date vraiment et c'est vraiment pas ergonomique.
Ceci dit je trouve qu'il n'ya pas grand chose à améliorer aux MFC les classes assurent une bonne partie des devs que l'on souhaite réaliser.
Les lacunes c'est notamment la gestion des bitmaps et les images jpeg.
Sinon tu peux faire tout ce que tu veux avec MFC.
D'ailleurs d'une version VC++ à une autre tu remarqueras que les classes évoluent très très peu.
M'étonnerait pas que MFC de VC++6 = MFC de VC++ 4.0 à peu de choses près..
Et le gros avantage c'est que tu as peu de risques de rétrocompatibilité...contrairement à .NET
Si les MFC "font la job" comme on dit ici au Québec pourquoi changer quelque chose qui tourne bien ?

[unmanos]

Oui tu as parfaitement raison ;Microsoft semble mettre le paquet sur .NET.
Ceci dans une optique marketing ?
Parce que le développement c'est aussi un marché/segment économique , que les MFC ça date vraiment et c'est vraiment pas ergonomique.
Ceci dit je trouve qu'il n'ya pas grand chose à améliorer aux MFC les classes assurent une bonne partie des devs que l'on souhaite réaliser.
Les lacunes c'est notamment la gestion des bitmaps et les images jpeg.
Sinon tu peux faire tout ce que tu veux avec MFC.
D'ailleurs d'une version VC++ à une autre tu remarqueras que les classes évoluent très très peu.
M'étonnerait pas que MFC de VC++6 = MFC de VC++ 4.0 à peu de choses près..
Et le gros avantage c'est que tu as peu de risques de rétrocompatibilité...contrairement à .NET

Oui je suis d'accord que .NET est loin d'etre parfait. Quand ca a commence je m'etait passione surtout pour la CLR et j'avais meme commencer un VM (c'etait avant Mono). Je croyais que Microsoft avait enfin compris que les standards ouvert c'etait sympa. Mon reve c'etait de pouvoir faire du script en C# pour mon moteur de jeux. Helas... en deghors du format PE et des OpCodes pourri je me suis rendu compte que les standard de la CLR publie par MS via l'Ecma etait une facade. Et que meme un simple enum en C# fait des apells a la fameuse mscore.dll, qui elle est tres protegee par MS, et les apels sont non documentes (du moins a l'epoque ou j'avais fait ma VM, en 2002... ca a peut etre change depuis mais je ne penses pas).

La verite aussi c'est que pour le moment .NET rame un peu. Je me lancerais pas dans une enorme application (un editeur de monde monde example) avec ca. Mais pour les petites et moyennes appli avouons que c'est vraiment du bonheur, et je dirais que ca va au moins 10 fois plus vite que les MFC. Intelisense marche tout le temps, ...

Si les MFC "font la job" comme on dit ici au Québec pourquoi changer quelque chose qui tourne bien ?

C'est que moi j'aime bien les nouveaux trucs, ca me donne l'impression d'avoir toujours 20 ans ^^ J'en avait tellement marre des MFC que j'ai fini par faire ma propre UI en DirectX, vu que dans un moteur de JV il faut avoir une UI, c'etait pas forcemment beaucoup plus de boulot.