Captions non centrées dans ListView en mode Icon

**Jipété** · 27/11/2015, 19h30

Bonjour,

dans un projet d'explorateur, je trouve affreux cet alignement à gauche des Captions des Items, et n'ai trouvé aucune option permettant de régler ça.

Et gogol n'est d'aucun secours sur ce coup-là...

Quelqu'un aurait une idée ?
FPC 2.6.2 Laz 1.4.0
Merci,

**gvasseur58** · 28/11/2015, 19h26

Envoyé par Jipété

Bonjour,

dans un projet d'explorateur, je trouve affreux cet alignement à gauche des Captions des Items, et n'ai trouvé aucune option permettant de régler ça.

Et gogol n'est d'aucun secours sur ce coup-là...

Quelqu'un aurait une idée ?
FPC 2.6.2 Laz 1.4.0
Merci,

Bonjour,

Pour le dessin personnalisé, tu disposes de 3 gestionnaires d'événements : OnCustomDraw, OnCustomDrawItem et OnCustomDrawSubItem. C'est sans doute par ce biais-là que tu peux obtenir un dessin des éléments à ta convenance. En effet, la propriété IconOptions ne permet pas (je crois) de régler ton problème.

**Jipété** · 28/11/2015, 19h56

Salut, Gilles,

et merci pour ton retour.

Envoyé par gvasseur58

Pour le dessin personnalisé, tu disposes de 3 gestionnaires d'événements : OnCustomDraw, OnCustomDrawItem et OnCustomDrawSubItem. C'est sans doute par ce biais-là que tu peux obtenir un dessin des éléments à ta convenance. En effet, la propriété IconOptions ne permet pas (je crois) de régler ton problème.

J'espérais éviter de sortir l'artillerie lourde, mais en fait, je crois que je vais surtout hisser le drapeau blanc : j'ai demandé l'aide (

) sur OnCustomDrawItem, et tu sais ce qui s'affiche ? ça, et c'est tout :

TCustomListView.OnCustomDrawItem

OnCustomDrawItem - event handler for custom drawing an item

Declaration

Source position: comctrls.pp line 1536

protected property TCustomListView.OnCustomDrawItem : TLVCustomDrawItemEvent
read FOnCustomDrawItem
write FOnCustomDrawItem;

Alors, indépendamment du fait que ça aura été la misère pour copier/coller ces 7 lignes (il m'a fallu faire en deux temps : d'abord copier/coller les 4 premières car impossible de sélectionner les 3 dernières, et recopier à la main les 3 autres

), tu comprends bien qu'avoir une aide comme ça ou rien, c'est à peu près pareil...

Bon, de toute façon, je vais laisser tomber car le projet devait s'appuyer sur un TProcess pour "monter" (avec vdfuse) des fichiers de machines virtuelles (.vhd, .vdi) et ça, autant j'y arrive tip-top avec un script Bash, autant c'est totalement impossible avec un TProcess qui se bloque, bloque l'IHM, bloque aussi une console terminal lancée indépendamment du projet, obligé de décoincer le bazar à partir d'une autre session non graphique (en passant par Ctrl-Alt-Fx), jamais vu ça...

Et pourtant, j'avais bien suivi les recommandations de http://wiki.lazarus.freepascal.org/E...ernal_Programs, j'avais testé avec des commandes simples, mais là je suis face à un mur infranchissable.
J'abandonne tout ce projet, pour le moment.
Je reverrai ça avec la 2.0 ou 3.0, quand l'aide sera une vraie aide...

Bye et merci,

**Jipété** · 30/11/2015, 20h30

Envoyé par Jipété

Bon, de toute façon, je vais laisser tomber car le projet devait s'appuyer sur un TProcess pour "monter" (avec vdfuse) des fichiers de machines virtuelles (.vhd, .vdi) et ça, autant j'y arrive tip-top avec un script Bash, autant c'est totalement impossible avec un TProcess qui se bloque, bloque l'IHM, bloque aussi une console terminal lancée indépendamment du projet, obligé de décoincer le bazar à partir d'une autre session non graphique (en passant par Ctrl-Alt-Fx), jamais vu ça...

J'ai une vague piste concernant l'utilisation de FUSE sous linux, qui pourrait être le coupable, ou tout du moins la manière dont ce système est appelé par l'applicatif de "montage", le vdfuse. J'ai trouvé des liens à étudier, j'ai des tests à réaliser, je vais faire un peu de C, tiens, ça va me changer du Pascal

**Jipété** · 05/03/2018, 09h20

Tout vient à point à qui sait attendre, dit le proverbe.

Et moi je rajoute : respect !

Ça, c'est d'la soluce, bien joué, amigo !

Pas le temps de tester aujourd'hui, mais dans la semaine je pense...

Grand

par avance

**Jipété** · 06/03/2018, 19h45

Envoyé par Jipété

Pas le temps de tester aujourd'hui, mais dans la semaine je pense...

Ça me démangeait...

Et donc :

Perfecto dans ma vieille 1.4, dès que j'ai 5 minutes (mettons 1 heure

) je m'attaque à la 1.8, mais ça n'est pas pressé, j'ai autre chose sur le gaz.

Je ne sais pas comment te dire

plus fort que comme ça

Je vais pouvoir réanimer mon vieux projet, encore bravo à toi

Et je coche

! Elle est pas belle la vie ?

**Jipété** · 07/12/2015, 00h32

Bonsoir,

Envoyé par Jipété

[...] mais là je suis face à un mur infranchissable.

Il m'aura fallu 9 jours mais le mur a été enfin franchi : ce fut un combat laborieux avec de grosses gouttes de sueur, des tests à n'en plus finir avec TProcess, TAsyncProcess et des bidouillages dans des programmes en C capricieux au niveau du pilotage de leurs sorties (le fameux "printf"), et ce matin, en suivant un lien, enfin la lumière !
Quelqu'un s'est décarcassé et a réussi à récupérer la sortie de programmes divers et variés : qu'ils envoient tout d'un coup et se terminent ou qu'ils envoient petit à petit, je peux enfin tout récupérer.

Et du coup, retour au post d'origine, à ces histoires de centrage de caption à coups de CustomDrawItem et, ma foi, on dirait que ça le fait :

Le code :

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
const
  MARGE = 17;
  AJUST = 2;
 
procedure TForm1.lvCustomDrawItem(Sender: TCustomListView; Item: TListItem;
  State: TCustomDrawState; var DefaultDraw: Boolean);
var // http://comments.gmane.org/gmane.comp.ide.lazarus.general/77322
   rct: TRect;
   hcap,lcap: integer;
begin
   DefaultDraw:=False;
   {if (cdsSelected in State) then begin
     Sender.Canvas.Font.Style:=[fsBold];
     Sender.Canvas.Font.Color:=clGreen;
   end
   else} begin
     Sender.Canvas.Font.Style:=[];
     Sender.Canvas.Font.Color:=clRed; // rouge juste pour vérifier que ça fonctionne
   end;
   rct := Item.DisplayRect(drLabel); //drSelectBounds, drBounds, drIcon c'est tout pareil
   //ligne dessous : pas trouvé l'utilité...
   //Sender.Canvas.FillRect(rct); //paint background with default brush colour
   hcap := Sender.Canvas.TextHeight(Item.Caption);
   lcap := Sender.Canvas.TextWidth (Item.Caption);
   case rdg.ItemIndex of
     0,1:
       Sender.Canvas.TextOut(((rct.Right-rct.Left-lcap)div 2)+rct.Left,
       rct.Bottom-hcap+MARGE, Item.Caption);
     2:
       Sender.Canvas.TextOut(rct.Left+AJUST, rct.Top-AJUST, Item.Caption);
   end;
end;

Ne cherchez pas dans l'aide de Lazarus, il n'y a, comme d'habitude, rien, enfin, rien d'utilisable...

Allez, je vais cliquer sur

Il reste quand même un dernier problème (sinon ça ne serait pas marrant) : dès que le dossier à afficher contient quelques objets (une vingtaine de dossiers et fichiers), ça devient épouvantablement long : compter une dizaine de secondes pour passer de l'affichage "icônes" à l'affichage "petites icônes", par exemple.
Et c'est bien ce CustomDrawItem qui met la pagaille : si je commente ce code, l'affichage est instantané.

Donc en gros c'est fonctionnellement résolu mais totalement inutilisable en production...

**Jipété** · 07/12/2015, 20h35

Envoyé par Jipété

Et c'est bien ce CustomDrawItem qui met la pagaille : si je commente ce code, l'affichage est instantané.

Donc en gros c'est fonctionnellement résolu mais totalement inutilisable en production...

Le problème est dans cet appel à DisplayRect :

Code :

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

   rct := Item.DisplayRect(drLabel);

Si je commente cette ligne, l'affichage est instantané mais je n'ai pas de texte écrit sous les icônes, si je la remets en service 10 à 15 secondes sont nécessaires pour afficher une vue de 22 icônes...

Et également 10 à 15 secondes pour fermer le programme en cliquant bêtement sur la croix...

J'enlève

, je considère que ça ne peut pas fonctionner comme ça.

**Jipété** · 07/03/2018, 00h35

Bonsoir,

je n'avais pas vu que tu avais posté un zip avec les deux fichiers, j'ai donc fait à l'ancienne, au bloc-notes entre les fichiers d'origine et tes corrections indiquées dans le post.

Ce soir je ne sais pas ce qui m'a pris, mais j'ai voulu comparer mon fichier modifié et celui que tu fournis dans le zip (je parle de gtk2cellrenderer.pas, pas eu le temps de comparer l'autre), et je note une différence dans la fonction LCLIntfCellRenderer_GetType_Center: TGtkType; :

Extrait du code posté :

Code :

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

1
2
3
    class_size: SizeOf(TLCLIntfCellRendererClass)+100;
    class_init_func: @LCLIntfCellRenderer_ClassInitCenter;
    object_init_func : @LCLIntfCellRendererCenter_Init;

Extrait du zip :

Code :

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

1
2
3
    class_size: SizeOf(TLCLIntfCellRendererClass)+100;
    class_init_func: @LCLIntfCellRenderer_ClassInit; // <<<<<< manque "Center" !
    object_init_func : @LCLIntfCellRenderer_Init_Center;

Et la dernière ligne montre clairement que tu as modifié le nom de la fonction concernée : c'est bien, ça uniformise les noms, mais ça trouble pendant la comparaison,

EDIT :
1, je barre :
J'attends de tes nouvelles pour savoir dans quelle direction je vais car si la modification du nom de la fonction d'init de l'objet n'est pas perturbante, l'appel de la mauvaise fonction pour l'init de la class me déstabilise !

2, je précise :
j'ai écrit "manque Center" car il y a une proc appelée LCLIntfCellRenderer_ClassInitCenter dans le code posté mais en fait, il n'y en a pas besoin (d'où son absence dans le zip), donc ma remarque est inutile.
(Pas facile à voir avec le bloc-note, ce genre de différences...)

Tout va bien : il suffit de remplacer les fichiers (après renommage de ceux qui vont devenir les "anciens au cas où") et hop !

**Jipété** · 08/12/2015, 19h36

Bonsoir,

j'ai préparé un petit zip contenant juste ce qu'il faut (une form avec une ListView, un RadioGroup pour choisir le ViewStyle, et 2 ImageLists, c'est tout) pour montrer le problème, si une (ou plusieurs) âme(s) charitable(s) voulai(en)t bien y jeter un œil, histoire de voir si ce souci est reproductible dans d'autres environnements que le mien (Linux Debian 32 bits sous Gtk2), ça serait vraiment cool.

J'ai mis également deux dossiers de test dans le zip :
- un nommé "ab" (histoire qu'il soit au début de l'arborescence quand je teste avec le Treeview et tout le toutim) ne contenant que 4 fichiers (et déjà je note un peu de lag à l'affichage) ;
- un autre nommé "content4filexplorer" qui contient 22 fichiers et dossiers et pour lequel c'est donc la grande misère : en moyenne 13 secondes pour lancer le prog., 13 secondes pour le fermer, 13 secondes pour réafficher la fenêtre si elle a été masquée, c'est infernal et invivable.

Les testeurs auront une seule chose à paramétrer, dans le FormCreate, en fonction de leur environnement :

Code :

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

1
2
  ShowDirectory('/ab'); // 4 fichiers
//  ShowDirectory('/content4filexplorer'); // 22 fichiers

Un dernier mot : ce lag épouvantable ne se manifeste chez moi que pour les affichages en mode "icônes" et "petites icônes" et pas du tout en mode "report". Allez comprendre...

J'espère qu'il n'y aura pas de cafouillages avec les retour-chariots, les fichiers texte venant du monde Linux, j'ai converti les fins de ligne pour le mode Windows avant de zipper.

Merci de vos retours,

pj : test4lag.zip

**Jipété** · 09/12/2015, 12h31

Yop !

Une autre adaptation à faire, découverte ce matin en testant dans un autre environnement, toujours sous Debian 32 bits mais sous Xfce :
dans la proc CustomDrawItem, adaptez comme suit :

Code :

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

1
2
3
4
5
    2: begin
      rct := Item.DisplayRect(drLabel);
//      c.TextOut(rct.Left+AJUST, rct.Top-AJUST, Item.Caption); // LXDE
      c.TextOut(rct.Left+16+AJUST*4, rct.Top+AJUST, Item.Caption); // XFCE
    end;

Est-ce que ça vient du fait que le Lazarus de cette machine n'est plus tout jeune (1.0.10, fpc 2.6.4) ? Je ne sais pas, mais je passe l'information.
Me demande comment ça va sortir sous Windows...

**ThWilliam** · 09/12/2015, 13h28

Salut JP,

Puisque tu te demandes comment ça va sortir sous Windows...

D'abord, sous Windows, il n'y a aucun problème d'affichage en mode icon quand on laisse le dessin par défaut : le texte est parfaitement centré.
Ce qui m'avait immédiatement frappé dans ton post du 6/12 : dans ta procedure OnDrawItem, avec DefaultDraw:= false --> l'icône ne devrait plus être dessinée !!!

J'ai testé ton zip sous Lazarus 1.4.4 et sous W7 :
Le programme se lance très vite, mais le ListView est continuellement redessiné (haute cadence de clignotement) , d'où impossibilité de fermer le programme !!!
Problème résolu en supprimant dans la procédure CustomDrawItem : lv.BeginUpdate et lv.EndUpdate.
Confirmation que avec DefaultDraw false, l'icône n'est pas dessinée.

Bon... je ne te suis pas d'un grand secours.

Cordialement
Thierry

**Jipété** · 09/12/2015, 15h29

Yop, Thierry,

et grand merci pour ton retour et tes tests, ça va me permettre d'avancer (dans le mur,

)

Envoyé par ThWilliam

D'abord, sous Windows, il n'y a aucun problème d'affichage en mode icon quand on laisse le dessin par défaut : le texte est parfaitement centré.

Et pourtant je n'ai pas inventé les copies d'écran postées dans le 1^er post (qui s'est pris un -1, j'aimerais bien savoir pourquoi : on ne doit plus poser des questions quand on a un problème, sur ce forum ?)
Il y a donc bien un souci avec Linux...

Envoyé par ThWilliam

Ce qui m'avait immédiatement frappé dans ton post du 6/12 : dans ta procedure OnDrawItem, avec DefaultDraw:= false --> l'icône ne devrait plus être dessinée !!!

Euh, d'après la doc trouvée chez Embarcadero, cette option concerne le texte, je la remets :

Set DefaultDraw to false if you don't want the control to paint the item's text after the event handler exits. If DefaultDraw remains true, the list view adds the item's text to the image on the canvas.

Et comme j'ai bien vu, dans des rapports de bugs ici et là, que le team Lazarus s'appuie sur les docs et comportements de Delphi, je considère que la doc d'Embarcadero est plus ou moins valide, en tout cas plus valide que celle, inexistante, de Lazarus (ce qui n'a pas l'air de plaire, mais y a que la vérité qui fâche, c'est bien connu

)

Envoyé par ThWilliam

Le programme se lance très vite, mais le ListView est continuellement redessiné (haute cadence de clignotement) , d'où impossibilité de fermer le programme !!!
Problème résolu en supprimant dans la procédure CustomDrawItem : lv.BeginUpdate et lv.EndUpdate.

J'avais rajouté ces choses dans l'espoir d'améliorer le défaut que je constate, on peut les supprimer, en effet.

Envoyé par ThWilliam

Confirmation que avec DefaultDraw false, l'icône n'est pas dessinée.

Voir plus haut, et, mystère... Car moi je confirme que j'ai le comportement "Embarcadero".

Envoyé par ThWilliam

Bon... je ne te suis pas d'un grand secours.

D'un grand secours pour mon affichage, non, mais au moins ça confirme que ce composant est loin d'être fini (suffit de regarder dans WSComCtrls.pp, il y a plein de procédures vides du côté des lignes 400 à 600, un exemple lignes 630-660 :

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
class function TWSCustomListView.GetVisibleRowCount(const ALV: TCustomListView): Integer;
begin
  Result := 0; // oui, là il y a du code, mais dessous ????????
end;
 
class procedure TWSCustomListView.SetAllocBy(const ALV: TCustomListView; const AValue: Integer);
begin
end;
 
class procedure TWSCustomListView.SetDefaultItemHeight(const ALV: TCustomListView; const AValue: Integer);
begin
end;
 
class procedure TWSCustomListView.SetHotTrackStyles(const ALV: TCustomListView; const AValue: TListHotTrackStyles);
begin
end;
 
class procedure TWSCustomListView.SetHoverTime(const ALV: TCustomListView; const AValue: Integer);
begin
end;
 
class procedure TWSCustomListView.SetIconArrangement(
  const ALV: TCustomListView; const AValue: TIconArrangement);
begin
end;
 
class procedure TWSCustomListView.SetImageList(const ALV: TCustomListView; const AList: TListViewImageList; const AValue: TCustomImageList);
begin
end;

c'est peut-être normal ? Je ne sais pas...)

J'envisage de m'orienter vers une TListBox ou une TStringGrid, je sais pas trop encore...

Attendons d'autres retours...

Ah, pendant que j'y suis : j'ai essayé de jouer avec TTextStyle (il en reste une trace dans le zip) mais je ne suis arrivé à rien là aussi, notamment l'option qui permet d'avoir un nom de fichier long réparti sur plusieurs lignes (chose qui fonctionne dans l'explorateur natif de mon système) : ça ne fonctionne pas, tout reste sur une seule ligne, résultat des zones qui s'agrandissent en fonction du nom de fichier le plus long, inutile de vous dire à quoi ça ressemble quand le texte est aligné à gauche...

Encore merci à toi,

**Jipété** · 21/12/2015, 21h34

Bonsoir,

histoire d'essayer d'avancer un peu et voulant profiter de cette récente 1.6rc1, j'ai monté vite fait une machine virtuelle XP sp2 dans laquelle j'ai donc téléchargé puis installé cette 1.6rc1 en mode "newbie", c'est-à-dire "suivant suivant suivant" et voilà, ça roule.

Sans aucune ligne de code (suppression complète de l'événement OnCustomDrawItem) les icônes s'affichent parfaitement bien ; j'en conclus que Linux est le parent pauvre, merci pour les pingouins...

**Jipété** · 22/12/2015, 13h03

Salut,

C'est bien les machines virtuelles, ça permet d'avoir un seul dossier contenant le code (dans un dossier partagé commun à toutes mes machines virtuelles), dossier qui sera attaqué par une machine sous XP sp2 et par une autre machine sous Linux Debian Wheezy, ces deux machines exécutant le tout nouveau tout beau Lazarus 1.6rc1.

L'astuce consiste à ne lancer qu'un IDE à la fois pour éviter les embrouilles et au final je me retrouve avec l'exécutable Windows prog.exe et le binaire Linux prog.

Et comme on est dans cette histoire de captions non centrées, je précise bien que tout code gérant l'affichage dans la Listview a été supprimé ; il ne subsiste que le choix de son mode d'affichage (Icon, Report, etc.) :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
procedure TForm1.rdgSelectionChanged(Sender: TObject);
begin
  case rdg.ItemIndex of
    0: lv.ViewStyle:=vsIcon;
    1: lv.ViewStyle:=vsSmallIcon;
    2: lv.ViewStyle:=vsReport;
  end;
  // dessus = moi, dessous = vient des exemples Lazarus (listview)
  // mais fait disparaitre ColumnHeaders !? :-(
  //lv.ViewStyle := TViewStyle(rdg.ItemIndex);
end;

Et au final une image permettant de comparer les résultats, à gauche dans Linux et à droite dans Windows :

De cette image je ne dirai qu'une chose :
Write Once Compile Anywhere = euh, y a encore du chemin...

**gvasseur58** · 30/12/2015, 17h50

Envoyé par Jipété

De cette image je ne dirai qu'une chose :
Write Once Compile Anywhere = euh, y a encore du chemin...

Il y a encore du travail : c'est certain

Je découvre bien tard cette discussion, mais je me permets de renvoyer à l'état d'avancement du compilateur et de ses bibliothèques : Listview est explicitement présenté comme en cours de développement (partially implemented) pour gtk2...

Suivre ce lien : ici

**Jipété** · 31/12/2015, 01h18

Bonsoir, Gilles, et merci pour ton retour, et pour cette information :

Envoyé par gvasseur58

Il y a encore du travail : c'est certain

Je découvre bien tard cette discussion, mais je me permets de renvoyer à l'état d'avancement du compilateur et de ses bibliothèques : Listview est explicitement présenté comme en cours de développement (partially implemented) pour gtk2...

Suivre ce lien : ici

Alors je crois que les gens qui développent l'ide devraient absolument mettre un flag quelque part, genre tu double-cliques sur l'icône d'un compo ou tu le drag-n'-drop sur la form et un ShowMessage informe le user que ceci que cela, ou dans l'inspecteur de propriétés mais en gros, que ça se voie !, que l'utilisateur sache où il met les mains.
Ou alors une icône barrée avec un code couleur indiquant le degré de disponibilité, enfin, tu vois ce que je veux dire : ça m'aurait évité de perdre un temps dément sur cette affaire.

Ah, en plus il manque une info dans ton tableau : il n'y a rien entre "working" et "partially implemented" ; j'aurais bien aimé voir un "work in progress", parce que là, je ne sais pas du tout ce qu'il faut que je fasse avec mon projet planté...
Ou alors je bascule sur Qt ou je régresse vers gtk puisque là c'est "working".

Bon, ben c'était la dernière mauvaise nouvelle de cette année, m3rd1que à souhait, vivement la prochaine, ça ne pourra qu'aller mieux.