WIN32 TOOL KIT MFC LIKE + CHANGER LANGUAGE APPLI + PARSERS (XML, RESOURCE.H)
Hellaynnea
Messages postés
57
Date d'inscription
samedi 14 décembre 2002
Statut
Membre
Dernière intervention
2 mai 2005
-
24 févr. 2004 à 21:54
MaX271 Messages postés 4 Date d'inscription mercredi 19 octobre 2005 Statut Membre Dernière intervention 21 mars 2006 - 2 juil. 2006 à 17:26
MaX271 Messages postés 4 Date d'inscription mercredi 19 octobre 2005 Statut Membre Dernière intervention 21 mars 2006 - 2 juil. 2006 à 17:26
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/20639-win32-tool-kit-mfc-like-changer-language-appli-parsers-xml-resource-h
https://codes-sources.commentcamarche.net/source/20639-win32-tool-kit-mfc-like-changer-language-appli-parsers-xml-resource-h
2 juil. 2006 à 17:26
c'est tout à fait le genre de trus qui simplifient bcp le C/C++!
j'ai pas encore tt regardé, mais ca m'intéresse bcp...
11 janv. 2005 à 19:53
11 janv. 2005 à 19:52
10 janv. 2005 à 19:57
pour la doc, j'ai bien décrit en haut de la source.
Pour le xml (like), j'en avais jamais fait et depuis j'en met partout dans mes projet.
++
10 janv. 2005 à 16:28
Mais pour mon prog, ( Polyglotte ) C'était basique lol, c'est plus développé mais j'vais vraiment regarder ça de pres ;) et jte dis quoi ;)
Bonne journée ;)
10 janv. 2005 à 14:50
on découvre des petites merveilles en suivant des liens parfois
bravo pour cette source, très complète
Pour la traduction, pourquoi du xml plutot que du .ini?
Pour le reste, il faudrait que je m'y plonge....
ça a l'air très bien.
un seul regret:
une petite doc d'utilisation serait la bienvenue...
++
Nono.
2 mars 2004 à 00:13
2 mars 2004 à 00:10
Sinon maintenant on peut associer des fonctions a des événéments (ca reste encore basique mais ca va bientot etre amélioré) et on peut créer soit mm les boutons qu'on veut (il faut que j'implémente ca bien parce que la c'est un peu crade)
++
2 mars 2004 à 00:03
Si t'implémentes la gestion de signaux et de slots là ça pourra devenir super je pense ;)
Juste pour info, ça pourrait te servir, il existe déjà plusieurs librairies crées exprès pour ça, t'as libsigc++ ou une autre, je crois que c'est SigSlots, un truc du genre, c'est expliqué dans un Linux Magazine par le créateur de la lib :)
Ensuite, pour ce qui est de l'éditeur de ressources, je pense que le mieux (mais bon faut pas trop rêver...), ce serait ton propre concepteur d'interface, que d'ailleurs tu programmerais en utilisant ta lib ;)
Ce serait un prog externe du genre de Glade, ou de VB, que tu utiliserais pour créer l'interface graphique; ensuite tu généres le code C++ correspondant, que tu utilises ensuite toi-même.
Mais bon, c'est un gros travail je pense...
Enfin pour ce qui est du linkage en statique, je sais bien qu'il suffirait de recompiler en .lib les fichiers commençant par C, mais je pense que tu serais mieux organisé si dans un même workspace tu mettais 2 projets, un étant la lib, et l'autre étant le projet exemple, qui dépendrait de l'autre projet.
Enfin, un truc : je pense que le meilleur toolkit est celui qui permet de faire le + de choses en le - de lignes, donc je pense que laisser la possibilité de dériver une classe genre CButton pour se créer un type de bouton particulier par exemple, est une bonne idée, mais qu'il faut éviter de le rendre obligatoire.
Je pense à des toolkits genre wxWindows où on est obligés de dériver wxWindow pour se créer une fenêtre bien à soi. Je trouve que ça fait écrire des lignes en trop.
Voilà, et bonne chance ;)
++
28 févr. 2004 à 17:51
> hum je travaille la dessus justement, ca me dérange aussi mais >pour l'instant j'avais pas le temps de me pencher dessus >sérieusement, j'ai commencé par faire des objets permettant de >manipuler plus facilement les interfaces
Aussi, un truc que franchement j'aime pas (dsl...) : quand on produit un prog il est dépendant de fichiers externes, les fichiers .lang (on peut s'en passer de toutes façons non?) et surtout le fichier ressource.h; le fait de le parser au "runnage" de l'appli, je trouve que ça fait pas propre...
> pour ces fichiers aucun d'eux n'est obligatoire, c'est un plus pour >pouvoir par exemple traduire ton appli pour les resources, c pour
> utiliser des id d'objets dynamiques, comme j'utilise visual 6.0
> ils régénère le fichier à chaque fois que tu saves et parfois les id
> changent alors pour éviter d'avoir a checker j'ai fait un petit parseur >de fichiers de resources resource.h
Ensuite, faudrait que tu divises le projet en 2 parties : d'un côté la lib et de l'autre le prog exemple, parce que là le linker met tout statiquement dans le prog exemple, même ce qu'il n'utilise pas (enfin il me semble...), je dis ça au vu de la taille finale, 292 Ko. Sinon y'aurait aussi la possibilité de compiler soit en static soit que l'exe fasse une référence à une DLL.
>pour les deux parties, la seule chose c'est le main qui contient >l'exemple ! le projet en lui mm est constitué de tout ce qui >commence par Cxxx : CMutex, CMouse,...
Ensuite, au niveau de ta WinProc, ce qui serait super ce serait de faire un système pour connecter les signaux aux slots, ou un système de callbacks. Je parle d'un système comme utilisent GTK+ ou Qt. Un truc genre :
void OnMonBoutonClick(void* data);
...
mon_bouton->Connect(SIGNAL_CLICK, OnMonBoutonClick, NULL); // où NULL est le paramètre qui est passé à OnMonBoutonClick.
et ensuite à chaque clic sur le bouton OnMonBoutonClick() s'exécute...
Pour implémenter ça, tu utiliserais un tableau de pointeurs de fonctions membre de ta classe CEventReceiver, dont dériveraient tous les widgets (fenêtre, boutons...etc).
C'est un exemple, mais c'est ce qui est utilisé dans la plupart des toolkits et ça simplifie vachement je trouve.
> hum pas mal comme idée fo que j'y pense, seulement il faut
> d'abord que j'implémente les callbacks et j'ai pas trop de temps en > ce moment, mais j'aime bien l'idée :)
> jve bien faire une dll ca me pose pas de problème, seulement il
> faut que je sortes CMutex et CMouse (que j'avais mises la comme >ca) il faut que je réunisse dans une callback tous les évents qu'on
> peut retrouver
> bon jcrois que je vais m'y mettre cet après midi ca m'intéresse :d)
> seulement it remains a problem, c'est pour le desing des resources, > on est toujours dépendant des editeurs de resources, mais si on
> regarde bien la source de mon prog, on peut modifier la position et > la taille d'un bouton, il faudrait juste que j'étende l'utilisation des
> fichiers de conf pour pouvoir dès le début mettre les attributs des
> objets, seulement les construire réellement me demanderaient pas >mal de temps, pour l'instant je suis obligé de laisser ca tel quel, a >moins qu'une bonne ame ... :) mais bon jme fais pas d'illusions
> étant donné que tu es le seul (et je t'en remercie) a avoir regardé >le code
Enfin dernier truc, c'est pour le nom de ton toolkit que je trouve franchement....ben.....banal quoi :p
> oui c vrai :) mais le nom on s'en fout un peu :) c t pour que ca
> fasse suggestif qu'on sache a quoi ca sert au pire jle changerait >apres
Je tiens à préciser que le but de ces critiques est uniquement d'être CONSTRUCTIVES, ne les prends pas mal stp ;)
Voilà, maintenant tu as mon avis ;)
> jte remercie pour ton avis, et j'accepte les critiques (bonnes ou >mauvaises) ca permet d'avancer, je vais dès maintenant me mettre >à ton idée de signaux et de pointeurs de fonctions pour la dll je >verrai une fois que tout sera fini
++
28 févr. 2004 à 15:38
Moi j'ai une bonne raison pour pas avoir posté de commentaires avant, mon PC marchait pas ^^
Mais là je viens de voir ça, de tester et tout et tout, et j'ai vu que c'était 211 Ko de code source....O_o
J'ai regardé un peu comment c'est foutu : personnellement je préfère quand j'utilise un toolkit qu'il ne soit pas dépendant de l'éditeur de ressources, et qu'il y ait le moins de code qui utilise l'API possible, même si c'est pas portable. Et là, quand on regarde main.cpp, on voit que tu conserves encore la WinProc, alors que le but d'un toolkit en général c'est plutôt de la cacher...
Aussi, un truc que franchement j'aime pas (dsl...) : quand on produit un prog il est dépendant de fichiers externes, les fichiers .lang (on peut s'en passer de toutes façons non?) et surtout le fichier ressource.h; le fait de le parser au "runnage" de l'appli, je trouve que ça fait pas propre...
Ensuite, faudrait que tu divises le projet en 2 parties : d'un côté la lib et de l'autre le prog exemple, parce que là le linker met tout statiquement dans le prog exemple, même ce qu'il n'utilise pas (enfin il me semble...), je dis ça au vu de la taille finale, 292 Ko. Sinon y'aurait aussi la possibilité de compiler soit en static soit que l'exe fasse une référence à une DLL.
Ensuite, au niveau de ta WinProc, ce qui serait super ce serait de faire un système pour connecter les signaux aux slots, ou un système de callbacks. Je parle d'un système comme utilisent GTK+ ou Qt. Un truc genre :
void OnMonBoutonClick(void* data);
...
mon_bouton->Connect(SIGNAL_CLICK, OnMonBoutonClick, NULL); // où NULL est le paramètre qui est passé à OnMonBoutonClick.
et ensuite à chaque clic sur le bouton OnMonBoutonClick() s'exécute...
Pour implémenter ça, tu utiliserais un tableau de pointeurs de fonctions membre de ta classe CEventReceiver, dont dériveraient tous les widgets (fenêtre, boutons...etc).
C'est un exemple, mais c'est ce qui est utilisé dans la plupart des toolkits et ça simplifie vachement je trouve.
Enfin dernier truc, c'est pour le nom de ton toolkit que je trouve franchement....ben.....banal quoi :p
Je tiens à préciser que le but de ces critiques est uniquement d'être CONSTRUCTIVES, ne les prends pas mal stp ;)
Voilà, maintenant tu as mon avis ;)
28 févr. 2004 à 00:02
Par contre vous pourrez toujours la trouver sur
http://hellaynnea.free.fr/programmation/c++/ => win32ToolKit prendre la dernière version en date (zip) vous pouvez voir les dernières updates dans le fichier win32ToolKit_Updates.txt
++
24 févr. 2004 à 21:54
la vocation du site c surtout pour apprendre
++