Discussion :

[guillaume07]

Bonjour,

Quel est la différence entre un signal et un évenement sous QT :
par exemple la différence entre faire

emit mon_signal();
et
sendEvent();

Avec sendEvent est on sûr que le code de réception soit éxécuté immédiatement ou est ce mis dans une queue event

plusieurs questions donc, merci!

[guillaume07]

ça pourrait faire une entrée dans la FAQ QT peut être !

[Matthieu Brucher]

Les événements ne sont jamais synchrones car dispatchés par la boucle des messages.

[nouknouk]

Avec sendEvent est on sûr que le code de réception soit éxécuté immédiatement ou est ce mis dans une queue event ?

C'est justement la différence entre un signal et un événement :

- un signal (emit CeciCela) est exécuté immédiatement, c'est l'équivalent d'un appel de fonction vers chacun des slots connectés à ce signal (*)

- un événement est d'abord posté dans la file d'attente de la queue d'événements et sera traité dès que l'application exécutera à nouveau la boucle d'événements, donc plus tard.

C'est d'ailleurs pour cette raison qu'existe la fonction deleteLater() : si un objet monButton émet un signal 'clicked' qui lui même est connecté à un slot 'onButtonClicked' de maFenetre, je n'ai pas le droit de faire dans 'onButtonClicked' un 'delete monButton' : en effet, 'onButtonClicked' est appelé directement par monButton, donc quand on retournera de 'onButtonClicked', la pile d'exécution devrait continuer dans monButton ... qui vient d'être deleté => crash car on a corrompu la pile d'exécution.

La solution est d'utiliser 'monButton.deleteLater()' au lieu de 'delete monButton' : ça postera un événement dans la boucle d'événements qui sera traité après que la pile d'exécution soit sortie du traitement du signal monbutton, donc la pile d'exécution ne contiendra plus de référence à monButton.

(*) il y a une exception à cela: quand un signal est connecté à un slot d'un objet appartenant à autre thread: comme on n'a pas le droit d'aller 'taper' dans les objets d'un autre thread, c'est à la place un événement 'activer slot ceciCela' qui est alors ajouté dans la liste d'événement du thread différent. cf. Qt::ConnexionType.

[yan]

ça pourrait faire une entrée dans la FAQ QT peut être !

oui, très bonne idée.

C'est justement la différence entre un signal et un événement :

- un signal (emit CeciCela) est exécuté immédiatement, c'est l'équivalent d'un appel de fonction vers chacun des slots connectés à ce signal (*)

- un événement est d'abord posté dans la file d'attente de la queue d'événements et sera traité dès que l'application exécutera à nouveau la boucle d'événements, donc plus tard.

C'est d'ailleurs pour cette raison qu'existe la fonction deleteLater() : si un objet monButton émet un signal 'clicked' qui lui même est connecté à un slot 'onButtonClicked' de maFenetre, je n'ai pas le droit de faire dans 'onButtonClicked' un 'delete monButton' : en effet, 'onButtonClicked' est appelé directement par monButton, donc quand on retournera de 'onButtonClicked', la pile d'exécution devrait continuer dans monButton ... qui vient d'être deleté => crash car on a corrompu la pile d'exécution.

La solution est d'utiliser 'monButton.deleteLater()' au lieu de 'delete monButton' : ça postera un événement dans la boucle d'événements qui sera traité après que la pile d'exécution soit sortie du traitement du signal monbutton, donc la pile d'exécution ne contiendra plus de référence à monButton.

(*) il y a une exception à cela: quand un signal est connecté à un slot d'un objet appartenant à autre thread: comme on n'a pas le droit d'aller 'taper' dans les objets d'un autre thread, c'est à la place un événement 'activer slot ceciCela' qui est alors ajouté dans la liste d'événement du thread différent. cf. Qt::ConnexionType.

ca fait une bonne ébauche. Si cela te dit te faire la QR

[guillaume07]

ah voilà, je pensais aussi que la différence devait se situer ici, exec séquentielle vs file d'attente, mais dans un de mes softs, justement le signal n'est pas exec tout de suite. il s'agit donc de l'exception que tu as mentioné, c'est à dire le cas où un thread effectue un emit et que le slot se situe dans un autre thread, tout s'explique!