Version imprimable
C'est possible dans une GUI :
Mais ca ???Code:
2
3
ou est ce qu on est obligé de passer par une méthode contenant thread.method() ?Code:
2
Salut.
pour commencer faudrait que tu revoie les connect.
Tu peut regarder la FAQ elle viens d'être mise a jour et la doc :
http://qt.developpez.com/doc/latest/...sandslots.html
Ensuite pour le connect entre thread tu peut regarder :
http://www.developpez.net/forums/sho...d.php?t=484613
http://www.developpez.net/forums/sho...2&postcount=23
Merci, je vais regarder, pour le moment je mets les méthodes du thread dans les slots de mon appli. Ca fonctionne. J'ai lu le doc Trolltech récemment. Hormi une particularité des threads, je ne vois pas pourquoi on ne pourrait pas mettre en slot un méthode d'une instance de QThread (un thread, quoi), et l'activer avec un signal du main thread. D'autant plus que l'inverse est possible, comme dans l'exemple de mandelbrotalors...
Salut
attention un QThread et les objet créé dans son créateur appartiennent au thread qu'il la créé!!!Citation:
Envoyé par ttone
Seul tout les objets qui sont créént dans la méthode run appartiennent au nouveau thread
J'ai mis un exemple ici :
http://www.developpez.net/forums/sho...5&postcount=15
la différence est le mode de connection. En gros, l'appel du slot d'objet appartenant au même thread que le signal sera comme un appel direct.
l'appel du slot d'objet appartenant à un thread différent que le signal, l'appel sera sérialisé dans l'eventloop de la thread pour être traité plus tard.
Un autre point est qu'un emit est thread safe
On peut, c'est juste que ce n'est pas ce que tu demandes. Tu connecte le signal a un slot de "this" au lieu d'un slot de ton thread:Citation:
Envoyé par ttone
:arrow:
:DCode:connect(this->interface.sendButton, SIGNAL(clicked()), thread, SLOT(method()));
:roll: :oops: toutes mes confuses, ma question est en fait, peut on écrire ca ?:
c'est thread safe, donc ok.Code:
2
par crainte, je passais par des méthodes...qui contenaitCode:this->sendToThread()
Code:thread.method()
A propos, je n'ai quasiment rien dans ma méthode run, sinon quelques initialisations secondaires, qui passent après le constructeur. Toutes mes méthodes sont "en plus", et sont appelé par les événements GUI (keyPressEvent, signal sur éléments graphiques, etc.). Est ce normal ?Citation:
Seul tout les objets qui sont créént dans la méthode run appartiennent au nouveau thread
est ce que tu as un lien particulièrement intéressant pour ca ? Ca m'intéresse pas mal...Citation:
la différence est le mode de connection. En gros, l'appel du slot d'objet appartenant au même thread que le signal sera comme un appel direct.
l'appel du slot d'objet appartenant à un thread différent que le signal, l'appel sera sérialisé dans l'eventloop de la thread pour être traité plus tard.
Vive Qt, c'est pratique à souhaitCitation:
Un autre point est qu'un emit est thread safe
Non, comme le disent Aurélien et Mongaulois, c'est possible. Les signaux/slots de Qt permettent justement de connecter des signaux à des slots qui sont dans des threads différents. Il y a une page de la doc officielle qui y est dédiée si je ne m'abuse.
Ok, ==>Résolu.
Une question de newbie absolue j'imagine, comment utiliser un QThread pour gérer un compteur ? Je travaille sur un player video, je voudrais avoir dans mon thread un emit permanent vers mon mainThread/GUI, pour afficher la progression de la lecture. Un indice ?
Merci pour votre aide
A mon avis, il faut connecter un signal personnalisé que tu mettrais par exemple dans ta classe dérivant de QThread à un slot dans ton IHM permettant de mettre à jour l'avancement de la lecture. Un signal et le slot auquel il est connecté devant avoir la même signature, je te conseille de passer par exemple un int, qui serait le nombre de millisecondes par exemple... ou de secondes.
Tout à fait je pars dans cette direction, mais le problème que je mepose, c'est comment émettre le signal continuement ou par pas d'une centiseconde par exemple ?Citation:
A mon avis, il faut connecter un signal personnalisé que tu mettrais par exemple dans ta classe dérivant de QThread à un slot dans ton IHM permettant de mettre à jour l'avancement de la lecture. Un signal et le slot auquel il est connecté devant avoir la même signature, je te conseille de passer par exemple un int, qui serait le nombre de millisecondes par exemple... ou de secondes.
La mention de MontGaulois de l'eventLoop m'a fait penser que c'est peut être par là qu'il faut que je cherche.
Pour émettre un signal comme tu le souhaites, il faut faire une boucle dans laquelle tu fais :
puis tu attends X millisecondes.Code:emit tonSignal(ton_int_representant_lavancement);
Cette boucle sera exécutée et à chaque fois demandera de mettre à jour ton composant graphique dans lequel tu inscris l'avancement de la lecture.
Ce qui m'étonne dans tout ca, en bien d'ailleurs, c'est qu'avant la lecture média bloquait mon mainThread, ok, maintenant elle se fait en parallèle et je peux en plus mettre des set/get dans tous les sens sur ce média, tout passe.
Ton dernier problème a été résolu ?
Non, je mets en place un thread propre au comptage.
D'ailleurs on est autorisé à instancier un thread dans un thread ?
Quelle est la meilleure solution en terme de stabilité ?
pas dans ce sens car this et thread sont la même thread. Donc le connect est directCitation:
Envoyé par ttone
par contre un emit dans la fonction run est threadsafe.
regarde le lien que je t'ai donnée. y as aussi un exemple pour comprendre.
Tu as aussi cette partie de la doc
http://qt.developpez.com/doc/latest/...s-and-qobjects
pour ce que tu veut faire, un QTimer ne correspond pas??
Je me suis posé la question, mais je ne pense pas que ca aille.Citation:
pour ce que tu veut faire, un QTimer ne correspond pas??
En fait voilà, j'ai mon mainThread et mon mediaThread, ... pour l'instant je lance mon mediaThread qui est soumis à plusieurs signaux (play, pause, stop, volume, zoom, etc...) pendant la lecture du media.
Et qui émet (emit) des infos de nature a modifier les propriétés de la GUI/
C'est sur 2 propriétés en particulier que je cherche à faire un "timer", d'abord pour avoir un compteur, mais QTimer n'ira pas a toute première vue, car je me déplace dans mon fichier (j'avance, je reviens au début, etc) donc je pensais faire un getPosition sur la tête de lecture en permanence et afficher ca...
La 2eme propriétés est que j'utilise un slider en IN/OUT, je m'en sers pour me positionner dans le media, je voudrais aussi qu'il bouge pour informer de l'avancée de la lecture, ...
ces 2 propriétés en perpétuel changement, ne peuvent pas se faire dans mon mediaThread car elles nécessite une boucle et le bloquerai, j'ai donc pour le moment, ajouté un thread fils à mediaThread qui se lance à l'initialisation de mediaThread :
mainThread
“
mediaThread
“
timerThread
et à chaque pas de la boucle tout remonte, un emit de timerThread tamponne un signal de mediaThread, qui arrive sur un slot de mainThread et fait bouger le slider...
enfin en théorie, car le debug a l'air de détester mes threads en série...Citation:
you should never pass the QThread object (this) as the parent of an object created in the thread (since the QThread object itself was created in another thread).
ceci n'est pas un problème. En faite, c'est pas évident de comprendre comment marche un QThread.Je vais essayer d'expliquer. N'hésite pas a poser des questions.Citation:
Envoyé par ttone
Un QThread est simplement un objet qui va lancer une thread. Le code que va lancer la QThread est dans run.
Donc tout ce qui est créé et exécuter dans run appartiens au thread, pas le reste.
[QUOTE]you should never pass the QThread object (this) as the parent of an object created in the thread [/QUOTE]
Ca veut simplement dire de ne pas mettre comme parent à un objet, un objet d'une autre thread. Or QThread n'appartient pas au thread quel va lancer. Pas ce qui sera créé dans le run
C'est ca qui est difficile à comprendre.
En gros tout ce que doit utiliser ta thread doit être créé dans run.
Si tu veut utiliser des slot et des signal avec une QThread, le plus propre est de déporter ton code dans un QObject qui sera instancié dans le run et lancer l'eventloop de la thread.
Comme tu peut connect des signaux entre eux, tu peut te servir de la QThread pour interfacer ta thread. Ainsi un signal emit par la gui sera connecté directement avec un signal du Qthread qui sera connecté indirectement au slot du QObject de la thread.
Un signal emit par le QObject sera connecté indirectement à un signal du QThread qui sera connecté directement au slot de la GUI
connecté directement : les objet appartiennent au même thread, cette connection équivaux à un appel directe de la fonction
connecté indirectement : les objets appartiennent à deux thread différentes, les paramètres sont copiés et envoyés dans l'eventloop du slot pour être exécute dés que possible.
Merci,
sauf que bizarrement, en ayant pas saisi, j'ai quasiment rien mis dans run, et pourtant ca ne freeze pas...
Sinon une classe dérivant de QThread, ne serait qu'une classe pouvant contenir un run, lui même start-able depuis la classe qui l'instancie ?...