Bienvenue sur le forum !

Si vous souhaitez rejoindre la communauté, cliquez sur l'un de ces boutons !

Qt 5 : 5.9.1 - Qt Creator : 4.4.0 - Qt Installer : 2.0.3 - JOM : 1.1.2 - Qt Build suite : 1.7.0 - VS Qt 5 : 2.0.0

[méthode] par quoi passer pour faire ce que je veux?

Bonjour, j'ai réfléchit, et j'arrive pas à me décider par quel méthode passer pour faire ce que je veux sachant de que je veux que ce soit propre.
Mon projet:
http://www.first-world.info/fichier/apps.zip
Voila ce que je veux faire:
Dans mon threads créer et exécuter quand clique sur le menu dans le + en mode avancer, qu'il ouvre un fenêtre pour sélectionner un dossier source et un dossier de destination, puis quand créer une liste de copie par le thread pour pas faire ramer l'application principal, le problème et comme passer et recevoir des variables de mon thread, comment exécuter des méthode de l'objet de ma fenêtre principal, pour faire que le thread est une main sur la fenêtre de l'application principal pour modif les boutons et les zones de texte.
J'ai trouver plein de méthode, j'arrive à en appliquer aucune, et rien n'est trés clair, comment faire ça simplement?

Réponses

  • passer des variables au thresad ok, mais rien de graphique
  • Salut,

    En supplément de la réponse de Nicolas, si tu veux qu'un thread génère un événement graphique, il te faudra avoir 2 choses:
    1. un signal dans le thread pour demander cette action
    2. Un slot récepteur dans la classe la plus appropriée qui tourne dans le thread principal pour recevoir cette demande et executer ton appel.

    De façon générale, il est préférable d'adopter cette méthode lorsque le thread perso a besoin de faire faire quelque chose au thread GUI.
  • Merci de vos conseille avisé, je vais essayer de faire comme ça.
  • Bonjour, j'ai un petit problème, que je comprend pas et qui parait illogique. J'ai bien mes class, et les connexion signal slot marche bien sauf dans un cas, j'ai bien connecter mon signal à mon slot, le signal est bien émit, rien n'est dit en console d'alarmant, quand on lance le slot à la main ça marche.
    Voila ma source, qmake --project, qmake, make:
    http://www.first-world.info/fichier/signal.tar.bz2
    Dans ma class j'ai bien:
    connect(AddingFolderThread, SIGNAL(setTo(QString&)), this, SLOT(setTo(QString&)));
    Et le signal est bien émit:
    emit setTo(temp);
    Mais le slot:
    void Main_window::setTo(QString& texte)
    n'est pas exécuter par le signal, mais il peu être exécuter directement.

    Tout à l'air bon, et les signaux/slot dans l'autre sens marche trés bien, si quelqu'un pouvais jeter un coup d' œil ce serai gentil. Je vous remerci d'avance.
  • Va sur ce post très instructif d'IrmatDen, tu auras sûrement une piste pour ton problème :
    http://forum.qtfr.org/viewtopic.php?pid=32052#p32052
  • December 2007 modifié
    dans la fonction bool Main_window::addFolder()
        disconnect( AddingFolderThread, SIGNAL(setTo(QString&)), this, SLOT(setTo(QString&)) );
    AddingFolderThread->start();
    et dans void Thread::run()
        emit setTo(temp);
    comment un slot deconnecté pourait-il être exécuté?
  • je ne vois pas l'intéret d'un thread pour sélectionner des fichiers et des répertoires
    un QFileDialog bloquant (fd->exec()) ou non bloquant (fd->show()) devrait faire l'affaire

    si j'ai bien compris, tu veux faire de la copie/transfert/sauvegarde/déplacement de fichiers/répertoires
    à ce stade seulement, le thread devient vraiment intéressant
    je verrais ça comme cela (shématiquement) :
    mainWindow::mainWindow( ... ) : QMainWindow( ... )
    {
    // ...
    connect( pbStart, SIGNAL(clicked()), SLOT(on_pbStart_clicked()) );
    }
    void mainWindow::on_pbStart_clicked()
    {
    th = new Thread( ... );
    connect( th, SIGNAL(terminated()), SLOT(on_th_terminated()) );
    // dire au thread ce qu'il doit faire
    th->start();
    }
    void mainWindow::on_th_terminated()
    {
    delete th;
    // eventuellement afficher un compte-rendu
    }
    et dans Thread::run() tu implémentes ce qui doit être fait
  • December 2007 modifié
    En fait, il faut constituer un liste des fichiers copiés, ce qui est très long quand on copie 500 000 fichier, donc pour pas bloquer le thread graphique, je délègue ça à un autre threads qui affiche dans le thread graphique un avancement. Et c'est exact ce que tu as dit, en mode débugage je vois clairement que le signal est déconnecter puis exécuté.
    Moi je vois le thread comme ça:
    1) demande des dossier source et de destination
    2) désactivation de la liste de la fonctionnalité pour pas avoir 2 thread en même temps
    3) création de la liste de lecture et affichage de la progression
    4) réactivation de la fonction

    Ca devrai marche et voila ce que j'obtiens:
    QObject::connect: Cannot queue arguments of type 'QString&'
    (Make sure 'QString&' is registered using qRegisterMetaType().)
    On m'as dit que ça pouvais venir des QString&, mais c'est bizard, car j'utilise les connexions comme ça et j'ai jamais eu de problèmes.
  • alpha_one_x86 said:
    Moi je vois le thread comme ça:
    1) demande des dossier source et de destination
    2) désactivation de la liste de la fonctionnalité pour pas avoir 2 thread en même temps
    3) création de la liste de lecture et affichage de la progression
    4) réactivation de la fonction
    Moi j'aurais vu :
    3) création de la liste de lecture et informe le thread principal de la progression (affichage de la progression dans l thread principal .... )

    1,2 et 4 pouvant etre fait sans probleme dans le thread principal ...
  • 1, 2 et 4 déjà dans le thread principal, tu m'a convaincu pour le laisser dans le thread principal

    par contre regarde mon edit:

    Ca devrai marche et voila ce que j'obtiens:
    QObject::connect: Cannot queue arguments of type 'QString&'
    (Make sure 'QString&' is registered using qRegisterMetaType().)
    On m'as dit que ça pouvais venir des QString&, mais c'est bizard, car j'utilise les connexions comme ça et j'ai jamais eu de problèmes.
  • de la meme maniere que tu ne met pas les const, il ne faut pas mettre les &
    donc :
    connec(tAddingFolderThread, SIGNAL(setTo(QString)), this, SLOT(setTo(QString)) )
  • Salut,

    Je ne peux que plussoyer le post de lud42fr; les QString sont basés sur COW, donc ne pas utiliser de références se révélera finalement assez peu couteux (en admettant dans ce contexte que tu ne t'en sers pas pour les modifier ce qui me paraît plus que judicieux dans un contexte multi-thread...)
  • IrmatDen said:
    Salut,

    Je ne peux que plussoyer le post de lud42fr; les QString sont basés sur COW, donc ne pas utiliser de références se révélera finalement assez peu couteux (en admettant dans ce contexte que tu ne t'en sers pas pour les modifier ce qui me paraît plus que judicieux dans un contexte multi-thread...)
    COW ????
  • Pardon, Copy On Write.
    Pour résumer, QString contient un pointeur partagé vers les données. Le constructeur par copie ne fait qu'utiliser le pointeur de l'autre tant que tu ne cherches pas à modifier son contenu. Lorsque tu modifies la chaîne, le contenu est alors copié puis modifié de façon à ce que cette chaîne soit unique, et que l'instance précédente reste intacte.
    D'où le fait que passer une QString par copie est préférable dans tout les cas où la chaîne n'a pas besoin d'être renvoyée modifiée (auquel cas, un passage par pointeur sera plus judicieux parce que l'appellant a plus de chances de comprendre plus ou moins instinctivement que ce sera modifié).
  • December 2007 modifié
    à l'attention d'alpha_one_x86
    lud42fr said:
    de la meme maniere que tu ne met pas les const, il ne faut pas mettre les &
    donc :
    connec(tAddingFolderThread, SIGNAL(setTo(QString)), this, SLOT(setTo(QString)) )
    je me permet de rajouter le "pourquoi"

    si, dans une fonction, on passe à un slot une référence à une variable locale par l'intermediaire d'une "QueuedConnection" (ie: le slot n'est pas exécuté immédiatement),
    cette variable a de fortes chanches de ne plus exister au moment de l'exécution du slot.
    son référencement provoquera très probablement un crash
  • merci pour ces infos, je vais essayer de mettre tout ça en pratique.
Connectez-vous ou Inscrivez-vous pour répondre.