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

[Invité]

Bonjour Chris37,

Merci pour votre réponse...

Alors quel est le problème dans le code que j'ai fourni ?

Vous posez 2 StringGrids par défaut sur la Form . Vous remplissez par programmation les Columns.title.caption et les Cells de la même façon dans les 2 StringGrids et dans la 2ème vous rendez une colonne invisible.

Puis vous comparez l'affichage. C'est un bon début. Chez moi en 0.9.26.2 : il n'est pas cohérent ! Rien que cela !

Pour le reste de votre réponse, c'est caractéristique de ce que je lis régulièrement.

A. "Je n'ai pas de problème"

• moi si ! je fournis le code et les résultats produits. Donc 2 solutions : où le code est faux, ou il ne l'est pas. S'il ne l'est pas, comment le problème peut-il être contourné ? Qu'est-ce que cela implique dans les autres traitements de l'objet. Est-ce généralisable et portable sur les autres objets identiques du projet ? Combien cela consommera-t-il de ressources notamment de temps ? Finalement, la solution est-elle techniquement et économiquement acceptable ?
• Le code fonctionne peut-être parce que vous utilisez la dernière 0.9.27.svn, celle que vous avez téléchargée ce matin pour remplacer celle d'hier qui elle-même remplaçait... Je ne programme pas en production avec des versions svn. C'est suicidaire !... et impossible (au niveau des OS, elles ne sont pas synchronisées) : il faudrait vérifier le fonctionnement de l'ensemble du projet à chaque fois, sachant que le code fonctionnant sous la version stable arrive à poser problème sur les versions svn.
  Donc, chez vous, les StringGrids fonctionnent disons "acceptablement" ?

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
procedure TForm1.FormCreate(Sender: TObject);
var
i : integer;
StringGridX : TStringGrid;
begin
StringGridX := TStringGrid.Create(self);
 
//Création des colonnes
StringGrid1.ColCount := 5;
StringGrid1.FixedCols := 1;
//Création des lignes
StringGrid1.RowCount  := 5;
StringGrid1.FixedRows := 1;
//Titre de certaines colonnes
for i := 2 to 3 do
 StringGridX.Columns[i].Title.Caption := 'Col' + IntToStr(i);
 
StringGridX.Free;
 
end;

Essayez cela ! --> Project raised exception classe EListError with message : List index (2) out of bounds [Le 2 correspond à for i:=2...]

Bug connu depuis longtemps que l'on sait contourner: Il nécessite de déclarer d'abord ColCount:=0; et d'utiliser Columns.add pour créer des colonnes... Et le contournement présente lui-même des bugs. Regardez les commentaires placés sur les Columns.add dans mon code fourni au départ de cette discussion. La déclaration et le positionnement des Columns.add n'obéit à aucune logique autre que le bricolage... Et vous n'avez pas de problème avec les StringGrids ? Je n'arrive pas à atteindre votre niveau de tolérance et d'adaptation. Cela doit expliquer finalement la différence de notre évaluation du composant Lazarus.StringGrid.

Evidemment, je peux imaginer une solution, on peut toujours imaginer ! En plaçant les champs visibles dans une StringGrid (et l'ID des lignes dans la Col gsFixed dont l'écriture aura la même couleur que le fond) puis en l'associant à un StringGrid.visible:=false; dans lequel on place les champs invisibles qui auraient dû figurer dans la première... et évidemment en faisant un "petit" effort de synchronisation... Pour moi, à ce niveau de "compensation", cela devient n'importe quoi. Un programmeur n'est pas sensé faire n'importe quoi pour arriver à ses fins, ici gérer une StringGrid moderne [Tris sur plusieurs index (colonnes) en même temps, sélections multilignes non contiguës, champs de recherche associés au Header, redimensionnement des colonnes, ...]. D'autant que sur le papier Lazarus permet de réaliser cela très facilement, plus facilement d'ailleurs que je n'aurai pu le faire en Delphi 7 (notamment les tris). Le problème c'est qu'à force de contourner des contournements de contournements, ce n'est plus de la programmation utilisable en production.

B. La faiblesse d'un composant
"Il" est bénévole, "il" est seul, "il" n'a pas de temps. C'est une mauvaise excuse, cela frise maintenant la complainte. Soit Lazarus a l'ambition de devenir une plateforme de développement performante, soit cela reste un produit "universitaire" développé par (et pour) quelques "initiés". Pour les composants natifs de connexions aux BDD et la chaîne "avale", à contre-courant (cela coule de source... avec aval), j'ai produit un CR après tentative d'utilisation. (http://www.developpez.net/forums/d69...r-dexperience/). J'ai même commencé à modifier certains d'entre eux et j'ai voulu prendre contact avec l'équipe de développement. Je crois même que j'ai fait appel au forum pour avoir des contacts. Impossible : le seul outil, c'est le bugtracker. Vu le nombre de problèmes rencontrés, c'est une plaisanterie. Alors, on ne peut pas dire, je suis tout seul et cela explique les manques du composant ou ses faiblesses et d'un autre côté avoir un comportement que j'explique mal et que j'interprête comme des réflexes défensifs de préservation du code. Soit c'est un produit ouvert, soit il ne l'est pas. Alors évidemment, chacun peut le modifier à sa manière dans son coin. Mais à chaque release "officielle", il faut réinjecter dans le nouvel IDE ses propres modifications. Cela devient injouable.

Bon j'arrête là, je vais passer mon week-end à ré-écrire mon code sur une autre plateforme. Ce qui me mécontente toujours autant... même après une bonne nuit de repos (http://www.developpez.net/forums/d74...professionnel/).

Cordialement. Gilles

[chris37]

Bonjour,

Je comprend ton mécontentement surtout si tu fais de la production avec une version BETA car n'oublions pas que même la version 0.9.26 est une version BETA. Il suffit de parcourir les taches restante pour aboutir à la V1 pour comprendre certains soucis rencontrés. Des bug sont corrigés ou ne pourront l'être qu'après d'autre corrections. Mais bon c'est çà le libre

Quand tu dis :

Mais à chaque release "officielle", il faut réinjecter dans le nouvel IDE ses propres modifications. Cela devient injouable.

Il faut fournir des patch pour qu'il soient intégrés directement à la prochaine release.

Je suis en congé mais des mon retour en septembre, je verrais à reprendre la gestion du Wiki et fournir plus de doc et d'aide... car les écrivains sont rares ces temps ci

Bon dimanche sous ce soleil magnifique

Cordialement,
Chris