Répondre à la discussion
Affichage des résultats 1 à 18 sur 18

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

  1. #1
    Bounoume

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

    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

    -----

    Pourquoi faire simple quand on peut faire compliqué ? (les Shadoks)

  2. Publicité
  3. #2
    Jack

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

    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 ...

  4. #3
    Jack

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

    Des infos par ici.

  5. #4
    pm42

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

    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.

  6. #5
    Bounoume

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

    Citation Envoyé par Jack Voir le message
    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?
    Pourquoi faire simple quand on peut faire compliqué ? (les Shadoks)

  7. #6
    Jack

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

    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.

  8. #7
    Bounoume

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

    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?
    Pourquoi faire simple quand on peut faire compliqué ? (les Shadoks)

  9. #8
    Bounoume

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

    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?????
    Pourquoi faire simple quand on peut faire compliqué ? (les Shadoks)

  10. #9
    pm42

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

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

  11. #10
    Bounoume

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

    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.....
    Pourquoi faire simple quand on peut faire compliqué ? (les Shadoks)

  12. #11
    Jack

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

    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.

  13. #12
    Bounoume

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

    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........
    Pourquoi faire simple quand on peut faire compliqué ? (les Shadoks)

  14. #13
    pm42

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

    Je vais détailler :

    Citation Envoyé par Bounoume Voir le message
    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.


    Citation Envoyé par Bounoume Voir le message
    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...

    Citation Envoyé par Bounoume Voir le message
    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.

    Citation Envoyé par Jack Voir le message
    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.

  15. #14
    Bounoume

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

    Pas moyen d'interrompre directement un enchaînement de calculs.....
    Alors faire 2 threads..... ce que je souhaitais éviter, du moins au début........
    Citation Envoyé par pm42 Voir le message
    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.......
    Pourquoi faire simple quand on peut faire compliqué ? (les Shadoks)

  16. #15
    Jack

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

    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.

  17. #16
    Bounoume

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

    Merci beaucoup.
    On va bientôt tester.......
    A +
    Pourquoi faire simple quand on peut faire compliqué ? (les Shadoks)

  18. #17
    Bounoume

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

    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....
    Pourquoi faire simple quand on peut faire compliqué ? (les Shadoks)

  19. #18
    Jack

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

    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?

Discussions similaires

  1. QTCreator: application QT-avecwidget: accès librairies standard?
    Par Bounoume dans le forum Programmation et langages, Algorithmique
    Réponses: 26
    Dernier message: 31/05/2018, 22h42
  2. Démineur sur QTcreator
    Par Lucas1836 dans le forum Programmation et langages, Algorithmique
    Réponses: 3
    Dernier message: 23/10/2015, 23h59
  3. Problème affichage avec Qtcréator
    Par foudefoot dans le forum Programmation et langages, Algorithmique
    Réponses: 13
    Dernier message: 22/06/2014, 23h09
  4. GSM : Uplink/downlink : Décalage de 3 slots ?
    Par Boogob dans le forum Physique
    Réponses: 0
    Dernier message: 03/12/2009, 22h30
  5. Slots PCI sur un serveur
    Par jpl77 dans le forum Matériel - Hardware
    Réponses: 3
    Dernier message: 11/10/2007, 21h09