begin process at 2012 05 27 19:35:21
  Trouver un code source :
 
dans
 
Accueil > 

Code

 > 

API

 > WIN32 TOOL KIT MFC LIKE + CHANGER LANGUAGE APPLI + PARSERS (XML, RESOURCE.H)

WIN32 TOOL KIT MFC LIKE + CHANGER LANGUAGE APPLI + PARSERS (XML, RESOURCE.H)


 Information sur la source

Note :
9 / 10 - par 1 personne
9,00 / 10

  • 1

  • 2

  • 3

  • 4

  • 5

  • 6

  • 7

  • 8

  • 9

  • 10
Catégorie :API Niveau :Initié Date de création :21/02/2004 Date de mise à jour :27/02/2004 23:59:19 Vu / téléchargé :6 002 / 528

Auteur : Hellaynnea

Ecrire un message privé
Site perso
Commentaire sur cette source (13)
Ajouter un commentaire et/ou une note

 Description

je vais vous présenter cette source qui m'a prit la semaine a faire. Il s'agit d'un toolkit win32, donc un ensemble d'objets ou classes utiles qui vont vous permettre (d'apprendre pour ceux qui savent pas déja :) ) et de vous faciliter la vie avec les composants windows simples : listes, boutons, edit, check,... J'ai généré une documentation html de l'ensemble du kit par doxygen pour ceux que ca intéresse.
Classes utilisables :
---------------------
CEdit : edit boxes
CButton : boutons
CRadio : radio boutons
CCheck : check boxes (cases à cocher)
CList : list boxes
CCombo : combo boxes
CWindow : gestion des fenêtres et de tous les composants d'une fenêtre
CChild : gestion de fenêtres enfants
CSlider : gestion des sliders
CMouse : une petite classe regroupant les fonctions utiles de gestion souris
CXmlDocument : parseur de fichiers type Xml / Svg
CResourceFile : parseur de fichiers resources : resource.h
CLangFile : classe d'implémentation de différent langages des applications
CLangController : regroupe tous les languages possibles pour l'application
CController : template classe pour manipuler les map de classes facilement

=== Les éléments ===
Un élément est constitué d'un handle (HWND) et de l'id de celui-ci (ex. IDC_BUTTON1). De plus la plupart des items peuvent avoir un titre ou une icone. (ou un contenu unique pour les edit boxes par exemple) Dans les fichiers de configuration, on peut spécifier les icones/captions par défaut ou des index d'icones/captions pour les items qui peuvent changer : exemple un bouton qui peut faire : play->pause->stop. on créera 3 captions différents : play, pause et stop aux indexs 0,1,2 respectivement. Ces entrées seront reportées dans tous les fichiers de language traduits dans la langue correspondante. Certains items peuvent etres cochés, et enable|disable. Tout ceci peut etre reporté dans un fichier de configuration de fenêtre

=== CWindow ===
la classe regroupe tous lees éléments qu'on peut retrouver dans une fenêtre et la fenêtre elle même. Elle permet grâce à un ensemble de fonctions simples de passer toute une fenêtre (+items) de francais à anglais, etc... Il suffit d'un fichier de configuration de la fenêtre (ex : w1.win) qui contient tous les éléments de la fenêtre. Une CWindow peut être associée à un language controller. Ainsi on peut changer tous les items de la fenêtre selon les titres et icones du language. On peut alors spécifier les index des titres correspondant à ceux enregistrés dans les fichiers de language.
un item type :
<window id="100" caption="MaFenetre">
  <item id="1001" type="button" caption="mon_titre"/>
</window>

ou pour une icon :
<window id="100" caption="MaFenetre">
  <item id="1001" type="button" icon="c:\my_icon.ico"/>
</window>

pour spécifier les index (-1 <=> titre/icon par défaut)
<window id="100" caption="@1">
  <item id="1001" type="button" icon="@2"/>
</window>

=== CLangFiles ===
comme vu précédemment les CLangFiles représentent un language pour les items :
<language name="francais">
#pour les icones
  <item id="1001" type="button" icon="c:\my_icon.ico">    //icone par défaut
    <icon index="0" name="my_icon0.ico"/>
    <icon index="1" name="my_icon1.ico"/>
  </item>
#pour les captions
   <item id="1002" type="check" caption="MyCheckBox">    //caption par défaut
    <caption index="0" name="Check0"/>
    <caption index="1" name="Check1"/>
  </item>
#pour les fenêtres
  <item id="123" type="child" caption="MyWindow">
    <caption index="0" name="Window0"/>
    <caption index="0" name="Window1"/>
  </item>
</language>

il suffit de créer un langage file par language a utiliser puis de les ajouter au  ontroller. Controller->getLanguage(french) => const CLangFile * retourne un pointeur constant vers un language :)

=== ResourcesFiles ===
si on regarde les exemples on voit qu'il faut reporter à chaque fois les id des éléments. Les id se trouvent dans les fichiers de resources : ex, resource.h seulement comme ces fichiers sont générés automatiquement par visual lorsqu'on
dessine une fenêtre c'est assez pénible de tout tenir à jour. J'ai créé un parseur de fichiers de resources : une resource concrètement c'est une ligne :
#define IDC_BUTTON1 1001
l'id string = IDC_BUTTON et l'id integer = 1001
le parseur fait le lien entre les deux : parser->getID("IDC_BUTTON") => 1001
J'ai donc permis l'association entre les CResourcesFile et les CWindows, ainsi que les CLangFile. On peut alors remplacer les id brutes (1001) par les références au fichier de resource associé (IDC_BUTTON) pour ce faire un exemple dans le fichier de fenêtre :
#notre bouton :
<item id="#IDC_BUTTON" type="button" caption="@1"/>

Voila que demander de plus ?? :)
Je vous laisse découvrir toutes les fonctionnalités du toolkit (regardez le
main)
bonne lecture.



Source

  • tout est dans le zip, + qqs fichiers de language et de fenêtre pour comprendre la synthaxe
tout est dans le zip, + qqs fichiers de language et de fenêtre pour comprendre la synthaxe

 Conclusion

Bon je pense que la description est suffisante quand mm :)

Sinon pour ceux qui sont intéressés mon ftp free: http://hellaynnea.free.fr/programmation
ou ya tout plein de choses intéressantes, dans la partioe Doc, j'ai mais les schémas des automates des 2 parseurs : ResourceFile et xmlParser

Par ailleurs je n'arrive pas à changer le style d'un bouton lorsque la fenêtre a été créée : passer d'icone à caption et inversement.


Corrections :
[27/02/04]
- création de la classe template CController qui permet de gérer n'imorte quel type de list
> implémentation de CController dans le CLangController (modification de la
> structure)
> pourra être utilisé pour gérer plusieurs CWindow
- toutes les fonctions d'output ont été formatées en XML like, et leur nom
> remplacées par "dump"

[26/02/04]
- Intégration d'un code de retour pour close et destroy item
- pour destroy modification flag si boite de dialogue modale
- toutes les classes ont été passées dans le workspace win32ToolKit
- correction de certains bugs pour compilation cygwin
- ajout de ka fonction getItemCaption(...) dans CLangController pour ne pas avoir
> a utiliser une fenêtre pour pouvoir récupérer un texte.
- correction d'erreurs dans les parseurs (lecture de '\r' et '\n' et pos >= len )
[24/02/04]
- ajout dans CBasicWindow :
move(modification pour pouvoir mettre la taille aussi), getPosition, getSize, setSize
- ajout de la classe CText
- CWindow :ajout des méthodes:
> getTextItem() pour récupérer un texte dans le language courant
> getItemcaption() pour récupérer le caption d'un item dans le langage courant

[22/02/04]
- correction de CWindow::SetIcon(HICON)

 Fichier Zip

Les Membres Club peuvent télécharger directement un fichier contenu dans le zip sans télécharger le zip en entier !

Télécharger le zip


 Sources du même auteur

Source avec Zip CLOGFILE - CLASSE DE GESTION DE FICHIER LOG (THREAD SAFE)
Source avec Zip CXMLLINE : LIGNES XML
Source avec Zip CLASS WRAPPER STD::MAP + TEMPLATES
Source avec Zip Source avec une capture HELLPARSER - PROJET DE CRÉATION D'INTERPRÊTEURS + RAPPORT
Source avec Zip PARSEUR XML

 Sources de la même categorie

Source avec Zip WIN32 TLS LENT par dguilmain
Source avec Zip VIDER ELEMENTS DE CORBEILLE WINDOWS7 (WIN64) par BruNews
Source avec Zip Source avec une capture FIND TEXT (WIN64) par BruNews
Source avec Zip DELETE DIRECTORY (WIN64) par BruNews
Source avec Zip ENUM DIRECTORY (WIN64) par BruNews

Commentaires et avis

Commentaire de Hellaynnea le 24/02/2004 21:54:23

Bon visiblement ma source n'intéresse pas grand monde, ne sucite pas de commentaire, c dommage parce qu'il ya plein de choses intéressantes dedans,si c juste opur la leecher c pas la peine :(
la vocation du site c surtout pour apprendre
++

Commentaire de Hellaynnea le 28/02/2004 00:02:48

Je prend pas mal de temps a essayer de la mettre a jour sur ce site, si ca n'intéresse personne j'arreterait parce que j'ai aussi du travail a côté. Dites moi si vous voulez des mises à jours Sinon j'arrêterait d'updater la source ici.
Par contre vous pourrez toujours la trouver sur
http://hellaynnea.free.fr/programmation/c++/ =&gt; win32ToolKit prendre la dernière version en date (zip) vous pouvez voir les dernières updates dans le fichier win32ToolKit_Updates.txt
++

Commentaire de Funto66 le 28/02/2004 15:38:50

Non non y'en a 1 qui postera un commentaire, ce sera moi !
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-&gt;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 ;)

Commentaire de Hellaynnea le 28/02/2004 17:51:35

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...

&gt; hum je travaille la dessus justement, ca me dérange aussi mais &gt;pour l'instant  j'avais pas le temps de me pencher dessus &gt;sérieusement, j'ai commencé par faire des objets permettant de &gt;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...

&gt; pour ces fichiers aucun d'eux n'est obligatoire, c'est un plus pour &gt;pouvoir par exemple  traduire ton appli pour les resources, c pour
&gt; utiliser des id d'objets dynamiques, comme j'utilise visual 6.0
&gt; ils régénère le fichier à chaque fois que tu saves et parfois les id
&gt; changent alors pour éviter d'avoir a checker j'ai fait un petit parseur &gt;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.

&gt;pour les deux parties, la seule chose c'est le main qui contient &gt;l'exemple ! le projet en lui mm est constitué de tout ce qui &gt;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-&gt;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.

&gt; hum pas mal comme idée fo que j'y pense, seulement il faut
&gt; d'abord que j'implémente les callbacks et j'ai pas trop de temps en &gt; ce moment, mais j'aime bien l'idée :)
&gt; jve bien faire une dll ca me pose pas de problème, seulement il
&gt; faut que je sortes CMutex et CMouse (que j'avais mises la comme &gt;ca) il faut que je réunisse dans une callback tous les évents qu'on
&gt; peut retrouver
&gt; bon jcrois que je vais m'y mettre cet après midi ca m'intéresse :d)
&gt; seulement it remains a problem, c'est pour le desing des resources, &gt; on est toujours dépendant des editeurs de resources, mais si on
&gt; regarde bien la source de mon prog, on peut modifier la position et &gt; la taille d'un bouton, il faudrait juste que j'étende l'utilisation des
&gt; fichiers de conf pour pouvoir dès le début mettre les attributs des
&gt; objets, seulement les construire réellement me demanderaient pas &gt;mal de temps, pour l'instant je suis obligé de laisser ca tel quel, a &gt;moins qu'une bonne ame ... :)  mais bon jme fais pas d'illusions
&gt; étant donné que tu es le seul (et je t'en remercie) a avoir regardé &gt;le code

Enfin dernier truc, c'est pour le nom de ton toolkit que je trouve franchement....ben.....banal quoi :p

&gt; oui c vrai :) mais le nom on s'en fout un peu :) c t pour que ca
&gt; fasse suggestif qu'on sache a quoi ca sert au pire jle changerait &gt;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 ;)

&gt; jte remercie pour ton avis, et j'accepte les critiques (bonnes ou &gt;mauvaises) ca permet d'avancer, je vais dès maintenant me mettre &gt;à ton idée de signaux et de pointeurs de fonctions pour la dll je &gt;verrai une fois que tout sera fini

++

Commentaire de Funto66 le 02/03/2004 00:03:01

Cool :)
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 ;)

++

Commentaire de Hellaynnea le 02/03/2004 00:10:21

Salut, merci pour les comments, samedi j'ai fini d'implémenter les signaux seulement j'ai encore des soucis lorsque j'inclus les dlgproc dans les objets fo encore que je règle ca et j'ai pas super de temps.
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)
++

Commentaire de Funto66 le 02/03/2004 00:13:51

Yeeeah cool ;)

Commentaire de magic_Nono le 10/01/2005 14:50:31

Bonjour

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.

Commentaire de Joky le 10/01/2005 16:28:33

Bahhh de même, j'viens de voir ça, Ya beaucoup de code lol mais j'ai regarder la plus grosse partie et jtrouve ça pas mal :o
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 ;)

Commentaire de Hellaynnea le 10/01/2005 19:57:30

Salut, tout d'abord merci pour vos comments, qd j'ai sortie la source, elle est passée inapercue :(.
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.
++

Commentaire de Funto66 le 11/01/2005 19:52:09

Inaperçue, et moi alors, je compte pr des clous? :'(

Commentaire de Joky le 11/01/2005 19:53:43

Mdrrrrr

Commentaire de MaX271 le 02/07/2006 17:26:46

mais ca a l'ai trèèèèès bien ca!
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...

 Ajouter un commentaire




Nos sponsors


Sondage...

CalendriCode

Mai 2012
LMMJVSD
 123456
78910111213
14151617181920
21222324252627
28293031   

Consulter la suite du CalendriCode

A découvrir



 
Développement réalisé par Nicolas SOREL (Nix) avec l'aide de : Cyril DURAND et Emmanuel (EBArtSoft), Merci à Vincent pour ses précieux conseils.
CodeS-SourceS.com© Toute reproduction même partielle est interdite sauf accord écrit du Webmaster
CodeS-SourceS.com© est une marque déposée tous droits réservés

Google Coop CodeS-SourceS Google Coop CodeS-SourceS
Temps d'éxécution de la page : 0,312 sec (4)

Nous contacter | Annoncer sur CodeS-SourceS | Mentions légales