Equivalent de TStringGrid.Cols[x].IndexOf pour réponses multiples

Bonjiour,

Je cherche une valeur dans une colonne de StringGrid sachant que la valeur figure plusieurs fois dans cette colonne. Le numéro de la ligne en cas de valeur trouvée est stockée dans une StringList. Ensuite j'applique un traitement particulier à chaune des lignes.

Le parcours séquentiel de la StringGrid affichée -et l'affichage ne doit pas changer pendant le traitement- donne des résultats désastreux en terme de rapidité :

Code:

---

1 2	for iRow := 0 to SG.Rowcount -1 do if SG.Cells[x, iRow] = sValeur then SL.Add(IntToStr(iRow)) ;

---

Comment peut-on optimiser un tel traitement ?

Cordialement. Gilles

à part utiliser pour les indices des lignes un tableau dynamique d'entiers prédimensionné puis réduit au nombre trouvé, je ne vois pas...

mais dans ton titre, tu parles de cols[x] : pê plus rapide sans repasser par Cells :

Code:

---

1 2 3

with SG.Cols[x] do for i:=0 to Lines.Count-1 do if Lines[i]=sValeur then... ;

---

Bonjour,

Oui, j'ai commencé quelque chose du même genre. Le problème est en réalité la constitution de colonnes d'une SG principale à partir de SG secondaires imbriquées. Pour toutes les SG secondaires, le IndexOf convient car les valeurs sont uniques...

Pour illustrer le problème, un exemple "apparenté" serait 3 SG secondaires articulées ainsi sgVEHICULE-->sgMARQUE-->sgMODELE
La StringGrid principale serait alors sgFACTURE qui contient n fois (mais n peut atteindre 100) le même véhicule. Ce qui fait que, au moment de son remplissage initial, sgFACTURE va faire un grand nombre de fois le traitement 'Quel véhicule ?" de manière inutile. Avec des SGDBR, le traitement est usuel et automatisé... Mais là, je suis en pur SG.

18H00... Finalement, je pense régler le problème ainsi, sans passer par une StringGrid temporaire comme l'idée m'était venue initialement. Evidemment, le code est incomplet :

Code:

---

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

Deb := Now; iRow := 0; nChanged := 0; while iRow > -1 do begin iRow := sgFA.Cols[x].IndexOf('14875'); if iRow > -1 then begin sgFA.Cells[x,iRow] := '@14875'; //On change le champ pour pouvoir réutiliser IndexOf inc(nChanged); if nChanged = 1 then begin //On calcule la valeur du Champ dans la cellule concernée [...] end else begin //On copie dans la Cellule concernée [...] end; end; end; if nChanged > 0 then begin iRow := 0; while iRow > -1 do begin iRow := sgFA.Cols[x].IndexOf('@14875'); //Evidemment on rechange... if iRow > -1 then sgFA.Cells[x] := '14875'; end; end; Fin := Now; Showmessage(FloatToStr(Fin-Deb) + ' --> ' + IntTostr(nChanged));

---

Mais, même sans optimisation, je ne pensais pas me heurter à une telle latence en utilisation pure de la mémoire... avec des StringGrids. En prenant la durée des traitements élémentaires de recherche, même avec un parcours séquentiel de la SG principale, je ne comprends pas comment il me fallait 4s.

Encore merci pour votre aide.
Cordialement. Gilles

Bon finalement, je suis passé par des array of array.

Dans l'application que je développe actuellement, le temps est un facteur critique. Je pars d'une base mySQL distante hébergée mais l'utilisation de requêtes distantes n'est pas envisageable pour 2 raisons : la lenteur et la fiabilité.

Dans un premier temps, j'ai essayé le plus facile : je me connecte à la base distante et je remplis une base SQLite locale. C'est un peu long au départ mais le temps n'est pas un facteur critique à l'initialisation du programme. Mais mauvaise surprise, pour les requêtes d'exploitation, le couple SQLite local +Zeos est extrêmement lent. Le remplissage et l'actualisation de certaines dbGrids est presqu'aussi lent que les mêmes utilisant le mySQL distant hébergé + Zeos.

Dans un deuxième temps, j'ai chargé mes tables dans des StringGrids de "référence". C'est mieux. mais dans certains cas, dont celui exposé ci-dessus, la latence de chargement des StringGrids "visuelles" ou leur actualisation est perceptible (ie gênante).

Finalement, j'ai utilisé des array of array. Et là, cela fonctionne correctement. Ce qui m'étonne un peu c'est que même en essayant d'optimiser les StringGrids (qui sont stockées en mémoire), le résultat laisse à désirer. Que cela soit pour les tris ou les recherches, l'usage des array of array est vraiment plus rapide. Est-ce que les IndexOf sont mal optimisés, les tris des colonnes ? Où y-a-t-il des procédures parasites inutiles (Drawcell & Cie sur des SG invisibles) dans mon cas ? Je ne sais pas et comme je suis en production, je n'ai pas le temps de re-re-regarder les StringGrids...

Cordialement. Gilles