Discussion :

[Kliffe]

Bonjour ,j'aimerai savoir comment s'effectue la gestion de signaux slot dans un Thread ?

J'effectue un projet pour le lycée et quand je passe par le debugger étape par etape (IDE : QT) cela marche mais dès qu'il s'agit d'utiliser ça en temps réels il est impossible que cela marche.

Le problème c'est que le programme recupére les informations de la carte après il récupere les informations du code barre (qui est scanné par un lecteur code barre) ensuite il faut poser l'artciel sur la balance mais a ce moment la cela ne s'efffectue pas.

Est ce que quelqu'un pourrai m'eclaircir. Merci

Voici les code principaux ou ce pose le problème.

Si vous souhaitez d'autres renseignement n'hesitez pas.

[Kliffe]

Voila la suite du code si besoin :

[Kliffe]

Le problème c'est que je ne peut même pas arriver a trouver le problème car avec le debugger ça marche.

Le main.cpp fini par la fonction :

Code :

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

return a.exec();

Et donc tout ce qui ce passe après cela n'est pas géré par l'ihm. L'ihm devrai m'afficher "Scanner votre conteneur sinon retirer votre carte" mais il bloque à " Poser le conteneur sur la balance". J'ai essayé de faire un :

Code :

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

QApplication::processEvent();

Mais cela ne met pas à jour l'interface. Merci de votre aide.

[bacelar]

Si vous gérez correctement les erreurs, vous devez avoir un fichier de log ou une fenêtre de trace avec tout plein d'indices.

[Kliffe]

J'ai trouvé le problème mais je ne sais pas comment je peut le résoudre. La dernière méthode appelé par l'ihm en mode "Normal (non Debug)" est la méthode (le_editing_finished()). Du coup ne pensant plus attendre d'autres choses. L'ihm retourne a.exec(). Comment je peut faire pour que l'ihm ne s'arrete pas lors de l'evenement le_editing_finished().

Merci de votre réponse.

[white_tentacle]

Note : je n’ai pas regardé tout le code.

Normalement, le a.exec() lance la boucle d’évènements principale, qui ne se termine que dans les cas suivants :
- quit() est appelé
- une erreur survient (segfault ou similaire)
- le thread est terminé de manière violente (pas bien, à peu près équivalent au cas précédent)

Quelques questions quand même :
- pourquoi mettre la balance dans un thread à part ?
- pourquoi faire dériver cette classe de QThread : c’est déprécié comme manière de faire
- idem pour la gestion de la bdd

Vu l’application cible, je pense que passer par un QSocketListener pour la balance et des appels synchrones pour la bdd serait largement suffisant (à moins qu’utiliser les threads ne soit un exercice, évidemment).

[Kliffe]

C'étais en effet pour travailler sur les thread car cela faisait partie de mon projet de validation de BTS. Durant la Tache de mise en oeuvre je suis passé par événement et pas un QTimer mais durant l’intégration j'ai voulu corser un peu tout ça.
Je ne connais pas QSokectListener. J'ai pus avancer un peut dans ma démarche et donc afficher "Scanner votre conteneur ou retirer votre carte" mais si le poids n'est pas stable à ce moment (donc contient kg et est différent de 0.00kg) alors l’événement ne réussi pas à faire la suite des Signaux.
Merci de ta réponse white. Ce qu'il fallais surtout que je gère c'étais la gestion de la carte à puce par un Thread afin de pouvoir boucler tant que la carte n'est pas insérer ou quand elle est insérer tester si la carte est encore présente.
Tout le reste n'etais pas forcement utile de passer par un thread.