QTCreator..., C++, signal et slots:

[Bounoume]

boucles de calculs compliqués, et quasi sans fin:
comment les interrompre sans perte de données, examiner et modifier des paramètres, et laisser repartir...

voici ce que je souhaite: un réseau d'objets ('nodes'),interagissants de façon peu prévisible, qui de temps en temps écrivent leurs propriétés à l'écran,dans des widgets de QT. Ces widgets constituent l'interface utilisateur du réseau.

Mais je désire, depuis l'interface utilisateur, suspendre les traitements, inspecter certains éléments, modifier des paramètres (et même créer/détruire certins objets, puis laisser redémarrer le processus.

Lorsque l'utilisateur modifie des widgets affichés à l'écran (ou clique dessus), j'ai cru comprendre qu'ils émettent des signaux, puis que ces signaux activent des fonctions 'slots' auparavant définies par le programmeur.
Si j'ai bien compris, à partir d'un bouton, je devrais pouvoir lancer un 'slot' (une fonction) construite pour modifier des variables qui contrôlent des if ou while, arrêtant ainsi les calculs, immédiatement ou après la fin d'une suite d'opérations parfaitement limitée (cela m'est indifférent).

Mais.... encore faut-il que la fonction 'slots' s'exécute entre 2 instructions de "main" ou de ses dépendances, alors que les boucles du programme principal de calcul s'enchaînent sans aucun temps d'attente.

D'ou la question: aprés une action adéquate dans l'interface graphique, l'exécution d'une fonction du genre:
on_inputSpinBox1_valueChanged( int value)
{ ..instructions...nombre=0; arret=1; etc.... }

..... est-elle prioritaire et va-t-elle s'insérer de suite entre l'exécution de 2 lignes du code en cours d'exécution?
..... ou attend-elle éternellement la fin des calculs?
merci d'avance
-----

[Jack]

C'est de la programmation par événement. Qt fait tourner une boucle qui scrute si des événements se sont produits.

Si ton programme "s'enferme" dans une boucle de calcul, la gestion des événements, et par conséquent de l'interface graphique du coup, n'est plus assurée et tout semblera figé tant que les calculs ne seront pas terminés.

Il faudrait regarder de plus près la gestion des événements dans Qt. Peut-être que l'utilisation de threads pour le calcul permettrait de s'en sortir. A creuser ...

[Jack]

Des infos par ici.

[pm42]

Oui, la solution est simple : on fait des objets manipulables graphiquement.
Puis on met le calcul dans un thread à part. Ce thread vérifie régulièrement s'il doit s'arrêter (via un bouton dans l'interface graphique).

Quand on cliqué sur le bouton et qu'on a eu confirmation que le thread de calcul est en attente, l'interface graphique qui jusque là était en visualisation seule autorise la modification/création/effacement d'objets.

Et ce jusqu'au moment où on clique sur le bouton pour relancer le traitement.

C'est du classique, pas très compliqué quand on a déjà un peu de métier sur les threads et sur la programmation graphique évènementielle.
Mais c'est du boulot.

[A voir en vidéo sur Futura]

[Bounoume]

C'est de la programmation par événement. Qt fait tourner une boucle qui scrute si des événements se sont produits.

Si ton programme "s'enferme" dans une boucle de calcul, la gestion des événements, et par conséquent de l'interface graphique du coup, n'est plus assurée et tout semblera figé tant que les calculs ne seront pas terminés.

Il faudrait regarder de plus près la gestion des événements dans Qt. Peut-être que l'utilisation de threads pour le calcul permettrait de s'en sortir. A creuser ...

c'est ce que je craignais....

Alors, autre idée: envoyer un 'signal' non depuis l'interface graphique, mais depuis le clavier . Par exemple ctrl/A, ctrl/P...... en évitant les signaux qui ne peuvent être interceptés.

Ecrire la fonction qui intercepte le signal, puis la déclarer comme handle d'interception:

include csignal.h // [est-ce la bonne déclaration ici ?]
void (*prev_handler)(int);
prev_handler = signal (SIGINT, ma_fonction_qui_pose_verrous_d ans_boucles);.

toujours en évitant pour le moment les threads multiples.....
Est-ce que l'action de presser le clavier va être prise en compte alors que la boucle de calcul tourne sans interruption?

[Jack]

Le signaux de Qt n'ont aucun rapport avec les signaux d'UNIX.

Les signaux de Qt utilisables sont ceux appartenant aux classes prédéfinies de Qt ou à de nouveau signaux définis dans des classes perso.

S'il n'y a qu'un thread ou deux à gérer pour exécuter des calculs, ça ne doit pas poser de problème insurmontable.

[Bounoume]

Les signaux définis dans signal.h sont spécifiques aux systèmes Unix, ou sont-ils implémentés dans tout programme C -ou C++- portable, y compris sur la chose à Microsoft?

[Bounoume]

Je viens de lire ça dans QT-Assistant
The C++ preprocessor changes or removes the signals, slots, and emit keywords so that the compiler is presented with standard C++.
J'en déduis que ces méthodes sont converties en signaux standard..... qui sont alors compilés par GC++, et que si des signaux décrits dans signal.h sont introduits en code natif C, ça marche......

Perso, c'est ce que je souhaite, parce que je trouve ça bien + simple que les objets 'signal' à QT (.......dès lors qu'on s'écarte des slots livrés presque tout prêts avec les widgets.... mais qui ne marchent pas si l'interface graphique est en sommeil du fait du programme de calculs qui tourne en continu.....)

Donc, quelqu'un sait-il si les signaux liés aux touches Ctrl/caractère , et non interceptés par des objets QT programmés pour ce faire.........->
-> vont avoir le comportement par défaut des signaux C, mais aussi pourront être interceptés par le code bien simple:
prev_handler = signal (SIGINT, my_handler);
où my_handler est une fonction C toute bête!

et bien sûr, qu'est-ce qui se passe quand on faut CTRL/Z ou CTRL/Q chez Windows? Est ce que ça émet aussi les mêmes signaux?????

[pm42]

Ta déduction est fausse. Voir le message de Jack plus haut.

[Bounoume]

pas si sûr!
je viens de trafiquer la fonction main() d'un exemple,
en y rajoutant

#include <csignal>

et
raise (SIGINT);

avant le return
je fais compiler main() tout seul:
Pas d'erreur à la compilation (alors que si le ficher d'en-tête est mal écrit, et ça dit qu'il y a pas ce fichier, et que le 'raise' et le SIGINT n'ont pas été déclarés.....

[Jack]

Ce n'est pas parce que tu utilises les bibliothèques de Qt que tu ne peut pas en utiliser d'autres. Donc ce que tu viens de réaliser n'est pas étonnant.
Maintenant, est-ce une bonne idée de jongler entre les événements de Qt et les signaux d'UNIX? Je ne pense pas, mais il est vrai que je ne suis pas réellement informaticien.

[Bounoume]

la suite:
QT a bien voulu l'exécuter ....
quand le raise(SIGINT) est absent, ça affiche une fenêtre de saisie de texte standard
quand j'ajoute mon raise(SIGINT) ça doit bien envoyer et prendre en compte ce signal....
.......... rien ne s'affiche, et dans la fenêtre de QT 'sortie d'application' ça dit

'le programme s''est terminé subitement' .... application crashed....
ce qui est l'effet attendu........

[pm42]

Je vais détailler :

J'en déduis que ces méthodes sont converties en signaux standard.....

Comme je le disais, cette déduction est fausse et les 2 "signaux" n'ont absolument rien en commun si ce n'est le nom.

pas si sûr!
je viens de trafiquer la fonction main() d'un exemple,

Ce qui n'a aucun rapport avec la "déduction" plus haut sur les signaux Qt...

Donc, quelqu'un sait-il si les signaux liés aux touches Ctrl/caractère , et non interceptés par des objets QT programmés pour ce faire.........->

Qt est surtout prévu pour faire des interfaces graphiques et le concept d'intercepter les signaux associés à certaines touches clavier en Unix n'a absolument aucun sens dans un programme graphique. D'autant que ça ne marche pas en Windows, en OSX et même en Linux si on lance le programme via une icône. Et qu'au cas où on le lancerait via une fenêtre, c'est aberrant ausi.

Vu que plus haut, il est précisé que le programme va utiliser des Widgets de Qt, il est bizarre de vouloir utiliser des mécanismes faits pour des programmes en ligne de commande.

Maintenant, est-ce une bonne idée de jongler entre les événements de Qt et les signaux d'UNIX? Je ne pense pas, mais il est vrai que je ne suis pas réellement informaticien.

Cela n'a aucun sens : les signaux Unix sont un mécanisme minimal de communication inter-process. Les signaux/slots de Qt sont un mécanisme de communication entre objets à l'intérieur d'un même process pour éviter l'enfer des callbacks en programmation évènementielle.
Bref, rien à voir.

[Bounoume]

Pas moyen d'interrompre directement un enchaînement de calculs.....
Alors faire 2 threads..... ce que je souhaitais éviter, du moins au début........

Oui, la solution est simple : on fait des objets manipulables graphiquement.
Puis on met le calcul dans un thread à part. Ce thread vérifie régulièrement s'il doit s'arrêter (via un bouton dans l'interface graphique).

Quand on cliqué sur le bouton et qu'on a eu confirmation que le thread de calcul est en attente, l'interface graphique qui jusque là était en visualisation seule autorise la modification/création/effacement d'objets.

Et ce jusqu'au moment où on clique sur le bouton pour relancer le traitement.
.

interrompre les traitements périodiquement (au passage périodique obligé à certaines instructions) ça c'est facile.
Je penserais même aussi à un timer (trouvé par hasard dans QT).....
Il faut activer 1 fonction maison qui lit l'état du bouton ad hoc......
écrire le code, ça va.

Mais il a été dit que pendant les calculs la partie graphique était inactive, incapable de prendre en charge les actions de l'utilisateur.
Si je laisse tout le code gestion des fenêtres dans le thread d'origine, alors l' écran demeurera réactif et enregistrera les mouvements de souris et le clic, alors que le 2 eme thread tourne encore un max?

SI l'écran veut bien prendre en compte le positionnement et le clic de souris, alors que ça tourne un max dans l'autre thread, et si
-celui qui mouline peut lancer périodiquement 1 fonction de lecture de l'état du bouton (et que l'objet interrogé répond!)
alors c'est gagné......

ou alors, ce qui me plairait encore plus, si le changement d'état du bouton pouvait activer un slot qui.....dans les données communes aux threads, positionnerait
la condition d'un if ou while à FALSE, ce qui stopperait le fil......
ce serait parfait.......

[Jack]

SI l'écran veut bien prendre en compte le positionnement et le clic de souris, alors que ça tourne un max dans l'autre thread, et si
-celui qui mouline peut lancer périodiquement 1 fonction de lecture de l'état du bouton (et que l'objet interrogé répond!)
alors c'est gagné......

Bin ça c'est vite testé: dans le thread, tu fais une boucle infinie et tu vérifies que ton interface graphique est toujours réactive.

ou alors, ce qui me plairait encore plus, si le changement d'état du bouton pouvait activer un slot qui.....dans les données communes aux threads, positionnerait
la condition d'un if ou while à FALSE, ce qui stopperait le fil......
ce serait parfait.......

Aucun problème à priori.

[Bounoume]

Merci beaucoup.
On va bientôt tester.......
A +

[Bounoume]

J'ai beaucoup pris de retard.....
j'ai seulement vérifié que, dans main(), si
avant le
return La_fenetre_de_application.show ()
(instruction qui est en fin de fonction main() )

-j'insère raise(SIGINT)
ça arrête l'exécution..... avant affichage de la fenêtre: RAS ici

-j'insère une boucle infinie du genre
while(TRUE){ };........

au même endroit, en restant dans le thread de main()......
ça bloque totalement l'affichage et ça empêche l'apparition de la fenêtre : faut 'tuer' le processus depuis le moniteur système.....

Je vais essayer la suite....

[Jack]

Il me semble logique qu'en empêchant d'exécuter "return La_fenetre_de_application.show ()" il n'y ait aucune fenêtre qui s'ouvre puisque le programme est bloqué dans la boucle.

On n'avait pas convenu de mettre la boucle infinie dans le thread?

[Bounoume]

Oui, la solution est simple : on fait des objets manipulables graphiquement.
Puis on met le calcul dans un thread à part. Ce thread vérifie régulièrement s'il doit s'arrêter (via un bouton dans l'interface graphique).
Quand on cliqué sur le bouton et qu'on a eu confirmation que le thread de calcul est en attente, l'interface graphique qui jusque là était en visualisation seule autorise la modification/création/effacement d'objets.
Et ce jusqu'au moment où on clique sur le bouton pour relancer le traitement.
C'est du classique, pas très compliqué quand on a déjà un peu de métier sur les threads et sur la programmation graphique évènementielle.
Mais c'est du boulot.

C'est ce que je tente maintenant:
démarrer un objet thread dérivé de QThread, pour les calculs, et y connecter des signaux venant du thread initial, avec mainwindow et divers gadgets.

Mais
0) la définition de slots dans l'objet Thread1, héritier de QThread, est acceptée.
1) je n'ai pas trouvé clairement comment utiliser les signaux envoyé par les widgets. L'interface graphique donne bien le nom des objets, j'ai essayé de les invoquer.....
et de construire un 'connect' avec. Erreur....
2) pour test + simple: j'ai défini un signal dans l'objet Thread1: OK ....... mais pas moyen de connecter cette fonction déclarée signal, ,et un slot dans le même THread1....

Voici le code

dans mainwindow.h
class Thread1 : public QThread
{
Q_OBJECT
protected: void run();//redéfinit la fonction virtuelle
public: void toto();
//~Thread1();
public slots:
void demarre();
void stoppe();
signals:
void couine();
connect(this,SIGNAL( couine()), this, SIGNAL(stoppe())); //void ou pas void, SIGNAL ou pas SIGNAL, ça ne change rien.....
}

erreur : expected identifier before 'this' connect(this,SIGNAL (couine()), this, SLOT(stoppe()));
sans SIGNAL/SLOT:
erreur : expected constructor, destructor, or type conversion before '(' token QObject::connect(&t1, SIGNAL(couine()),etc.....

ou bien dans mainwindow.cpp

Thread1 t1;
QObject::connect(&t1, SIGNAL(couine()),&t1, SLOT(stoppe()));

encore message d'erreur..... : expected constructor, destructor, or type conversion before '(' token QObject::connect(&t1, SIGNAL(couine()),

Il y a quelque chose qui m'échappe:
Qu 'est ce qui ne va pas?
^

[Bounoume]

je rajoute une impression: il me semble que l'expression à l'intérieur de la fonction n'est pas évaluée: :
un nombre différent d'arguments dans le signal et le slot cela n'entraîne aucun message d"erreur supplémentaire....
de même si le nom de la fonction signal ou slot ne correspond à aucune fonction déclarée....

[Jack]

C'est pour cela qu'il ne faut plus utiliser les macros SIGNAL et SLOT et préférer la nouvelle syntaxe.

[Bounoume]

bon, d'accord, mais il est bien dit que l'ancienne syntaxe est conservée.......
J'ai converti dans la nouvelle syntaxe

dans mainwindow.h
QObject::connect(&t1, t1:: (couine()), &t1, t1:: (stoppe()));

devrait être accepté ....

version Qt Creator 3.5.1
Basé sur Qt 5.5.1 (GCC 5.2.1 20151129, 64 bit)

ben non.....
erreur...../boitexte_threads/mainwindow.h:61: erreur : expected constructor, destructor, or type conversion before '(' token
QObject::connect(&t1, t1:: (couine()), &t1, t&:: (stoppe()));

[Jack]

je tâcherai de faire un test un peu plus tard.

bon, d'accord, mais il est bien dit que l'ancienne syntaxe est conservée.......

Je n'ai pas dit le contraire, mais je répondais au fait qu'aucun message d'erreur n'était généré si les arguments ne correspondaient pas. La nouvelle syntaxe, elle, effectue cette vérification à la compilation.

[Jack]

dans mainwindow.h
QObject::connect(&t1, t1:: (couine()), &t1, t1:: (stoppe()));

je ne vois pas comment ça peut marcher dans un fichier de déclaration de la classe (.h), vu que t1 n'est en principe pas encore instancié .

[Jack]

De plus, t1::couine() ne peut pas aller non plus car t1 n'est pas le nom de la classe à laquelle appartient la fonction couine.

[Bounoume]

le modèle dans la doc de QT5:

connect ( sender, &Sender::valueChanged, receiver, &Receiver::updateValue);

si j'ai compris la nouvelle version:
connect( l'instance_qui_envoie, l'adresse_du_Type_qui_contient _le_signal::le_ signal, l'instance_qui_reçoit, l'adresse_du_Type_du_receveur: :la_fonction_slot).....
soit:

moi, dans le .cpp

Thread1 t1;
QObject::connect(t1, &Thread1::couine, t1, &Thread1::stoppe);

et ca donne quand même toujours:
c/boitexte_threads/mainwindow.cpp:48: erreur : expected constructor, destructor, or type conversion before '(' token
QObject::connect(t1, &t1::couine, t1, &t1::stoppe);
désespérant.....

[Bounoume]

j'avais placé la déclaration de l'instance Thread1 et le connect dans le fichier mainwindow.cpp.....
maintenant, en déclarant l'instance et en faisant connect ...... dans main.cpp, après la fin de main(...) même erreur;

Par contre SI (est-ce correct ou obligatoire d'ailleurs ? ) je déclare l'instanciation ET le connect DANS la fonction main(....)
avant le w.show(),
il y a une suite de messages d'erreur (moc a fait son travail?)
le premier message:
c/boitexte_threads/main.cpp:17: erreur : no matching function for call to 'QObject::connect(Thread1&, void (Thread1::*)(), Thread1&, void (Thread1::*)())'
QObject::connect(t1, &Thread1::couine, t1, &Thread1::stoppe);

je préférerais.... mais quel est le mismatch en fait? je ne trouve pas... ^

[Jack]

Quelques constatations
- je ne vois pas de constructeur dans la classe Thread1
- pourquoi creer un signal couine dans la classe Thread1 pour appeler une fonction dans la même classe? Autant appeler directement la fonction plutôt que d'émettre le signal.

Ou alors je ne comprends pas comment tu comptes utiliser ce signal.

[Bounoume]

ta deuxième remarque: mettre slot et signal dans le même objet, c'était seulement pour tester le connect,
pas pour un usage réel....
la première:
pas de constructeur de l'objet dérivé de thread: je n'ai pas envie de modifier 1 objet déjà complet pour lancer/arrêter de threads.....
je veux simplement y rajouter des slots qui activent run(), et le fonctions d'arrêt quit() exition() je crois....

maintenat j'ai rajouté un objet de classe Truc: QObject....., instance trucx.....
avec un signal appelé couine()....
j'ai essayé la nouvelle syntaxe
QObject::connect(sender, &Objetsender::fonction, reciever,&objetreceiver::fonct ion)
.......
(ligne placée dans une fonction comme le constructeur de Mainwindow dans mainwindow.cpp)
c'est bien évalué, ça reconnaît et signale si je modifie les noms des arguments, mais ça me dit imperturbablement:

code: QObject::connect(trucx, &Truc::couine, threadx, &Thread1::stoppe);
erreur:
/home/hubert/projets-c/boitexte_threads/mainwindow.cpp:12: erreur : no matching function for call to 'MainWindow::connect(Truc&)'
QObject::connect(trucx), &Truc::couine, threadx, &Thread1::stoppe);

alors que les arguments me semblent corrects.
Pourtant il y a bien une cause.....

il y a aussi 1 message qui dit que la fonction couine() est protégée alors que je crais l'avoir notée après un 'public:'

J'y perds mon latin (ou le peu qui m'en reste....)

[Jack]

la syntaxe de connect impose que trucx et threadx soient les adresses des objets, donc il faut que tu les aies déclaré ainsi: Trucx* trucx;
puis instanciés par: trucx = new Trucx;

Si tu as déclaré et instancié ainsi: Trucx trucx;
il faudra modifier le connect en spécifiant l'a dresse des instances de trucx et threadx: connect(&trucx, &Truc::couine, &threadx, &Thread1::stoppe);