Rafraichissement de la vue QTableView

**katanaenmousse** · 28/01/2019, 09h29

Bonjour à tous,

lorsque je charge un nouveau QSqlQueryModel dans mon QTableView j'obtiens des bugs d'affichage sur les couleurs du fond des lignes du tableau.

Il est vrai que mon modèle contient 40 colonnes et plus de 40 000 lignes en moyenne et que parfois il peut en contenir jusqu'à 150 000.

Dans mon modèle j'utilise en plus un code pour changer la couleur du fond des lignes en fonction du contenu de la colonne 38.
Voici le code utilisé :

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
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
QVariant ModeleFenTrafic::data(const QModelIndex &index, int role) const {  
     static std::set<int> ligneVertes;
     switch(role) {
         case Qt::BackgroundRole:
 
         int ligneCourante=index.row();
         int lignePrecedente=ligneCourante-1;
         if(lignePrecedente<=0) lignePrecedente=0; 
         if(ligneSuivante>=index.model()->rowCount()) ligneSuivante=index.model()->rowCount(); 
         // je ne m'intéresse qu'à la colonne 38 
         QString valeurPrecedente=index.model()->data(index.model()->index(lignePrecedente,38)).toString();
         QStringvaleurCourante=index.model()->data(index.model()->index(ligneCourante,38)).toString(); 
         if(valeurCourante==valeurPrecedente) 
         {  
              std::set<int>::iterator it=find(lignesVertes.begin(),lignesVertes.end(),lignePrecedente);
             if(it!=lignesVertes.end())
             { 
                  lignesVertes.insert(index.row()); 
                  QBrush newBackground(Qt::green); 
                  return newBackground; 
             } 
             else 
             { 
                  QBrush newBackground(Qt::blue); 
                  return newBackground; 
             } 
         } 
         else 
         {
             std::set<int>::iterator it=find(lignesVertes.begin(),lignesVertes.end(),lignePrecedente);
             if(it!=lignesVertes.end())
            { 
                   QBrush newBackground(Qt::blue); 
                   return newBackground; 
               }
               else 
               {
                   lignesVertes.insert(index.row()); 
                   QBrush newBackground(Qt::green); 
                   return newBackground; 
                } 
          } 
          break;
     } 
return QSqlQueryModel::data(index,role); 
}

pour mettre mon QTableView à jour je fais simplement
tableau->setModel(monModele);

Mais là, le modèle est bien chargé, les données sont les bonnes et tout est bien raffraichi dans mon QTableView sauf la couleur des lignes après environ 20 000 lignes (tout se passe bien par contre pour les 20 000 premières lignes environ)

Après ces 20 000 premières lignes les couleurs de fond des lignes ne correspondent plus.
Toutefois si je refais remonter les lignes du QTableView avec la molette de la souris, puis que je refais descendre les lignes pour les afficher à nouveau, là, elles sont de la bonne couleur.
Je pense donc à un problème de raffraichissement de l'affichage.

Comment résoudre ce souci selon vous? Quelqu'un aurait des pistes?
Merci à vous

**koala01** · 28/01/2019, 15h10

Salut,

Il n'y a rien à faire: une vue de 40 champs pour 40 000 (ou pire, pour 150 000) enregistrements, moi, ca me semble excessif. Ne serait-ce que parce que tu as forcément un(e) pauvre malheureux (se) qui va s'user les yeux à essayer de comprendre toutes les informations que tu lui envoies!

Et le simple fait de trouver "l'information qui l'intéresse" parmi 40 champs "qui n'ont rien à voir" d'un seul enregistrement, moi, ca me semble pour le moins compliqué. Alors, s'il faut -- en plus -- trouver le seul enregistrement qui l'intéresse parmi 40 000 (ou pire 150 000) autre, tu imagines un peu la galère que cela pourrait être

S'il s'agissait de traiter dynamiquement tous ces enregistrements, je suis persuadé qu'un ordinateur devrait être capable de le faire. Mais, dés que tu fais entrer un humain dans la danse, je crois sincèrement que tu devrais t'arranger pour que la réponse aux différentes requêtes soit "moins importante".

Après tout, nous sommes dans le domaine d'une vue, et qui plus est, d'une vue tabulaire. Dés lors, pourquoi veux tu impérativement surcharger cette vue en fournissant les 40 champs pour les 40 000 enregistrements

Ne pourrais tu pas envisager de "peaufiner" tes requêtes pour fournir, par exemple, seulement 10 champs pour, mettons, un petit millier d'enregistrements à la fois

Bien sur, cela signifierait que tu aurais sans doute quatre vues différentes (une pour chaque groupe de 10 champs à montrer), et que tu aurais sans doute 40 à 150 pages par vues (une par groupe de 1 000 enregistrements). Mais cela ne pourrait-il pas très nettement faciliter le travail de la personne qui pose les yeux dessus

Et, par la même occasion, cela te permettrait de "contourner" le problème du bug à l'affichage, vu qu'il n'y aurait plus jamais 20 0000 lignes à afficher

Soyons bien clair : je n'ai absolument aucune idée du genre de base de données que tu attaques. Les valeurs que je donnes ici (10 champs pour 1 000 enregistrements) sont tout à fait arbitraires, et sujettes à adaptation de ta part. Mais, de manière générale, il faut toujours te dire que, quand tu arrives au niveau de la vue, il y aura "quelqu'un" qui voudra l'analyser. Et qu'il faut prendre soin de son pauvere malheureux cerveau

**katanaenmousse** · 29/01/2019, 09h07

Merci Koala pour ta réponse (une fois de plus)

Il n'y a rien à faire: une vue de 40 champs pour 40 000 (ou pire, pour 150 000) enregistrements, moi, ca me semble excessif. Ne serait-ce que parce que tu as forcément un(e) pauvre malheureux (se) qui va s'user les yeux à essayer de comprendre toutes les informations que tu lui envoies!

Et le simple fait de trouver "l'information qui l'intéresse" parmi 40 champs "qui n'ont rien à voir" d'un seul enregistrement, moi, ca me semble pour le moins compliqué. Alors, s'il faut -- en plus -- trouver le seul enregistrement qui l'intéresse parmi 40 000 (ou pire 150 000) autre, tu imagines un peu la galère que cela pourrait être

Je suis moi même habitué à afficher des tableaux plus courts et plus parlants donc en général je te rejoins sur ce point. Toutefois mon code est en fait le code d'un programme que j'ai développé en Python / Gtk et qui a donné lieu à plusieurs versions.
Celle que les utilisateurs préfèrent est la version qui affiche ce fameux tableau de 100 000 ou 150 000 lignes. les données sont chronologiques et de ce fait l'utilisateur s'y repère simplement avec dans les 40 colonnes toutes les infos qu'il souhaite sans devoir requeter à nouveau la base. c'est un choix qu'a été fait par plus de 340 utilisateurs sur presque 400. Deplus une fonction dans le tableau permet de retrouver un enregistrement spécifique rapidement.
Pour cette raison je souhaite conserver la possibilité d'afficher les 100 ou 150 000 lignes. Sachant qu'une autre fenetre permet d'afficher une vue par un nombre de lignes maxi défini par l'utilisateur dans les parametres du logiciel.
Je dis ça pour répondre à ton commentaire tout à fait légitime et que tu comprennes l'importance pour moi d'afficher toutes les lignes.

Pour revenir à mon problème,
j'ai lancé un débugage en affichant dans un fichier texte les valeurs de la ligne précédente et de la ligne courante ainsi que le résultat du test de présence de la valeur précédente dans le set.
Et là j'ai un résultat surprenant. J'ai parfois ceci:
ligne précédente n° 21572 = "ABCDEF" est dans le set ligneVerte -- ligne courante n° 21573 = "GFTDS" : est différente de précédente - doit être bleue - donc pas d'ajout au set
ligne précédente n° 21573 = "GFTDS" est dans le set ligneVerte -- ligne courante n° 21574 = "GFTDS" : est égale à précédente - doit être verte - donc ajout au set

On voit donc bien que la ligne 21573 qui est bleu et n'est pas ajouté au set ne devrait pas se retrouver dans le set lorsque l'on teste la ligne précédente (voir erreur soulignée ci dessus) de la ligne 21574
Et je ne comprends pas comment elle peut se retrouver dans le set. Surtout qu'avant les 20 000 lignes cette erreur ne se produit pas.

**koala01** · 29/01/2019, 12h00

Envoyé par katanaenmousse

Merci Koala pour ta réponse (une fois de plus)

Je suis moi même habitué à afficher des tableaux plus courts et plus parlants donc en général je te rejoins sur ce point. Toutefois mon code est en fait le code d'un programme que j'ai développé en Python / Gtk et qui a donné lieu à plusieurs versions.
Celle que les utilisateurs préfèrent est la version qui affiche ce fameux tableau de 100 000 ou 150 000 lignes. les données sont chronologiques et de ce fait l'utilisateur s'y repère simplement avec dans les 40 colonnes toutes les infos qu'il souhaite sans devoir requeter à nouveau la base. c'est un choix qu'a été fait par plus de 340 utilisateurs sur presque 400. Deplus une fonction dans le tableau permet de retrouver un enregistrement spécifique rapidement.
Pour cette raison je souhaite conserver la possibilité d'afficher les 100 ou 150 000 lignes. Sachant qu'une autre fenetre permet d'afficher une vue par un nombre de lignes maxi défini par l'utilisateur dans les parametres du logiciel.
Je dis ça pour répondre à ton commentaire tout à fait légitime et que tu comprennes l'importance pour moi d'afficher toutes les lignes.

Oh, tu sais, moi, je me contentais d'une réflexion d'ordre tout à fait générale sur ce point.

Si les utilisateur préfèrent s'user les yeux, nous n'allons pas les contredire, hein

Pour revenir à mon problème,
j'ai lancé un débugage en affichant dans un fichier texte les valeurs de la ligne précédente et de la ligne courante ainsi que le résultat du test de présence de la valeur précédente dans le set.
Et là j'ai un résultat surprenant. J'ai parfois ceci:
ligne précédente n° 21572 = "ABCDEF" est dans le set ligneVerte -- ligne courante n° 21573 = "GFTDS" : est différente de précédente - doit être bleue - donc pas d'ajout au set
ligne précédente n° 21573 = "GFTDS" est dans le set ligneVerte -- ligne courante n° 21574 = "GFTDS" : est égale à précédente - doit être verte - donc ajout au set

On voit donc bien que la ligne 21573 qui est bleu et n'est pas ajouté au set ne devrait pas se retrouver dans le set lorsque l'on teste la ligne précédente (voir erreur soulignée ci dessus) de la ligne 21574
Et je ne comprends pas comment elle peut se retrouver dans le set. Surtout qu'avant les 20 000 lignes cette erreur ne se produit pas.

Juste par acquit de conscience, quel est le type réel de la donnée qui sert de comparaison

Ne serait-ce pas -- à tout hasard -- un float ou un double

Et, sinon, je viens de constater que tu as choisi d'utiliser un std::set static dans la fonction elle-même, ce qui correspond à l'alternative à l'utilisation d'une donnée membre marquée mutable.

Se pourrait-il -- à tout hasard -- que tu travailles avec le résultat de deux requêtes qui fournissent deux résultat "presques similaires", à l'exception d'un enregistrement de plus / de moins au alentours du 21 572eme

Comme tu ne maintiens la liste des lignes qui doivent être colorées que "par le bout des ongles" (au travers d'une seule valeur issue d'un QItemIndex), cela rejoindrait le problème contre lequel j'ai essayé de te mettre en garde lorsque j'ai évoqué la solution: si deux requêtes fournissent des résultats "presque similaires", les éléments placés dans ligneVertes du fait de la première requête resteront dans ligneVertes quand tu traitera le résultat de la deuxième requête.

Malgré toute l'aversion que je peux comprendre que tu aies et tous les risques liés à cette pratique, as-tu tenté de définir ligneVertes comme étant une donnée membre mutable

Cela pourrait peut-être corriger un problème dont tu n'aies même pas forcément conscience et qui serait lié à la création de plusieurs modèles qui partageraient le contenu de ligneVertes de par son aspect static actuel.

L'étape suivante étant -- bien sur -- de déterminer à quel endroit du code le modèle serait "re créé" de manière injustifiée

**katanaenmousse** · 29/01/2019, 15h56

merci Koala pour tes précieux conseils, sans toi je n'en serai sûrement pas arrivé jusque là.

Pour ceci :

Oh, tu sais, moi, je me contentais d'une réflexion d'ordre tout à fait générale sur ce point.

Je l'avais bien pris comme tel mais je tenais à t'expliquer pourquoi j'avais fait ce choix particulier.

pour en revenir au problème de l'affichage des lignes vertes:

J'ai remplacé le static stc::set par un mutable QList<int>, le problème reste le même...

Pour ce point :

si deux requêtes fournissent des résultats "presque similaires", les éléments placés dans ligneVertes du fait de la première requête resteront dans ligneVertes quand tu traitera le résultat de la deuxième requête.

Je n'ai qu'une requête qui n'est pas renouvelée sans la destruction complète de l'objet qui contient la variable mutable. Donc aucun souci à priori.

Par contre, suite à ta remarque :

L'étape suivante étant -- bien sur -- de déterminer à quel endroit du code le modèle serait "re créé" de manière injustifiée

je me pose la question de savoir si ces erreurs ne pourraient pas être liées à ce bout de code qui sert à remplir mon modèle avec la réponse à la requete Sql:

Code :

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

1
2
3
4
5
6
 
monModelSqlQuery.setQuery(requeteSql, connexionBdd);
while(monModelSqlQuery.canFetchMore())
{
      monModelSqlQuery.fetchMore();
}

Ce bout de code n'aurait il pas des conséquences sur la re creation de mon modèle?

**koala01** · 30/01/2019, 18h59

Envoyé par katanaenmousse

J'ai remplacé le static stc::set par un mutable QList<int>, le problème reste le même...

Il n'est pas exclu qu'il y ait un bug au niveau des QAbstractItemModel dans Qt à ce niveau là...

Si oui, il y a fort à parier que c'est un problème qui s'accroche depuis de nombreuses versions, et nous devrions donc pouvoir le retrouver dans le bugtracker, et le seul moyen de l'éviter sera le contournement honteux : éviter d'avoir plus de 20 000 lignes de données à traiter à la fois

Est-ce que le problème se pose toujours à peu près à partir de la même ligne (à une ou deux centaines près, dirions nous)

Je n'ai qu'une requête qui n'est pas renouvelée sans la destruction complète de l'objet qui contient la variable mutable. Donc aucun souci à priori.

Je ne dispose que d'une infime partie de ton code, et je ne connais absolument pas ton projet. Je m'efforce donc d'ouvrir un maximum de voies de réflexion, pour être sur de ne rien "laisser au hasard"

Par contre, suite à ta remarque :

je me pose la question de savoir si ces erreurs ne pourraient pas être liées à ce bout de code qui sert à remplir mon modèle avec la réponse à la requete Sql:

Code :

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

1
2
3
4
5
6
 
monModelSqlQuery.setQuery(requeteSql, connexionBdd);
while(monModelSqlQuery.canFetchMore())
{
      monModelSqlQuery.fetchMore();
}

Ce bout de code n'aurait il pas des conséquences sur la re creation de mon modèle?

A priori, j'aurais tendance à dire que non, car c'est bel et bien la manière conseillée lorsque ton système de base de données n'est pas capable de fournir le nombre d'enregistrements renvoyé par une requête.

Comme je ne sais déjà pas quelle base de données est utilisée en arrière plan, je ne sais pas s'il y a ne serait-ce que moyen de faire autrement

Et, quand bien même il y aurait moyen de s'y prendre autrement, je ne vois pas vraiment la raison pour laquelle cette technique se mettrait subitement à partir en couille

Maintenant, en fonction du système de gestion de base de données que tu utilises, il se peut que tu puisse récupérer le nombre d'enregistrements renvoyés par la requête, et qu'il soit alors "plus facile" de travailler en les récupérant d'une autre manière.

Bien que je n'y croies pas trop, si tu as cette possibilité, autant l'essayer pour voir si le problème persiste ou non. Mais comme je te l'ai dit, je ne vois pas trop pourquoi la première technique partirait en couille.

Cependant, je ne participe à Qt que de manière très intermittente et je ne fais absolument pas attention à tous les rapports de bugs qui peuvent être émis. Je n'écarte donc pas non plus la possibilité qu'il y ait un rapport de bug pour lequel le work around consisterait -- en attendant de trouver un correctif au problème -- à utiliser une autre méthode si le système de gestion de base de données est capable d'indiquer le nombre d'enregistrements renvoyés par la requête.

Autant éviter de fermer la moindre porte avant d'avoir été vérifier précisément ce qui se cache derrière

**katanaenmousse** · 30/01/2019, 20h38

si oui, il y a fort à parier que c'est un problème qui s'accroche depuis de nombreuses versions, et nous devrions donc pouvoir le retrouver dans le bugtracker, et le seul moyen de l'éviter sera le contournement honteux : éviter d'avoir plus de 20 000 lignes de données à traiter à la fois

En fait j ai essayé avec 500 lignes en conservant mutable QList<int>
Résultat même souci
Je remarque aussi que Certaines cellules ne sont même pas complètement colorées quand je descends l ascenseur du QTableView, ce qui fait penser à un bug d affichage.
Pour la base c est SQLite et MySQL (selon le choix utilisateur le code modifie les requêtes )
Bref je vais devoir abandonner la couleur de fond si ça continue... je désespère

Rafraichissement de la vue QTableView

Qt

Discussions similaires

Partager

Partager