Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Les thread Qt
Bonjour.
Je souhaiterais créer un Thread via Qt. La documentation propose quelques exemples concernant ces derniers, néanmoins, ca ne convient pas réellement à mes attentes.
Il semblerais que sous Qt, un Thread nécessite la création d'une classe. Je souhaiterais faire abstraction de ce point, pour, non pas avoir une classe, mais simplement une méthode. Quelque chose du style CreateThread(), mais spécifique à Qt.
Est-ce possible ? Et si oui, de quelle manière ?
Cordialement,
PKO
Salut
Difficile de te répondre comme cela. A la limite je te dirait de regarder les QtConcurrent, mais tout dépend de cette questionEnvoyé par Altess
Que veut tu faire avec cette thread?
Bonjour et Merci d'avoir replacer le post.
En fait j'ai une classe qui hérite d'un QWIdget.
class FenInstall: public QWidget, private Ui::Form_install{...}
Et dans ce QWidget, j'ai une ListBox qui indique les étapes de mon application, du style :
Le soucis, c'est que mes indications n'apparaissent pas au fur et à mesure, mais toutes d'un coup, a la fin de l'application. J'ai donc tenter ca :- Etape 1 : Analyse ... Terminée
- Etape 2 : Création ... Terminée
[...]
- Etape n : Fin de l'application
class FenInstall: public QWidget, private Ui::Form_install, public QThread
Ceci, dans le but d'utiliser une méthode Run dans ma classe. Mais ça fonctionne pas. En gros, je n'arrive pas a utiliser les Thread dans la classe qui hérite déjà de QWidget. Il semblerais que depuis la version 4, l'héritage QWidget / QThread ne fasse pas bon ménage.
Je me suis donc orienter vers la création d'une méthode Thread, qui se verra passer en paramètre mes indications a afficher dans la listeBox.
Après, il est fort probable que ce soit pas la bonne solution cette histoire de méthode Thread. Si vous avez une idée de comment faire pour utiliser les Thread dans ma classe QWidget, je prend.
Cordialement,
PKO
alors là, je t'arrête tous de suite, JAMAIS de traitement IHM dans un THREAD
Dans ton cas, je proposerais trois solutions :
1- tu appel régulièrement la fonction static QCoreApplication::processEvents pour permettre la partie IHM de faire ses traitement
2- Tu créé un thread qui te fait l'installation et transmet son avancement vers l'ihm par des signal/slot
Vue ton cas la première semble amplement suffisante. Je ne vois pas beaucoup d'intérêt à utiliser un thread. Par contre découpe bien les étapes en fonction. Il te faudra surement pouvoir stopper l'installation.
Pour bien te former tu peu voir aussi les tutoriels et cours pour apprendre Qt : http://qt.developpez.com/tutoriels/
Yan > Merci pour ces informations. En ce qui concerne la remarque "JAMAIS de traitement IHM dans un THREAD", je met ça dans un coin de ma tête, et je ne referais plus la bêtise.
Effectivement, la méthode "QCoreApplication::processEvents" marche à merveille, c'est exactement ce que je cherchais. Je vais jeter un oeil dans la doc pour savoir ce qui se passe vraiment lors de l'appel.
L'étape 2 me sera sans doute utiles un jour ou l'autre, néanmoins, elle me semble bien complexe. Est-ce accessible, ou bien vraiment trop complexe ?
Enfin, "Dans ton cas, je proposerais trois solutions :". Y'en à une troisième ou pas, juste pour info?
Merci encore.
Cordialement,
PKO
Ca execute ce qu'il y as dans l'eventloop. Comment le rafraichissement de l'ihm par exemple.
Oui et non. Mais si on peut se passer de thread autant évitéL'étape 2 me sera sans doute utiles un jour ou l'autre, néanmoins, elle me semble bien complexe. Est-ce accessible, ou bien vraiment trop complexe ?
J'avais une troisième idée avec QtConcurrent::run, mais je ne suis pas sure que cela vaille le coupEnfin, "Dans ton cas, je proposerais trois solutions :". Y'en à une troisième ou pas, juste pour info
Yan > Merci de ta rapidité.
L'utilisation de ""QCoreApplication::processEvents" peut elle être régulière ? J'entend par là pouvoir l'appeler fréquemment dans un même petit bout de code, afin d'avoir une actualisation efficace et simple à la fois. Ou bien est-ce déconseillé, à n'utiliser qu'en dernier recourt ?
Cordialement;
PKO
Oui, au pire, elle ne fera rien, si il n'y as rien à faire.
C'est le dernier recourt avant d'utiliser un thread. Mais cela peut généré des petits problèmes (voire la doc).
Mais ça semble correspondre à ton problème.
Yan > Parfait. Merci encore pour toutes ces informations.
Cordialement,
PKO
Salut,
Pour appeler processEvents, j'ajouterais un léger bémol: ne l'appel pas trop souvent où tu ralentiras vraiment beaucoup le traitement que tu fais.
Seul toi peut savoir s'il vaut mieux appeler processEvents toutes les 2, 5, 10, 100 itérations (une étape de tes tâches), ou s'il vaut mieux créer un thread/suite de tâche par QFuture (qui me semble plus adapté pour modéliser un pipeline de tâches lourds) avec laquelle tu es sûr que l'application sera réactive aux entrées utilisateurs et autres événements, et que tes tâches tourneront à une vitesse correcte.
Au final je n'ai pas parlé de cela car je ne vois pas trop comment arrêter proprement l'exécution.
Par exemple le run exécute une boucle qui fait des copie. Comment faire pour stopper les copie en plein millieu?
QFutureWatcher dispose d'un slot cancel(), pause() ou encore resume(), ça devrait aller
Par contre, pour annuler les copies déjà effectuées, il faut prévoir un système stockant les objets à supprimer en cas d'annulation.
cancel : arrête la suite d'exécution à la prochaine itérationQFutureWatcher dispose d'un slot cancel(), pause() ou encore resume(), ça devrait aller
pause : pause la suite d'exécution
resume : relance la suite d'exécution
Un cancel sur un QtConcurrent::run ne sert pas à grand chose et dans mon exemple cela ne va pas arrêté la copie. Cela à un intérêt avec les autres algos par contre.
D'où la criticité de diviser en sous-tâches si c'est nécessaire. Or dans aucun de ces posts je n'ai lu de besoin particulier en ce sens.
Donc j'en parle; il est seul maître, et lui seul s'il peut ou non adapter ses tâches à un tel modèle.
Je contredit pas que tu en parle juste pourquoi je n'en ai pas parlé
En y réfléchissant ça me semble plus propre que d'utiliser processevents en effet. Peut être plus difficile à comprendre comment utiliser par contre.
en faite au final, je sais pas quel est le plus propre
chaqu'un à ses avantages et inconvénients.
Tout à fait, c'est pourquoi c'est important d'en parler
Certains pensent à tord que processEvent est un remède miracle, donc je profite de la moindre citation pour préciser que non, c'est à utiliser aussi soigneusement que des threads (si on veut conserver une vitesse d'exécution et une réactivé aux entrées correctes).
Bonjour.
Ce qui me gène avec les Thread, c'est que j'éprouve régulièrement la sensation de ne pas savoir les exploiter au mieux. Et dans ce cas, il est vrai que ProcessEvent me sert de "remède miracle", sans doute a tort.
Sans doute verrez-vous fleurir dans peu de temps un post de ma part concernant l'utilisation des thread (Qt et autre)
Cordialement,
PKO
Répondre avec citation
Partager