Discussion :

[ApproxDev]

Bonjour,

je voudrais remplir un QtableWidget (et non une QTableView) en utilisant QConcurrent.
J'arrive à mes fins mais j'ai dû ajouter dans mon main.cpp

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
    qRegisterMetaType<QVector<int> >("QVector<int>");
    qRegisterMetaType<QList<QPersistentModelIndex> >("QList<QPersistentModelIndex>");
    qRegisterMetaType<QItemSelection>("QItemSelection");
    qRegisterMetaType<QAbstractItemModel::LayoutChangeHint>("QAbstractItemModel::LayoutChangeHint");

sans trop comprendre quel est exactement le problème.

Cependant, j'ai lu plusieurs fois que piloter des éléments graphiques de la fenêtre (QTableWidget en est un) à partir d'un code appelé par le thread était "malsain" ?
Donc, existe-t-il une approche "recommandable" pour utiliser une requête SQL dans un thread secondaire ? Est-ce compatible avec le remplissage d'un QTableWidget de la manière suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
          ui->table->setUpdatesEnabled( false ) ;
          ui->table->setRowCount(query.size());
 
          int index=0;
          while (query.next())
          {
              ui->table->setItem(index,0,new QTableWidgetItem(query.value(0).toString()));
              ui->table->setItem(index,1,new QTableWidgetItem(query.value(1).toString()));
              ui->table->setItem(index,2,new QTableWidgetItem(query.value(2).toString() + " " + query.value(3).toString()));
              ui->table->setItem(index,3,new QTableWidgetItem(query.value(4).toString()));
              index++;
               if (bfutureStop == true) return;
          }
 
 
        //Lancer le tri par défaut
          sortCol = 2;
          sortOrder = Qt::AscendingOrder;
          ui->table->sortByColumn(3, sortOrder);
          ui->table->sortByColumn(2, sortOrder);
 
       //Select First Row
          ui->table->selectRow(0);
          ui->table->setUpdatesEnabled( true ) ;

Merci.

[jlbrd]

Bonjour,

Pourquoi tu ne passe pas par les signaux et slots qui sont sûrs entre thread. Dans ton thread qui lit la BDD tu mets un emit et tu récupère le message dans un slot du thread principal qui pilote l'interface graphique.

[ApproxDev]

Bonjour,

Non, cette option ne fonctionne pas à ma connaissance et suivant mes tests.
Des approches avec modification de Qt :: ConnectionType (Qt :: QueuedConnection ou Qt :: BlockingQueuedConnection ) restent limitées.

Cdlt.

[dourouc05]

Cependant, j'ai lu plusieurs fois que piloter des éléments graphiques de la fenêtre (QTableWidget en est un) à partir d'un code appelé par le thread était "malsain" ?

Le dessin s'effectue uniquement dans un fil d'exécution, tenter des modifications de l'extérieur donnera des messages d'erreur.

Non, cette option ne fonctionne pas à ma connaissance et suivant mes tests.

Et… ? C'est un peu court, jeune homme !, s'exclame un squelette. Qu'est-ce qui ne fonctionne pas ? Pour Qt, c'est vraiment l'approche à privilégier dans pas mal de cas. Quels tests as-tu effectués ? Quel en a été le résultat ?

Cdlt.

Moi aussi, j'aime écrire des choses imprononçables.

[ApproxDev]

Bonjour,

Cdlt : Cordialement. Une abréviation comme WE, comme Qt qui est plutôt un acronyme.

Pour le reste, accéder à une base distante (par internet) et charger quelques enregistrements gèlent l'interface graphique... même avec des signaux et slots, surtout s'ils sont issus de cet interface graphique. J'en ai fait l'expérience et c'est clairement exprimé dans certaines mais rares discussions anglo-saxonnes. Il y a la théorie générale (le thread) et son utilisation appliquée à des cas particuliers (ici l'accès à une base de données distante et le parcours d'une table importante en nombre d'enregistrements à usage statistique avec le rafraîchissement régulier du GUI pendant toute la durée de l'opération). Sur un petit volume, ce gel est à peine perceptible. Mais telle n'est pas ma situation. Ceci dit le web est vaste et je ne prétends pas avoir parcouru toutes les solutions. Il y a peut-être moyen d'échapper à cette contrainte, de la contourner, d'autant que les évolutions de Qt sont significatives et fréquentes. Ce qui était impossible pour un auteur il y a 2 ans, est peut-être réalisable facilement actuellement. C'était la deuxième partie de ma question initiale.

Pour la première partie,

J'arrive à mes fins mais j'ai dû ajouter dans mon main.cpp[...]

je demandais un petit peu d'éclaircissement sur la réclamation exprimée au débogage qui, une fois satisfaite, fonctionne correctement. Je suis incapable d'expliquer correctement le mécanisme qui conduit à l'expression de cette insuffisance (au niveau déclaration) précisée par le débogueur.

Enfin pour ma réponse, celle-ci signifie simplement à mon interlocuteur que ce qu'il propose est une piste que j'ai explorée au début et que je qualifie de limitée dans le cadre de mon exploitation. D'un autre côté, ma réponse est aussi laconique (i.e. sans code) que la sienne, mais pas plus.

Au final, je n'insiste pas. Je considère le problème comme résolu surtout si "d'une manière générale", il est facile de le traiter classiquement.

Cordialement.

[loupium]

Bonsoir,

d'autant que les évolutions de Qt sont significatives et fréquentes. Ce qui était impossible pour un auteur il y a 2 ans, est peut-être réalisable facilement actuellement.

La partie sql à peu évoluée depuis Qt4 car elle est "mature".
Voici un peu de lecture datant de 2007 mais qui reste d'actualité : http://www.linuxjournal.com/article/9602
(4 pages)

Au faite, mon bout de code sur le Drag and Drop entre QTableWidgets t'a servi ?

[jlbrd]

Bonjour,

Bon j'ai pris quelques minutes pour tester le concept. voici le projet qwidgetthreadtest.zip. Un thread se charge de lire les données toutes les 100 ms (dans cet exemple on ne lit rien mais ce n'est pas le problème). L'info est ensuite envoyée par un signal et reçu dans le slot slotMsg qui se charge d'ajouter une ligne dans le QTableWidget. Enfin la "mini calculatrice" permet de voir que le programme principal ne semble pas ralenti.
Voila je ne sais pas si ça correspondant à ta demande ni si ça va te servir.

[ApproxDev]

Bonjour Jlbrd,

Sympa... et merci pour le temps passé. Je branche ma base de données sur ton travail (enfin je vais créer une SQLite à la place de la base MySQL pour le retour de test) et te tiens au courant.
Mais j'émets déjà un "signal" : tu lances ton thread à partir d'un bouton, fenêtre ouverte et dessinée donc. Ce ne sera pas mon cas. Je lance mon thread à l'ouverture de la fenêtre et cela change beaucoup de choses contrairement à ce qu'on pourrait croire. Donc, il faut que la fenêtre et tous ses composants se dessinent et que le lancement du thread soit automatique. A partir de "ce" moment (de ces moments) la progression du chargement de la table SQL et les divers messages s'il y a lieu sont affichés.

La semaine est un peu chargée... mais j'essaie avant vendredi prochain. Cordialement.

[jlbrd]

Salut voici une version un peu différente qwidgetthreadtestdb.zip dont le thread lit une base SQLite. Le programme commence par créer et alimenter la base si nécessaire puis lance le thread qui lit cette bdd et émet par signal les infos. Une ligne est insérée ou mise à jour dans le QTableWidget suivant si la ligne existe déjà ou pas. Deux diodes permettent de visualiser les ajouts et le mises à jour. Au début on a que des ajouts qui diminuent de plus en plus. Tout ça semble fonctionner correctement sans ralentir l'interface principale qui est pourtant bien plus mise à jour.