On dévie un peu du sujet initial mais ce n'est pas grave, je crois que le résumé de tyrtamos "Le problème de super(), c'est qu'on n'est pas sûr de ce qu'il fait réellement !" est parfait pour clôre le débat. Surtout pour un truc que je n'ai jamais fait, que je n'envisageais pas de faire un jour mais que désormais je m'attacherai à éviter de faire préférant plutôt me couper les mains
Le principal souci de Qt face aux threads, c'est que la mise à jour de l'IHM ne peut se faire que dans l'IHM dite "principale", celle qui appelle le exec_(). Un thread n'a pas le droit de dire "ok le QPushButton, va te cacher" ou bien "ok le QProgressBar, avance un peu" même s'il possède la référence du QPushButton ou du QProgressBar.
S'il veut transmettre une info à Qt, il ne peut le faire que via signal.emit() ; signal que l'IHM peut récupérer et traiter dans un slot qui fera cacher le QPushButton ou progresser le QProgressBar.
Donc la question se résume à "comment ce self.obj peut-il envoyer un signal" et "comment, du côté Qt, associer un signal venu de D.obj à un slot local" ??? On peut rajouter une question moins essentielle mais qui mérite d'apparaitre et qui serait "pourquoi un thread irait créer un QObject alors qu'un QThread est déjà un thread avec QObject intégré et permet de répondre directement aux deux questions précédentes"
Si ça t'intéresse, je te recommande cet exemple approuvé par tyrtamos![]()
Partager