Une application de test de fonctionalités

Version imprimable

03/01/2012, 14h11
Caxton

Une application de test de fonctionalités

Bonjour,

Je suis en train de travaillé sur une fenêtre sous qt creator pour tester des concepts orienté objet en C++.

Je n'ai pas vraiment commencé car j'aimerais avant discuté de deux ou trois points technique.

J'ai vue dans un exemple que l'on pouvait créer une fenêtre avec 3 fichiers. Mais j'avoue c'est assez déroutant et c'est pourquoi je m'interroge sur ce point. Dans cette exemple, il y avait un .h qui mettait en oeuvre une classe.

C'est ce point que je ne suis pas sûr.

Citation:

Dans mon cas, je pensait faire:

Classe générique gFen() qui aura pour but de créer une fenêtre.

Classe générique gUrl() qui aura pour but de cherché un fichier particulier à partir d'une url déterminé.

Classe générique gXml() qui prendra en charge l'ouverture et le chargement d'une partie d'un xml en mémoire.

Classe enfante gXmlComp() qui prendra en chharge la comparaison entre deux portion de xml (<version>1.0.0</version> == <version>1.0.2a</version>).

Donc questions:
- Faut-il que toutes ces classes soit des .h ?
- Peut-on les renommé autrement, genre .cl vue que ce sont des classes ?
- Existe-il une autre convention ?

Bon là, je ne fais que m'informé, on se fiche pour le moment de comment je ferais les fonctionnalité, ça sera l'objet d'un autre post dans les sections concernés. :mouarf:

Merci et bonne année a tous 8-)
03/01/2012, 16h49
dourouc05

:salut:

Un seul fichier est requis, tu peux absolument mettre tout dedans : tes définitions de classes, les implémentations, main(), etc. D'ailleurs, une seule fonction est requise pour créer une fenêtre, pas besoin de créer sa propre classe (mais c'est assez limité).

Tu peux nommer tes fichiers d'en-tête comme tu veux, même sans extension (réservé par convention à la bibliothèque standard C++). Cependant, les fichiers ne seront plus associés à l'EDI, ils ne seront plus reconnus comme tels dans l'EDI (pas de belle icône ou de classement dans les catégories) ; ça ne changera rien pour la compilation, tant que tous les #include pointent sur des fichiers qui existent. Le compilateur n'en a que faire de l'extension.

Il y a cependant ce qu'on peut faire et ce qu'il est préférable de faire. Notamment, l'interface d'une classe dans un fichier d'en-tête (.hpp, .hxx, .h++ pour C++ uniquement conventionnellement ; .h pour C ou C++). Dans cet ordre d'idées, tu auras trois fichiers pour ta petite fenêtre : l'interface de sa classe (fen.hpp, e.g.), son implémentation (fen.cpp, e.g.), ton main() (main.cpp, e.g.).

Ensuite, pour tes fonctions... Ce sont des fonctions, pas des classes, à ce que j'en ai compris.
- gFen() : ce ne serait pas plutôt le rôle d'un constructeur (ou méthode d'une factory) ?
- gUrl() : ici, spécifiquement un slot ; par contre, Qt fournit de belles méthodes pour récupérer direct un path sans invoquer explicitement la fenêtre de choix (QFileDialog::getOpenFileName(), e.g.).
- gXml() : appelé juste après avoir récupéré le nom de fichier, plutôt (vu la taille des fonctions, inutile a priori de découper à ce point).
03/01/2012, 18h07
Caxton

Déjà, la réponse va dans le sens de ma pensé. C'est une bonne chose car je me voyais mal réinventé la roue ;)

Citation:

Envoyé par dourouc05

Ensuite, pour tes fonctions... Ce sont des fonctions, pas des classes, à ce que j'en ai compris.
- gFen() : ce ne serait pas plutôt le rôle d'un constructeur (ou méthode d'une factory) ?
- gUrl() : ici, spécifiquement un slot ; par contre, Qt fournit de belles méthodes pour récupérer direct un path sans invoquer explicitement la fenêtre de choix (QFileDialog::getOpenFileName(), e.g.).
- gXml() : appelé juste après avoir récupéré le nom de fichier, plutôt (vu la taille des fonctions, inutile a priori de découper à ce point).

Oui, mais pas totalement. J'ai besoin de faire la part des choses entre ce qui existe -> lib (entre autre pour la partie dom et xml mais ça c'est un autre débat qui existera ailleurs). Ou alors créer un fonctionnement perso, plutôt une lib particulière à l'application finale.

Sauf que je ne veux pas partir dans tous les sens et encore moins codé 30 fois la même chose. Donc je me fait une apply qui aura au final l'ensemble des fonction du projet sans en être le projet final. Et c'est bien là mon but.

Me renseigner sur les faisabilité du code à réalisé, trouvé les RFC s'il a lieu d'en utilisé et codé ce qui faut soit avec les libs, soit créer ma propre sauce. Au final cette apply permettra de corrigé les bugs de développement indépendamment de la construction de l'apply.

En outre, elle permettra de tester toutes les fonctionnalité et de sortir des logs de chaque actions et commandes. Enfin c'est ce que j'aimerais faire.

Chu peut-être un peu fou pour me lancé dans cette aventure mais j'en ai assez d'amorcé des projet et de ne plus avancé par ce que j'ai pas testé ni étudié le fonctionnement avant d'aller l'intégré de façon irrémédiable dans une apply. C'est mon point de vue. 8-)

Bon et bien, je vais donc essayer de prendre les choses dans l'ordre.
Un header, un main, des .cpp pour gérer fenêtre et classes.

Je sent que je vais m'amuser avec les accésseurs :mouarf:
03/01/2012, 21h23
dourouc05

Dans ce cas, que viens-tu faire dans le forum Qt... si c'est pour utiliser les MFC :aie: ? Qt fait tout ce que tu veux : fenêtre pour récupérer un chemin, gestion des fenêtres, XML tant DOM que SAX, café, etc.
04/01/2012, 14h45
Caxton

Ce que je viens faire sur qt... ben voyons !
En apprendre un peu plus sur cet EDI :ccool:

Plus sérieusement m'organisé de façon à éviter de codé n'importe quoi n'importe comment. Donc discuter sur le projet et avoir des avis. Mais bon si ca dérange, je partirais sur les MFC :cry:
04/01/2012, 14h48
dourouc05

Citation:

Envoyé par Microbulle

En apprendre un peu plus sur cet EDI :ccool:

Qt ? Un EDI ? Pas vraiment. Qt Creator est un EDI, Qt est un framework C++ qui fait la pluie et le beau temps (bon, presque :aie:).

Citation:

Envoyé par Microbulle

Plus sérieusement m'organisé de façon à éviter de codé n'importe quoi n'importe comment. Donc discuter sur le projet et avoir des avis. Mais bon si ca dérange, je partirais sur les MFC :cry:

C'est juste que, si tu veux utiliser les MFC, c'est mieux d'en discuter dans le forum approprié, pour te rapprocher des gens qui connaissent les MFC, les utilisent, savent ce qu'il faut faire pour se compliquer la vie, etc. ;).
04/01/2012, 17h19
Caxton

J'ai pas dit que je voulais me compliqué la vie ;)
Bien au contraire !

D'ailleurs, ca me soulève une question, pourquoi avoir parlé des MFC ? Après tout, qt possède déjà ce qui faut, autant en profité.

Et quand à mes classes, je te rassure rien de bien lourd à part certains traitements. Mais là, j'en parle pas car je n'y suis pas dessus.

Pour la petite histoire Edi Ok, idem pour Qt :ccool:
04/01/2012, 17h36
dourouc05

Citation:

Envoyé par Microbulle

D'ailleurs, ca me soulève une question, pourquoi avoir parlé des MFC ? Après tout, qt possède déjà ce qui faut, autant en profité.

Il me semble que tu as lancé cette idée, avec une faute de frappe (dans ce contexte, pas vraiment de RFC) :

Citation:

Envoyé par Microbulle

trouvé les RFC s'il a lieu d'en utilisé et codé ce qui faut soit avec les libs, soit créer ma propre sauce.

;)
04/01/2012, 17h45
Caxton

Ah oui, j'ai peut-être fait un abus de langage.

Je compte m'appuyé dessus, certes, mais si c'est déjà codé, j'utilise ce qui existe.

Là, entre autre ou je risque de devoir faire moi même, c'est si je doit transformé des données. Mais ça, c'est pour plus tard aussi.

Là, vraiment, je pense faire ma fenêtre, me basé sur qt pour la réalisé et faire que ca soit parfaitement intégré.

Ensuite, ça va être un problème de logique.

mon appli, devrais accepté le développement de classe, mais pas sa compilation. En effet, on prends le projet appliTest, par exemple, on code la classe que l'on veu, ou bien l'implémentation que l'on désire tester, on compile et on voie le résultat. Après, quand c'est tout compris et optimisé (bah oui, si on peu s'éviter de coder dix fois la même chose, c'est parfait), alors on a plus qu'à extraire les libs et le fonctionnement pour le projet final.

C'est un peu comme si je faisait un modèle qt en fait.

Après, c'est sûr qu'on peut allé plus loin, mais ca serais réinventé la roue :roll:
04/01/2012, 17h59
dourouc05

Citation:

Envoyé par Microbulle

Là, entre autre ou je risque de devoir faire moi même, c'est si je doit transformé des données. Mais ça, c'est pour plus tard aussi.

Tu as déjà pas mal de choses possibles en XML, tu peux même utiliser la même API pour d'autres formats (code à l'appui, cependant, même si ce n'est pas trop hard-core : http://qt-quarterly.developpez.com/q...es-generiques/), pratique pour du XQuery ou d'autres.

Puis, si tu veux aller plus loin dans ton idée, tu pourrais envisager d'utiliser des plug-ins, pour ne devoir compiler et linker que le bout de code à tester, pour utiliser une seule instance du testeur pour plusieurs échantillons (chacun étant un plug-in). Mais c'est beaucoup plus avancé :aie:.
04/01/2012, 21h01
Christophe

les slots

Je reviens sur le fait d'avoir plusieurs fichiers.

Si tu ne connais pas du tout Qt, Qt utilise un système nommé SLOT permettant de gérer les signaux ( exemple je lis un icône de barre d'outil à un slot ce slot contenant le code devant être exécuté lors du clic ou plutôt du signal clicked )

Pour cela j'ai un fichier main.cpp incluant un fichier mycode.h et ne contenant pas grand-chose d'autre, j'instancie un objet mycode contenant l'essentiel, et lance un objet QApllication contenant grosso-modo la boucle sans fin du système Qt arrêté par la méthode quit de QApplication ( explications simpliste vu que je débutes )

mycode.h contient mes includes Qt ( exemple : QApplication, QtGui, QMainWindow, etc ... )

mon fichier contient ensuite une classe appelée mycode contenant comme toutes les classes C++ public: , private, puis spécifique à Qt Slots:

Slots: contenant le même type d'info que public ou private, des méthodes, et des propriétés .

Quand je lance make, mon makefile généré par qmake crée un fichier moc_mycode.c en plus qui est utilisé pour la compilation. le fichier moc est un fichier de pré-compilation un peu obscur pour moi je l'avoue mais c'est la sauce interne de Qt. J'avais cru comprendre que le système moc analysait les fichiers .h . Au début tout mon code était dans mon fichier main.cpp et je n’arrivais pas à utiliser les slots. Par contre, je ne suis pas sûr que celà est la règle.

Après, moi qui ne suis pas spécialiste, je trouve le framework vachement complet tu peux faire par exemple grosso-modo un navigateur web en qq lignes, de ce que j'en ai vu c'est vachement complet. Un galère pour moi à prendre en main ( mais je ne suis pas développeur de métier ).

Un autre truc que je trouve excellent, le système de gestion des traductions.
En faitq tu met toutes tes phrases à traduire dans ton code dans la fonction tr
Le Framework va alors génerer le fichier de traduction que tu peux ensuite utiliser avec un outil graphique utilisable par un néophyte non developpeur. Dans le paramètre de la fonction tr, tu peux même donner un contexte d'explication servant pour le traducteur qui aura juste à exploiter un fichier pour l'application de traduction, ce fichier étant ensuite intégré à ton appli lors de la compilation.

Au départ, ça m'embetter de devoir créer un objet et de gérer un fichier cpp et un fichier .h ( à savoir que j'avais fait du C mais pas de C++ donc je me retrouve à devoir apprendre C++ et Qt ) mais finalement par rapport au service rendu je m'y suis fait. Alors avoir un ou plusieurs fichiers après tout ...

Je galère, mais j'arrive à progresser ( notamment grâce aux utilisateurs du forum que je remercie encore), je commence même à arriver à trouver les réponses par moi-même. C'est vachement complet, QtCreator, QtDesigner,
je trouve que c'est vachement abouti.
05/01/2012, 17h50
Caxton

Je comprends bien le principe de ce que tu explique au dessus.

Cependant, il faut que je travaille de la meilleure façon qui soit. Donc en fonctionnalités.

Une fonctionnalité, c'est un joyeux mélange de classe et de code étudié pour fonctionné ensemble. Mais il faut aussi que ça soit exportable.

Je ne pense pas que plusieurs fichiers soit si compliqué à gérer. Mais par contre faut être attentif à ce qui doit être mutualisé ou non. Et là, c'est plus un gros travail d'analyse et d'UML. Mais maintenant si tu ne connais pas ces concepts, effectivement il faut mieux en resté aux slots.

Moi, j'ai pas trop le choix vue la complexité final du bazar et de la ma façon de codé toujours en montant d'un cran :aie:

Bon et bien, je vais donc m'attaqué à un premier source que je présenterais là avec des questions plus en relation avec qt.

Je l'aurais un jour... je l'aurais !
06/01/2012, 07h45
Christophe

réponse par rapport aux slots

Microbulle,

Je précises que je ne suis pas développeur de métier, je peux donc raconter des conneries ( merci dans ce cas à la personne s'en apercevant de me corriger ).

L'UML c'est plutôt la théorie, moi à mon niveau je parles plutôt d'algorigrame, voire MVC après les normes ....

les SLOTS dont je parlais c'est plutôt la pratique. J'en parlais essentiellement car c'est une notion spécifique à Qt sur le nom et peut être sur la façon de l'utiliser ( ajout de slots: dans la définitions des objets ), ça sert à relier tes évènements aux fonctions de traitement. Je peux pas mieux expliquer mais ça donne une idée générale.

Enfin je pense que pour développer la moindre appli Qt, tu y sera confronté.

Après pour ton histoire d'UML, regardes du coté de Qt Designer et/ou Qt Creator . QT Designer génère un fichier XML contenant la description de tes Widgets, ce fichier étant chargé dans ton source pour générer l'interface.

regardes aussi ça :
http://uml.developpez.com/telecharge.../id/1862/BOUML
ça à l'air d'être fait en Qt

En espérant t'avoir fait avancer .. ou que j'avancerais moi-même ... ou encore mieux les deux ...
06/01/2012, 09h51
Caxton
Oui, les slots servent à reliée un bouton à son action.

Je pense que je ferais ainsi
Code:

1 2 QObject::connect( m_bouton, SIGNAL( clicked() ), qApp, SLOT( setTest("Bonjour") ) );
Comme on peut le voir, mon bouton est bien reliée comme tu disait en matière de slot. Là, je demande à un accesseur de transmettre en paramètre bonjour à une classe externe. Pour peu qu'elle soit inclue.

Au passage, l'UML d'ont je parlais c'est au niveau de setTest(). En effet, si je le code 1 fois et que j'en ai besoin 10 fois dans mon programme, je vais avoir tendance à le mutualisé. C'est ce que je veux faire.

Maintenant, mon appli me permet de tester ce qui doit être tester. Exemple ici, j'ai peut-être comis une erreur de code.. L'ai peut-être transmis des lettre donc au format String et le code attends des int, des chiffres ! C'est le but de mon apply de tester et de vérifier que l'on est bien sur la bone piste fonctionnelle.

Je sait pas si je suis très clair :roll: Si c'est pas le cas, merci de me le dire.

Au passage, j'ai pas tester mon bout de code au dessus, c'est possible que je me soit trompé. mais c'est le principe que je voulais évoqué. S'il existe une correction, n'hésitez pas à me le dire.

Merci.
06/01/2012, 10h04
Jerome S

Si je ne m'abuse, tu ne peux lier un signal à un slot uniquement si les types des paramètres sont identiques. Dans l'exemple que tu cite, tu lie un void avec un QString : ca ne passe pas.

Quelque chose de plus logique serait :

Code:

QObject::connect( m_bouton, SIGNAL( clicked() ), qApp, SLOT(OuvrirFenetre()) );

Ou bien :

Code:

QObject::connect( m_textEdit, SIGNAL(textChanged(QString)), qApp, SLOT(SetText(QString)) );

Je me trompe ?