QTCreator(QT5), C++ et exécution des instructions (dans un ordre curieux)

[Bounoume]

Bonsoir,
J'essaie de construire un programme manipulant des objets reliés en réseau.... dans un thread indépendant de celui de mainwindow (fenêtre qui fait les affichages et reçoit les commandes)
Lien entre les 2 par signal, slots avec la syntaxe ancienne du genre connect(&source,SIGNAL(machin( )),ui->textEdit33, SLOT(setPlainText(QString))
pas de problème.....c'est efficace dans les 2 sens.

c'est même sympa: si j'oublie le 'SIGNAL' avant l'appel de la fonction signal machin()...... encore aucun problème, c'est accepté et fonctionnel sans message d'erreur

par contre faut dire que la même fenêtre (état de mon biglotron) reçoit plein d'autres signalements.....
J'ai quand même envie que le message envoyé par machin soit visible quelques secondes, avant qu'un message récurrent du genre notifie_horloge() envoyé très fréquemment, ne l'écrase.

tel quelle, l'appel de mon signal machin() donne une visu de 1/4 seconde, puis c'est écrasé par les suivants....
SI , après l'appel de

signal machin("c'est moi machin")
,.................... j'écris un joli
thread01.wait(100);
.../....

non seulement le message de machin n'est plus du tout affiché, mais.....c'est le déroulement des séquences ultérieures qui est stoppé une seconde.....

Quelle peut être l'explication?
-----

[Jack]

Avec l'ancien syntaxe pour connecter signaux et slots, les erreurs ne sont pas signalées par le compilateur => Utiliser la nouvelle syntaxe.
la preuve, ton connect est syntaxiquement faux :connect(&source,SIGNAL(machin ( )),ui->textEdit33, SLOT(setPlainText(QString))

En effet, les arguments du signal et du slot doivent strictement correspondre. Il faudrait plutôt écrire : connect(&source,SIGNAL(machin(QString )),ui->textEdit33, SLOT(setPlainText(QString))

[Bounoume]

Exact...... mais c'était un exemple bidon; dans le vrai source, les arguments sont bien identiques (Qstring).... ou presque si le sinal est 1 évènement:
connect(ui->pushButtonStartThread,SIGNAL( clicked(bool)),&thread01,SLOT (start()));
là n'est pas le problème.
Ce que je voudrais comprendre,c'est pourquoi les instructions (parfois) ne semblent pas exécutées dans l'ordre programmé.......

[Jack]

là n'est pas le problème.

Si, un peu: l'exemple que tu donnes n'est toujours pas bon syntaxiquement, il faudrait que la fonction start prenne un booléen en argument. tant qu'il y aura une erreur, le slot ne sera pas appelé, ce qui peut peut-être expliquer tes problèmes puisque tu dis que machin n'a pas l'air d'être appelé.

Pour le reste, tu pourrais fournir un exemple concret que l'on puisse tester, parce que je n'ai pas très bien compris ?

[A voir en vidéo sur Futura]

[Bounoume]

D'après la doc de QT Assistant V4.8.7 2015, c'est bien correct si j'ai bien compris....:

to connect the signal to the slot, we use QObject::connect() and the SIGNAL() and SLOT() macros. The rule about whether to include arguments or not in the SIGNAL() and SLOT() macros, if the arguments have default values, is that the signature passed to the SIGNAL() macro must not have fewer arguments than the signature passed to the SLOT() macro.
All of these would work:
connect(sender, SIGNAL(destroyed(QObject*)), this, SLOT(objectDestroyed(Qbject*)) );
connect(sender, SIGNAL(destroyed(QObject*)), this, SLOT(objectDestroyed()));
connect(sender, SIGNAL(destroyed()), this, SLOT(objectDestroyed()));
But this one won't work:
connect(sender, SIGNAL(destroyed()), this, SLOT(objectDestroyed(QObject*) ));

Je vais essayer maintenant de te trouver un exemple concret..... mais ça va ếtre difficile de le tester.....
Si je copie seulement le bout de code qui semble foirer, il manquera tout le programme dans lequel il tourne ..... et ça fait 8 fichiers (cpp et en-tête + le mainwindow.ui....)
Ou alors je tente de former un embryon de projet avec une seule fenêtre principale et un thread simple..... mais ça va être pénible et pas sûr que j'arrive à reproduire les anomalies... en faisant toutner partie en exécutable seul, et.... en debugging.... avec la même version (celle délivrée par le gestionnaire d'applis Ubuntu, pas celle cherchée directement chez le développeur....)

En attendant, on peut quand même essayer de cerner un peu plus la (les) question(s) ?

[Jack]

En attendant, on peut quand même essayer de cerner un peu plus la (les) question(s) ?

Justement, je ne suis pas sûr d'avoir bien compris ton problème. pour l'instant, il me semble juste avoir compris que ton slot n'est pas appelé.

[Bounoume]

ça dépend...et c'est ça qui m'embête .

l'objet destinataire des messages (un QTextEdit) offre un slot SetPlainText(const QString)......., dans l'éditeur de formulaires (graphique).

J'ai connecté ce slot d'abord à 'machin', qui compte des cycles d'horloge(virtuelle), et donc les affiche successivement. Disons que toutes les secondes le nouveau 'tick' écrase la valeur affichée avant.....

ça marche, et les chiffres défilent bien.

Seulement j'ai envie d'afficher aussi autre chose par moments: par exemple l'accusé de réception d'un nouvel ordre par le thread travailleur, -ou le message que ça a bien abouti.
Ainsi le même slot est connecté aussi à un autre signal, disons signal2. Dans les docs j'ai compris que c'est tout à fait légal.....

Alors, quand signal2 est activé, tout à fait normalement, le message de signal2 s'affiche (en écrasant les nombres représentant l'horloge......)
Comme l'horloge continue de tourner, une demi seconde après, c'est la nouvelle 'heure' qui écrase le message de signal2, avant que j'aie pu le lire Grr!
Cela est encore normal.
note: les deux instructions "emit" sont dans des fonctions distinctes, avec plein d'instructions exécutées entre(toujours dans le thread qui calcule)

Ce qui ne va pas, c'est quand j'insère un
thread1.wait(1000)
juste après signal2........
Dans ma petite jugeotte, une fois le signal lancé, ça devrait laisser se transmettre le message de signal2, placé AVANT, puis arrêter la suite des opérations dans le thread pendant une seconde .....
Le moment où un nouveau top de pseudo-horloge écraserait le message de signal2 devrait simplement être retardé de une seconde......

Ben non......
le message de signal2 (qui sans le wait apparaîtrait transitoirement) ....n'apparaît plus du tout , alors que le retard à l'affichage du nouveau top de l'horloge est effectif: la thread a bien été suspendu pendant la seconde..
Voilà l'absurdité...


ps: dans mainwindow.cpp j'ai pu mis une autre temporisation avec la méthode thread1.msleep(millisecondes),
mais pas moyen de la faire accepter dans l'autre .cpp où elle serait peut-être plus adéquate:
message
/usr/include/qt4/QtCore/qthread.h:116: erreur : 'static void QThread::msleep(long unsigned int)' is protected
static void msleep(unsigned long);
^

[Bounoume]

le plus vicieux c'est qu' après avoir stoppé la boucle qui envoie des tops d'horloge, quand j'envoie un signal2,suivi immédiatement du thread1.wait(1000), alors
signal2 apparaît bien sans problème.....

[Jack]

Difficile de déterminer dans un cas aussi contextuel.

Tu peux tenter ta chance sur des forum spécialisés Qt si ce n'est pas déjà fait.

[Bounoume]

merci de ta réponse, je vais devoir tenter, mais si c'est en anglais, je vais beaucoup peiner à m'exprimer....
Ici, je cherchais principalement si quelqu'un avait déjà constaté des problèmes de ce genre.... et leur diagnostic sur la cause possible.....