Discussion :

[Invité]

Bonjour,

j'ai posé 2 questions dans le bug tracker mais une d'entre elles a été effacée. Ce n'était peut-être pas le lieu ou alors elle était idiote. Quelqu'un va certainement pouvoir m'expliquer...

StringGrid "commune" avec 2 colonnes construites avec l'inspecteur d'objet
Je pose une StringGrid sur une Form puis définis 2 colonnes à l'aide des propriétés de l'inspecteur d'objet : Propriétés --> Clic sur "Columns" puis bouton [...].
2 colonnes sont ainsi créées : 0-title et 1-title.
Ceci fait dans l'inspecteur d'objet de la StringGrid, dans les propriétés

• Columns indique automatiquement : 2 items
• Colcount indique automatiquement : 3
• VisibleColcount indique automatiquement : 3

L'écart Columns/Colcount est logique paraît-il car par défaut les Cells[0,y] sont gsfixed... Donc le colcount serait en quelque sorte le nombre de colonnes "actives". Hormis un décalage que j'estime hasardeux et compliquant inutilement la programmation, pourquoi pas ? Là n'est pas le problème même si je trouve le concept malhabile.
Dans cette configuration de la Grid, il existe bien 3 colonnes que l'on peut "atteindre" par programmation :

• les Cells[0,y] inatteignables (donc) par Columns[x] (puisqu'ici gsFixed)
• les Cells[1,y] qui correspondent à Columns[0]
• les Cells[2,y] qui correspondent à Columns[1]

Même StringGrid avec une colonne déclarée invisible
Maintenant, je retourne dans l'inspecteur de colonnes, je clique sur 0-title par exemple et place la propriété visible de la colonne à false.
Elle existe toujours bien dans l'éditeur de colonnes [dans propriété on lit toujours Columns : 2 items] mais le Colcount de la StringGrid indique 2 (au lieu de 3 avant) et en effet un Cells[2,y] provoque une erreur.

En résumé dans l'inspecteur d'objet de la StringGrid avec une Columns[x].visible = false, dans les propriétés

• Columns indique automatiquement : 2 items
• Colcount indique automatiquement : 2
• VisibleColcount indique automatiquement : 1

Ce qui correspond au fonctionnement par programmation suivant

• les Cells[0,y] inatteignables par Columns[x]
• les Cells[1,y] qui correspondent à Columns[0]
• les Cells[2,y] qui provoquent une erreur out of range cell...

Question
Alors la question posée est la suivante : à quoi sert la propriété visible des colonnes si en réalité lorsqu'on la met à false, la columns[x] présente dans l'éditeur de colonnes de la stringGrid ipso facto n'existe plus pour la programmation puisque Columns[x] et Cells[x+1,y] povoquent l'erreur (out of range cell...) ?


Merci de m'éclairer.

Cordialement. Gilles

[theodp]

j'ai posé 2 questions dans le bug tracker mais une d'entre elles a été effacée.

It was not deleted but closed ;-)
http://bugs.freepascal.org/view.php?id=14316

[Invité]

OK, mais ce n'est guère mieux. Je dois avouer que j'utilise peu le bug tracker. En contournant le bug (par Columns.add; bug reconnu depuis pas mal de temps mais non corrigé...), on en obtient un autre :

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
49
50
51
52
53
54
55
56
57
58
var
 i,j : integer;
begin
StringGrid1.ColCount := 0;
//Création de la Col gsFixed
StringGrid1.Columns.add;   //<-- Obligatoire sinon Erreur lors ligne suivante 
StringGrid1.FixedCols := 1;
//Création des lignes
StringGrid1.RowCount  := 5; //5 lignes dont une gsFixed
StringGrid1.FixedRows := 1;
 
//Création des colonnes "actives"
 
StringGrid1.Columns.add;  //<-- Pourquoi 3 add alors que je crée 4 colonnes ?
StringGrid1.Columns.add;
StringGrid1.Columns.add;
//StringGrid1.Columns.add; --> Crée une colonne supplémentaire inutile ?!
 
//Titre des colonnes
for i := 0 to 3 do
 StringGrid1.Columns[i].Title.Caption := 'Col' + IntToStr(i);
 
//Remplissage des cellules
for i := 0 to 4 do
 for j := 1 to 4 do
  StringGrid1.Cells[i,j] := 'Cells[' + IntToStr(i) + ',' + IntToStr(j)+']';
 
StringGrid2.ColCount  := 0;
//Création de la Col gsFixed
StringGrid2.Columns.add;
StringGrid2.FixedCols := 1;
//Création des lignes
StringGrid2.RowCount  := 5; //5 lignes dont une gsFixed
StringGrid2.FixedRows := 1;
 
//Création des colonnes "actives"
 
StringGrid2.Columns.add;
StringGrid2.Columns.add;
StringGrid2.Columns.add;
//StringGrid2.Columns.add;
 
//Titre des colonnes
for i := 0 to 3 do
 StringGrid2.Columns[i].Title.Caption := 'Col' + IntToStr(i);
 
//Remplissage des cellules
for i := 0 to 4 do
 for j := 1 to 4 do
  StringGrid2.Cells[i,j] := 'Cells[' + IntToStr(i) + ',' + InTtoStr(j)+ ']';
 
//Rendre Columns[2] invisible
StringGrid2.Columns[2].Visible := false;
 
//Edition sur la colonne invisible
Showmessage('StringGrid2:' + StringGrid2.Columns[2].Title.Caption + #10 +
                           StringGrid2.Cols[2-1].Text); !!! OK
end;

Et voici le résultat :


Alors, la colonne est bien invisible : On récupère bien les Columns[2].informations...
mais
pas les cells[2-1,y] où les les Cols[2-1].Text. [Le -1 est nécessaire (voir 1er message)]...
Et pour preuve l'affichage de la columns[3] dans la StringGrid2 (la colonne après celle déclarée invisible) et ses cells[] qui sont désynchronisées (sans utiliser de -1). C'est la simple ligne StringGrid2.Columns[2].visible := false; qui produit "automatiquement" ce résultat. Cela est-il exploitable en programmation courante ?

Vraiment, les StringGrids à la mode Lazarus me dépriment : cela signifie en clair que l'on ne peut pas stocker des données dans des colonnes cachées sauf à les mettre à colsWidth[x]:=0; ce qui pose des problèmes d'ergonomie quand on veut utiliser des colonnes redimensionnables ce qui est quand même assez usuel actuellement !

J'en reviens à ma critique [et d'ailleurs l'une des réponses fournies au premier bug que j'ai déclaré "Réglé dans 0.9.27 svn - qui je crois n'est pas installable facilement sur ma debian (ie sans passer par les rpm)] : avant de passer à la 0.9.28 stable préparée par la 0.9.27 qui ne sera jamais déclarée stable (comme la 0.9.25), il serait peut-être utilse de stabiliser la 0.9.26 déclarée stable pour des objets aussi usuels qu'une StringGrid. Quand au svn, s'il est massivement pour windows et laisse à la traine Linux et Mac (comme j'ai pu le constater), autant passer en Delphi (tant qu'il existe). Sur ce, il faut que je refasse mon prog dans un autre langage. Rageant !

Je me suis permis de répondre à la discussion "Lazarus est-il adapté au développement professionnel ?" que je l'utilisais souvent comme tel. Mais c'est le deuxième projet qui échoue techniquement à cause de bugs quasi incontournables ou contournables en sacrifiant l'ergonomie de manière incompatible avec des logiciels modernes. La base du produit n'est pas en cause, mais il faut absolument stabiliser les versions dites stables avant de continuer cette course (cette fuite) en avant. Sinon, même si je suis un Pascalien dans l'âme, Lazarus n'a pas d'avenir professionnel. Sale temps pour les Pascaliens, déjà Delphi Prism... bientôt Lazarus...
Cordialement. Gilles

[theodp]

Jesus Reyes said here http://bugs.freepascal.org/view.php?id=14316
use Columns[2].width:=0 instead of Columns[2].visible:=false. Makes sense imho.

[Invité]

Non désolé theodp, ce n'est pas du tout équivalent. C'est encore un contournement qui génère d'autres problèmes (évoqués ci-dessus et dans une discusion précédente).
http://www.developpez.net/forums/d79...ontal-colonne/

Une colonne à Width:=0 pour être invisible, doit le rester même (et surtout) si les colonnes "visibles" sont redimensionnables comme dans la plupart des logiciels actuels.

Merci pour votre aide.

Cordialement. Gilles

[chris37]

Bonsoir,

Gilles, je ne comprend pas ton soucis avec ta StringGrid car j'utilise la
propriété visible sans aucun soucis. La façons de démarrer le comptage est également logique...

L'interprétation des colonnes est plus pratique que dans certains logiciels dits évolués dans le sens ou l'on a accès à toutes les possibilités. restes bien sur quelques coquilles mais franchement, rien de gênant. On est programmeur ou pas.

Je ne relance pas un vieux débat mais chacun est libre de donner de son temps pour Lazarus, de créer des patch, de rédiger la doc et de créer des tutos (J'ai fais ma part au passage). Le wiki n'évolue plus et c'est dommage...peut être devrais-je fermer le site au final puisque prendre est plus facile que donner

Concernant LazReport, Jesus Reyes fais de sont mieux de la ou il est (L'autre bout de l'océan pour nous) et supporte presque tout seul ce composant. Il a donc moins de temps pour travailler sur les grid. J'ai échangé avec lui pour certaines améliorations mais faute de temps (le sien), c'est en stand by.

...
La nuit porte conseil