Bonsoir,
Voir l'image ci-dessous qui montre une même StringGrid triée en ordre ascendant à gauche et descendant à droite.
Pièce jointe 383791
Ça me laisse perplexe. Et vous ?
Version imprimable
Bonsoir,
Voir l'image ci-dessous qui montre une même StringGrid triée en ordre ascendant à gauche et descendant à droite.
Pièce jointe 383791
Ça me laisse perplexe. Et vous ?
Bonsoir
Alors effectivement ça laisse perplexe mais il ne faut pas oublier que la comparaison est faite sur des chaine de caractères par exemple le chiffre "1" correspond au code 48 et la "a" à "97" du coup 11 est avant 1a ou inversement selon le sens.
Si tu veux souhaites avoir un meilleur résultat il te faudra passer par l'événement "onCompareCell" je penses.
Bonne nuit ;)
Je vois ce que tu veux dire mais tu semble oublier que 11.jpg ( soit 4848 ) est aussi considéré comme plus petit que 1.jpg ( 48 ) ce qui casse un peu le raisonnement.
Par contre si je renomme les fichiers:
001.jpg
01a.jpg
011.jpg
L'ordre est correct.
Si j'enlève un 0 c'est correct pour 01.jpg et 11.jpg mais 1a.jpg repasse en fin de liste. Donc la solution temporaire est une fonction qui renomme les fichiers en complétant tous les noms avec des 0. Facile à faire mais quand même bizarre, ça me semble être un gros bug de Lazarus ( 1.8.0 ) il va falloir que je me penshe sur la 1.8.4 pour voir si ça fait la même chose.
Pour oncomparecell c'est sans doute une idée il semble à première vue que ça revienne à y écrire une fonction de tri à bulles. Un peu galère quand même. En plus si la comparaison est la même que celle qui sert au tri je vais avoir le même résultat. 11 sera toujours < que 1 et 1 < que 1a. Y-en a bordel...
hello,
il semblerait que tu sois sous linux car sous windows on n'a pas le même résultat. Pour éclaircir le problème j'ai créé un petit projet avec 2 StringGrid, une triée par AnsiCompareText ( ce qui semble être la fonction utilisée par défaut par le tri de colonne) et une triée par CompareStr.
voici le résultat :
Sous windows 10 Lazarus 1.8.2 :
Pièce jointe 383825
Comme on peut le constater, le résultat est le même avec AnsiCompareText et avec Compare Str.
Sous Lubuntu 16.04 Lazarus 1.8.2 :
Pièce jointe 383826
On constate que le résultat n'est pas le même et on retrouve le tri que tu nous avais montré.
voici ce que j'utilise pour remplir les TStringrid :
et les procédures sur l'événément onCompareCells pour personnaliser le tri :Code:
1
2
3
4
5
6
7
8
9
10
11 procedure TForm1.FormCreate(Sender: TObject); var x: integer; begin For x:=0 to 11 do begin StringGrid1.Cells[1,(x*2)+1] := inttostr(x+1) + '.jpg'; StringGrid1.Cells[1,(x*2)+2] := inttostr(x+1) + 'a.jpg'; StringGrid2.Cells[1,(x*2)+1] := inttostr(x+1) + '.jpg'; StringGrid2.Cells[1,(x*2)+2] := inttostr(x+1) + 'a.jpg'; end; end;
Code:
1
2
3
4
5
6
7
8 procedure TForm1.StringGrid1CompareCells(Sender: TObject; ACol, ARow, BCol, BRow: Integer; var Result: integer); begin Result:=AnsiCompareText(TStringGrid(Sender).Cells[ACol,ARow], TStringGrid(Sender).Cells[BCol,BRow]); if TStringGrid(Sender).SortOrder=soDescending then result:=-result; end;
Edit : voici ce qu'a répondu engkin dans le forum principal de Lazarus :Code:
1
2
3
4
5
6
7
8 procedure TForm1.StringGrid2CompareCells(Sender: TObject; ACol, ARow, BCol, BRow: Integer; var Result: integer); begin Result:=CompareStr(TStringGrid(Sender).Cells[ACol,ARow], TStringGrid(Sender).Cells[BCol,BRow]); if TStringGrid(Sender).SortOrder=soDescending then result:=-result; end;
Ami calmant, J.PCitation:
AnsiCompareStr uses current locale collation:
Windows ANSI locale has numbers ordered before letters (1 10 1a)
Linux UTF8 locale orders letters before numbers (1 1a 10)
Windows collation charts
Unicode collation charts
Bonjour :D .
En même temps, si l'ordre numérique 1,2,3,... semble aller de soi, l'ordre alphabétique est arbitraire et résulte plus d'un consensus que d'une réelle logique. Il n'y a qu'à le comparer à d'autres alphabets comme le grec, par exemple, pour s'en convaincre.
Le problème pour moi réside plutôt, une fois que l'on a fait un choix, dans le fait de ne pas s'y tenir. Si, par exemple, je nomme 4 fichiers comme suit:
- '
- i
- l'ire
- lire
Ils sont classés dans le dossier de la manière suivante:
- '
- i
- lire
- l'ire
La logique n'est pas respectée.
Si l'apostrophe ' est considérée comme étant avant le i, le fichier l'ire devrait se trouver avant le fichier lire, du moins si le classement était réalisé de la même manière que dans nos dictionnaires. Quand le premier caractère ne suffit pas à discriminer, ici l, on prend le deuxième, ici ' et i, et si celui-ci suffit, ce qui est présentement le cas, on s'arrête là, quelques soient le nombre et le type de caractères qui suivent.
Quand je dis que la logique n'est pas respectée, je veux dire qu'une autre logique est appliquée. Est-ce qu'une des deux doit primer sur l'autre, voire une troisième? Je n'ai pas la réponse :aie: .
Amicalement,
naute.
J'avais oublié Linuxmint 18.3.Citation:
il semblerait que tu sois sous linux car sous windows on n'a pas le même résultat.
Ceux qui font du cross compiling vont avoir des surprises non ?Citation:
On constate que le résultat n'est pas le même et on retrouve le tri que tu nous avais montré.
Pour 1a.jpg < 1.jpg je comprend que la présence de la lettre fasse remonter le nom mais si tu regarde mon premier message tu verras que 10.jpg et 11.jpg sont plus petits que 1.jpg et je ne pense pas que ça aille de soi ?Citation:
En même temps, si l'ordre numérique 1,2,3,... semble aller de soi,
Ceci dit les réponses de jurassic pork vont me permettre de retravailler le problème, je marque en résolu mais je repasserai si je trouve d'autres trucs. Ce qui reste bizarre c'est que pour les DbGrids je n'ai jamais eu ce souci et il me semble que je ne l'ai pas non plus sur les stringslist. Je vais voir tout ça dès que j'aurai un moment.
Merci pour tout.