Recherche piste de réflexion/tutoriel pour communication entre un programme en c++ avec BDD

**Bousk** · 31/10/2013, 14h37

Envoyé par white_tentacle

@bousk : ça veut quand même dire parser toute la command line côté c++, et côté python parser tout le retour. Ça se fait, mais je maintiens que ça rajoute encore des choses avec lesquelles l’op ne sera pas forcément à l’aise, et que ce sera l’enfer si tu veux pouvoir gérer des évènements initiés par l’équipement / le programme et pas par l’interface (tu vas devoir faire du polling actif…).

Le problème initial consiste à "j'appuye sur un bouton, ça allume/éteint"
Il ne s'agit pas d'un super ordinateur de bord temps réel web
Le code retour du programme, on peut s'en moquer, pour avoir l'info à jour, utiliser les spécificités du web : on affiche une page statique, on gère le côté dynamique via du javascript etc pour rafraichir le contenu
Si l'application fait une action toute seul (chose non abordée jusqu'ici, donc pure supposition ?), le client affichera le contenu à jour au refresh qui suit

A fortiori, l'op est un développeur web à la base, là il s'agira de faire strictement du web, le côté serveur se fait en qqs heures, puis on fignole l'interface web; et il s'agira de purs upgrade de l'appli principal quand nécessaire, sans même avoir besoin de toucher au serveur si l'on crée les bonnes méthodes/opérations

**therwald** · 31/10/2013, 14h38

Envoyé par clairetj

Vu que pour chaque ports, on crée un lien entre le port et une action dans le menu, on récupère l'action et on l'affiche dans le menu. Sauf qu'à priori il aime pas. Pourquoi ?

Le type est incomplet vu que tu n'as que la forward declaration. Dans ton impleme tu vas avoir besoin de l'import du header.
Mais dans un .cpp l'effet est plus localisé que dans un header.
Autre possibilité, plus longue mais plus propre, tu fais une classe d'adaptateur autour de ta référence d'interface, de manière à ce que ton core soit réellement indépendant du type de l'interface.
C'est ta classe d'adaptateur, abstraite, qui a la référence de l'interface, et elle a une implémentation pour la window, et une pour le serveur web. Elle définit la fonction membre virtuelle registerPort(), qui fait ce qu'elle a à faire pour enregistrer ton port dans l'interface.
Et c'est la main qui instancie le bon adaptateur puisque c'est elle qui instancie l'interface donc sait de quel type d'interface il s'agit

**therwald** · 31/10/2013, 14h40

Envoyé par Bousk

A fortiori, l'op est un développeur web à la base, là il s'agira de faire strictement du web, le côté serveur se fait en qqs heures, puis on fignole l'interface web;

J'avais pas compris ça pour ma part, puisqu'il avoue être une quiche intégrale en js et pas trop le temps ed s'y mettre...

**clairetj** · 31/10/2013, 14h43

Envoyé par therwald

Le type est incomplet vu que tu n'as que la forward declaration. Dans ton impleme tu vas avoir besoin de l'import du header.

Au risque de passé pour une bille, je suppose que faire un include monfichier.h ne suffit pas

**therwald** · 31/10/2013, 14h53

Quand tu fais une forward declaration, tu dis juste au compilateur: "hey, la classe XXX existe".
Ca suffit pour définir un pointeur ou une référence sur cette classe, mais il n'y a pas les info pour appeler des fonctions membres de la classe (pour ça il faut inclure le header).
Dans dans ton *.cpp il faut inclure le header de ta classe d'interface pour pouvoir en appeler les méthodes.
Ou alors tu avance un peu dans la conception et tu définis un adaptateur, qui lui a des fonctions à appeler par automate pour faire des choses comme enregistrer l'existence d'un port série. La signature de ces fonctions doit être conçues pour masquer la nature de l'interface (dans ce cas c'est l'adaptateur qui crée la QAction, à partir des données neutres dont dispose le core (nom de port, par ex?)

**clairetj** · 31/10/2013, 14h56

Envoyé par therwald

Quand tu fais une forward declaration, tu dis juste au compilateur: "hey, la classe XXX existe".
Ca suffit pour définir un pointeur ou une référence sur cette classe, mais il n'y a pas les info pour appeler des fonctions membres de la classe (pour ça il faut inclure le header).
Dans dans ton *.cpp il faut inclure le header de ta classe d'interface pour pouvoir en appeler les méthodes.

Donc, en haut de mon fichier.cpp je fais #include "mainwindow.h" (ça m'embête de le remettre la vu que le l'avais déjà mis dans mon automate.h donc je ne vois pas l'utilité de le remettre)

**white_tentacle** · 31/10/2013, 15h05

edit: oops, pas vu la page suivante

Dans automate.h, tu n’inclus pas mainwindow.h. Tu déclares simplement :

Code :

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

1
2
 
class MainWindow;

.

Idem dans mainwindow.h : tu n’inclus pas automate.h, tu déclares seulement :

Code :

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

1
2
 
class Automate;

dans mainwindow.cpp : tu inclus mainwindow.h et automate.h
dans automate.cpp : tu inclus automate.h et mainwindow.h

(l’ordre n’est pas spécialement important à ce niveau).

La FAQ explique ça normalement

.

http://cpp.developpez.com/faq/cpp/?p...TES_ou_inclure

**clairetj** · 31/10/2013, 15h09

dans mon automate. j'ai défini m_interface comme ceci:

Code :

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

1
2
private:
    MainWindow *m_interface;

mon setInterface est comme ceci:

Code :

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

1
2
3
4
void Automate::setInterface(MainWindow* interface)
{
    this->m_interface = interface;
}

et voici mon main

Code :

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

1
2
3
4
5
6
7
8
9
10
int main(int argc, char *argv[])
{
    QApplication a(argc, argv);
    Automate automate;
    MainWindow window(&automate);
    automate.setInterface(&window);
    window.show();
 
    return a.exec();
}

**white_tentacle** · 31/10/2013, 15h11

Le main me semble bon, j’ai édité ma réponse.

**therwald** · 31/10/2013, 15h15

Envoyé par clairetj

Donc, en haut de mon fichier.cpp je fais #include "mainwindow.h" (ça m'embête de le remettre la vu que le l'avais déjà mis dans mon automate.h donc je ne vois pas l'utilité de le remettre)

Ce n'est pas la même chose de mettre l'include mainwindow dans le header ou le CPP.
Dans le premier cas, toute classe utilisant ta classe automate sera recompilée quand on change mainwindow, dans le second, seul automate doit être recompilé.
L'idéal en conception serait d'utiliser l'adaptateur dont je t'ai parlé afin que la classe automate cesse d'être liée à mainwindow.

**clairetj** · 31/10/2013, 15h19

Je viens de me rendre compte de quelque chose:

Dans mon main, on crée en premier un automate, puis on crée une mainwindow qui va connaitre l'existence de l'automate créée

Or dans mon constructeur de mon automate, dedans, je lance la méthode detectionPortCOM. Cette méthode à besoin d'avoir connaissance de mainwindow.
Or vu que je crée d'abord l'automate (et donc avec le constructeur, le lance la méthode detectionPortCOm), la mainwindow n'étant pas encore créée, cela doit faire un conflit

le problème ne viendrait-il pas de là ???

**white_tentacle** · 31/10/2013, 15h23

Je confirme que c’est un problème !

Dans ton cas, tu peux corriger assez simplement ton problème en déplaçant cette partie du code dans une méthode « init », que tu appelleras après le setInterface…

**therwald** · 31/10/2013, 15h25

Pour éviter de multiplier les appel post construction, peut-être que ce devrait être init qui prend l'interface en paramètre.

**clairetj** · 31/10/2013, 15h35

Le problème venait bien de là, j'ai fait mes modifications et j'arrive (enfin ) à avoir à nouveau mon interface qui apparait.
La détection des ports COM et leur affichage dans l'interface se fait bien et j'arrive à sélectionner sur quel port je veux établir ma communication (comme avant).

Mais bon, vu que j'ai pas de chance, nouveau problème: je n'arrive plus à me connecter à mon automate

Je vais donc essayer de voir d'où sa vient et si je ne trouve pas je reviens faire un saut ici.
En tout cas merci pour votre aide pour cette étape de restructuration de code

**clairetj** · 31/10/2013, 15h42

Finalement, c'est bon j'ai retrouvé ma connexion à mon automate et cela marche comme mon programme originel très très mal organisé

Je suis donc prêt à passer à la suite, à savoir: le serveur

**clairetj** · 31/10/2013, 16h33

Du coup première question: sachant que mon client sera une page web, me faut-il un serveur TCP ou un serveur HTTP ???

**therwald** · 31/10/2013, 17h04

Un serveur HTTP serait l'idéal, comme ça tes formulaires seront automatiquement traités, tu n'auras plus qu'à "câbler" la récupération des valeurs. (en TCP ça fonctionnerait pareil...sauf que tu aurais le parsing HTTP à te tapper à la mano

)

**clairetj** · 31/10/2013, 17h14

du coup, comme j'avais un peu fait des recherches sur "comment programmer sous Qt un serveur HTTP" je suis tombé sur ça:
http://doc.qt.digia.com/solutions/4/...le-server.html

la façon dont c'est écris me gêne un peu. J'ai l'impression (c'est à quoi je pense quand je lis le code) que c'est un simple fichier.h dans lequel on aurait mis le code qui "normalement" ce trouverait dans un fichier.cpp (mais je peux me trompé, c'est comme ça que je comprends le code)

Ensuite (et même si je pense que je vais devoir faire des modification), est-ce que ce genre de code peut convenir pour réaliser mon serveur HTTP ?