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

Version imprimable

Voir 40 message(s) de cette discussion en une page

31/10/2013, 14h37
Bousk

Citation:

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
31/10/2013, 14h38
therwald

Citation:

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
31/10/2013, 14h40
therwald

Citation:

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...
31/10/2013, 14h43
clairetj

Citation:

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
31/10/2013, 14h53
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.
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?)
31/10/2013, 14h56
clairetj

Citation:

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)
31/10/2013, 15h05
white_tentacle
edit: oops, pas vu la page suivante

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

1 2 class MainWindow;
.

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

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

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

Code:

1
2
private:
    MainWindow *m_interface;

mon setInterface est comme ceci:

Code:

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

et voici mon main

Code:

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();
}

31/10/2013, 15h11
white_tentacle

Le main me semble bon, j’ai édité ma réponse.
31/10/2013, 15h15
therwald

Citation:

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.
31/10/2013, 15h19
clairetj

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à ???
31/10/2013, 15h23
white_tentacle

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…
31/10/2013, 15h25
therwald

Pour éviter de multiplier les appel post construction, peut-être que ce devrait être init qui prend l'interface en paramètre.
31/10/2013, 15h35
clairetj

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 :cry:

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
31/10/2013, 15h42
clairetj

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

Je suis donc prêt à passer à la suite, à savoir: le serveur
31/10/2013, 16h33
clairetj

Du coup première question: sachant que mon client sera une page web, me faut-il un serveur TCP ou un serveur HTTP ???
31/10/2013, 17h04
therwald

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 :aie:)
31/10/2013, 17h14
clairetj

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 ?
03/11/2013, 18h47
clairetj

alors, votre avis sur le code de mon précédent post ???
03/11/2013, 20h52
therwald

L'exemple de code de ton lien ne montre...qu'un serveur TCP qui se trouve renvoyer un fichier HTML en cas de requete.

Voir 40 message(s) de cette discussion en une page