Sinon pour en revenir sur le serveur HTTP, tu me parle bien de ça: https://bitbucket.org/devonit/qjsonr....cpp?at=master
Sinon pour en revenir sur le serveur HTTP, tu me parle bien de ça: https://bitbucket.org/devonit/qjsonr....cpp?at=master
Oui, sauf que là, c’est un client. Un exemple de serveur est à « tcpserver ».
Nouvelle question: pour essayer de me débloquer, mon chef de projet m'a passé un kit de développement microchip. Ce kit possède la TCP/IP Stack (une librairie de microchip qui répond à ce que je souhaite faire, et téléchargeable ici http://www.microchip.com/stellent/id...47784#P81_1493 )
J'ai téléchargé la librairie et je dois avouer que je m'y perd, il y a des dizaines de fichiers différents et je n'arrive pas à isoler ce qui pourrait m'être utile.
D'où ma question: mon projet (à savoir avoir une interface se trouvant sur une page web qui me permettrait d'interagir avec un programme fait en c++ sous Qt) est-il si compliqué que ça à mettre en oeuvre où alors il y a quelque chose qui m'échappe ?
Si je résume la situation (et n'hésitez pas à me corriger), pour pouvoir interagir depuis ma page web avec mon programme c++ développé sous Qt, il me faut un serveur HTTP qui me fera office de passerelle. mais est-ce vraiment si compliqué que ça à mettre en oeuvre, parce que là clairement je désespère et je ne sais plus vers quelles solutions me tourner
Ce n’est pas compliqué, mais ça fait appel à pas mal de connaissances qui visiblement te manquent encore (rien d’étonnant à ça si tu es étudiant).D'où ma question: mon projet (à savoir avoir une interface se trouvant sur une page web qui me permettrait d'interagir avec un programme fait en c++ sous Qt) est-il si compliqué que ça à mettre en oeuvre où alors il y a quelque chose qui m'échappe ?
C’est pour ça que je t’ai proposé une démarche pas à pas, qui vise à n’aborder qu’un seul aspect à la fois, pour ne pas multiplier les difficultés.
Sinon, pour la librairie microchip, je ne connais pas. Néanmoins, de mon point de vue, il n’y a pas de raisons que tu n’y arrives pas avec la solution qu’on t’a proposée. Si tu passes ton temps à chercher une solution sans approfondir, tu n’y arriveras jamais
Bon alors un état des lieux s'impose.
Actuellement, voici où j'en suis. En discutant avec une autre personne sur le forum, j'ai réussi à dissocier la partie IHM de la partie communication série de mon programme (mais j'ai encore un petit problème vu que maintenant quand je compile et que j'exécute mon programme, mon IHM ne s'ouvre plus, donc j'essaie de trouver pourquoi mais je pense pouvoir m'ateller à la suite en parallèle).
Donc maintenant, je dois me dirigé vers la conception de mon serveur que je vais rajouter à mon projet Qt, c'est ça ?
Bonjour,
de toutes évidences il te manque (beaucoup?) de connaissances sur les (nombreux!) domaines à utiliser dans le cadre de cette application. (ça me dépassera toujours de demander à quelqu'un de réaliser un travail seul alors que ce n'est pas dans son scope de compétence.. bref la plupart des patrons/chef d'équipe/projet/.. me font halluciner - à fortiori à un étudiant ?! )
Un moyen simple, selon/pour moi et tel que je le mettrai en place avec mes connaissances maigres sur le sujet, c'est de faire un serveur web en python, qui récupèrerait les entrées de l'utilisateur sur la page web et serait capable d'appeler directement une appli en ligne de commande pour exécuter les actions.
- un serveur en python ça peut se faire en 5mn avec le bon import, 10 avec le premier tuto du web
- tu as déjà l'appli (indépendante de l'ihm, et l'ihm est ici inutile)
- le serveur ne "sert à rien", il ne fait qu'appeler une appli
-> osef de se casser le cul à le faire en C++ !
Personnellement, je suis plutôt d’avis de finir les problèmes avant d’en attaquer de nouveaux. On aborde toujours mieux les choses en ayant l’esprit clair.
Si ta fenêtre ne s’ouvre plus, c’est probablement… parce que tu avais supprimé le membre ui de ta classe MainWindow, non*? (à moins que tu ne l’y ai remis depuis le code que tu as posté sur pastebin).
Voici où j'en suis actuellement
automate.h : http://pastebin.com/4dcZmxPF
automate.cpp : http://pastebin.com/qLWwDwbB
mainwindow.h : http://pastebin.com/KPgAJiUv
mainwindow.cpp : http://pastebin.com/eG6pQ7Tp
J'ai encore une petite interaction entre mon interface et mon programme de communication, mais à priori je suis obligé de l'avoir
De ce que je vois du projet dans lequel je suis, cela à l'ar de relevé du développement web (mais je peux me tromper). Or ma formation initial c'est plutôt l'électronique. Les seules notions que j'ai concernant le développement web ou le réseaux sont ce que j'ai appris pour faire un site web (et un site web très simple, pas un truc qui me ferai appeler un programme en c++, d'où ma difficulté) et les topologie de réseaux (anneaux, étoile, réseaux LAN, MAN, etc ...) donc moi mes connaissances (si on peut les appeler ainsi) sont extrêmement maigre voir ridicule, c'est pour ça que clairement, je galère, je désespère mais je ne peux pas abandonné. Sachant qu'en plus je dois quand même avancé rapidement ... En gros, je suis dans la merde
Il manque le main dans ce que tu as posté, mais rapidement, je vois déjà un gros problème :
et
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4 Automate::Automate() { m_interface = new MainWindow();
Ce qui nous donne que :
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3 MainWindow::MainWindow(QWidget *parent) : QMainWindow(parent), ui(new Ui::MainWindow), automate(new Automate) { ui->setupUi(this);
- quand on construit un Automate, on construit un nouveau MainWindow
- quand on construit un MainWindow, on consruit un nouvel Automate
Dit comme ça, je ne vois pas comment ça peut marcher
Personnellement, ce que je ferais :
- la construction de l’automate est à la charge du main.
- la construction de la MainWindow est à la charge du main
Comme seulement MainWindow connaît l’automate, et pas l’inverse (cas idéal, vers lequel tu dois arriver), MainWindow va prendre dans son constructeur un pointeur vers l’automate.
Ensuite, au niveau de l’automate, comme pour l’instant il connaît encore MainWindow, on va mettre une méthode setInterface(MainWindow* window) dessus, qu’on appellera dans le main, qui ressemblera à quelque chose comme :
@Bousk : le problème de ta solution, c’est que c’est l’enfer pour établir une connection à double sens avec l’équipement. J’ai rien contre python, mais par contre, la communication par command line, c’est limité, rapidement l’enfer et pas fiable. Et s’il doit faire une interface C à ses classes pour les appeler depuis python, pas sûr qu’il gagne en simplicité par rapport à qjsonrpc qui est quand même super simple.
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(); }
Voici mon main.cpp actuel
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8 int main(int argc, char *argv[]) { QApplication a(argc, argv); MainWindow w; w.show(); return a.exec(); }Je m'en doutais un peu mais vu que l'on m'a dit de faire comme ça et que ça devait marcher j'ai suivi (bêtement, je vous l'accorde)Il manque le main dans ce que tu as posté, mais rapidement, je vois déjà un gros problème :
...
et
...
Ce qui nous donne que :
- quand on construit un Automate, on construit un nouveau MainWindow
- quand on construit un MainWindow, on consruit un nouvel Automate
et par contre pour la méthode setInterface, je mets quoi dedans ?
J’ai l’impression que tu travailles beaucoup sur le code sans comprendre ce qu’il fait réellement. Je comprends que tu as des délais courts, qu’on te demande de faire des choses que tu n’as jamais apprises à faire, ce qui n’est pas évident du tout et te met dans une situation délicate.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4 void Automate::setInterface(MainWindow* interface) { this->m_interface = interface }
Néanmoins, je ne peux que t’encourager à passer un peu plus de temps à bien analyser chaque chose, à bien comprendre ce qu’il se passe, plutôt qu’à bricoler deux trois trucs en essayant jusqu’à ce que ça fonctionne. Au final, tu rattraperas sûrement le temps passé initialement, et en plus tu auras mieux rentabilisé ton stage
Non je ne parle pas de créer une interface python qui serait se tirer une balle.
Je parle de garder un seul et unique executable, et de l'appeler directement depuis le python.
Surtout ne pas dupliquer quoi que ce soit et garder l'unicité du programme qui commande le bouzin derrière.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3 import subprocess subprocess.Popen("mon.exe -reboot -allume_la_loupiote_1 -bip", shell=True, stdin=subprocess.PIPE, stdout=subprocess.PIPE, stderr=subprocess.STDOUT) print p.stdout.read()
du coup dans mon mainwindow.h je remplace
par
Code : Sélectionner tout - Visualiser dans une fenêtre à part explicit MainWindow(QWidget *parent = 0);
Comme ça ça me permet de dire "J'ai créé juste avant un automate, je te le passe en paramètre pour que tu le connaisse parce que tu vas devoir travailler avec lui"
Code : Sélectionner tout - Visualiser dans une fenêtre à part explicit MainWindow(Automate* automate);
C’est exactement ça.
Et ensuite, tu dis à l’automate, avec la méthode setInterface : j’ai créé cette classe d’interface, c’est celle-ci que tu dois utiliser.
@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…).
dans mon fichier automate.h,
lorsque je déclare ma méthode
il faut quand même que j'ajoute au début de mon automate.h
Code : Sélectionner tout - Visualiser dans une fenêtre à part void setInterface(MainWindow* interface);
class MainWindow; pour qu'il puisse le reconnaitre parce que sinon le compilateur me dit MainWindow has not been declared
Je m'auto-cite parce que j'ai une question sur ce que j'ai ecris (et histoire de passer encore plus pour un boulet): est-ce que je replace purement et simplement QWidget *parent par Automate* automate (je ne pense pas que je puisse le faire)ou alors je l'ai met à la suite du style:
?
Code : Sélectionner tout - Visualiser dans une fenêtre à part explicit MainWindow(QWidget *parent = 0, Automate* automate);
Dans l’autre sens :
Pour la « forward declaration » de MainWindow, c’est tout à fait normal (cf la FAQ c++ )
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2 explicit MainWindow(Automate* automate, QWidget *parent = 0);
Alors, j'ai essayé de compiler et là ça me chie bien dans la colle. J'ai donc posé des qDebug pour essayé de voir à partir d'où ça chie et à priori c'est cette ligne qui chie:
il aime pas ça.
Code : Sélectionner tout - Visualiser dans une fenêtre à part m_interface->ajouterAction(action);
AjouterAction est une méthode de mainwindow et qui fait ça:
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 ?
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4 void MainWindow::ajouterAction(QAction* action) { ui->menuSelection_portCOM->addAction(action); }
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager