Captions non centrées dans ListView en mode Icon

Version imprimable

27/11/2015, 18h30
Jipété

2 pièce(s) jointe(s)

Captions non centrées dans ListView en mode Icon

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à... :weird:

Pièce jointe 193758

Pièce jointe 193759

Quelqu'un aurait une idée ?
FPC 2.6.2 Laz 1.4.0
Merci,
28/11/2015, 18h26
gvasseur58

Citation:

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à... :weird:

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.
28/11/2015, 18h56
Jipété

Salut, Gilles,

et merci pour ton retour.

Citation:

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 (:aie:) sur OnCustomDrawItem, et tu sais ce qui s'affiche ? ça, et c'est tout :

Citation:

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 :weird:), tu comprends bien qu'avoir une aide comme ça ou rien, c'est à peu près pareil... :vomi:

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... :calim2:
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,
30/11/2015, 19h30
Jipété

Citation:

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... :calim2:

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 8-)
:coucou:

1 pièce(s) jointe(s)

Bonsoir,

Citation:

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.
:yaisse:

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 :

Pièce jointe 194525

Le code :
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 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 :resolu: :ccool:

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...

07/12/2015, 19h35
Jipété

Citation:

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:

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... :weird:

J'enlève :resolu:, je considère que ça ne peut pas fonctionner comme ça.
08/12/2015, 18h36
Jipété

1 pièce(s) jointe(s)
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:

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 : Pièce jointe 194768

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:

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...

09/12/2015, 12h28
ThWilliam

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

1 pièce(s) jointe(s)

Yop, Thierry,

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

Citation:

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...

Citation:

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 :

Citation:

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 :mrgreen:)

Citation:

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.

Citation:

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".

Citation:

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:

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...
Pièce jointe 194821

Encore merci à toi,

21/12/2015, 20h34
Jipété

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... :calim2:

1 pièce(s) jointe(s)

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:

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 :

Pièce jointe 196039

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

30/12/2015, 16h50
gvasseur58

Citation:

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 :mouarf:
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
31/12/2015, 00h18
Jipété

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

Citation:

Envoyé par gvasseur58

Il y a encore du travail : c'est certain :mouarf:
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.
31/12/2015, 12h45
gvasseur58

Citation:

Envoyé par Jipété

Ou alors je bascule sur Qt ou je régresse vers gtk puisque là c'est "working".

Surtout pas :aie:
C'est "working", mais en voie d'abandon :weird:
L'année 2016 sera meilleure ;)
04/01/2016, 19h12
Jipété

1 pièce(s) jointe(s)

Citation:

Envoyé par gvasseur58

L'année 2016 sera meilleure ;)

Les pauvres, ils ont du boulot ! Tiens, regarde :

Quand je lance mon programme de test (et là je suis sous Windows !) le bazar est configuré pour s'afficher en mode "Liste détaillée"

- tant que je joue entre "Liste détaillée" et "Petites icônes" je vais avoir l'affichage du haut (pas mis le mode "Liste détaillée pour ne pas alourdir)
- et si je passe par "Icônes" puis retour à "Petites icônes" vous constatez le changement d'affichage en bas...

Pièce jointe 197011

La ListView est vraiment le parent pauvre...

Bonjour,

Tout d'abord désolé pour ce déterrage de topic (:aie:), mais je pense avoir trouvé quelque chose d'assez intéressant.

Tout d'abord l'implémentation réelle de la TCustomListView est TGtk2WSCustomListView, qui se trouve dans lcl/interfaces/gtk2/gtk2wscustomlistview.inc (et non dans WSComCtrls.pp qui ne contient que les implémentation de la classe parent de TGtk2WSCustomListView, TWSCustomListView). En analysant le code, on se rend compte que le dessin du texte est pris en charge par un "textrenderer", créé par la fonction LCLIntfCellRenderer_New. Cette fonction ne fait que construire un GObject dérivé de GtkCellRendererText (voir lcl/interfaces/gtk2/gtk2/gtk2cellrenderer.pas pour la construction du type), qui a un attribut intéressant xalign, qui gère visiblement le centrage du texte.

Or GTK2 par défaut, positionne cette propriété xalign à 0 (tandis que GTK3 la positionne par défaut à 0.5, ce qui centre effectivement le texte), causant le problème d'alignement. Du coup, remplacer la fonction LCLIntfCellRenderer_Init (dans lcl/interfaces/gtk2/gtk2/gtk2cellrenderer.pas) par le code ci-dessous centre correctement le texte.
Code:

1 2 3 4 5 6 7 8 procedure LCLIntfCellRenderer_Init(Instance:PGTypeInstance; Data:Pointer); cdecl; var CellRenderer: PGtkCellRenderer; begin CellRenderer := GTK_CELL_RENDERER(Pointer(Instance)); CellRenderer^.xalign := 0.5; end;
Le seul problème c'est que toutes les ListBox/ComboBox (qui utilisent également le CellRenderer créé par LCLIntfCellRenderer_Init) ont leur texte centré par contre avec cette modification :aie:.

Salut,

Citation:

Envoyé par supersnail

Tout d'abord désolé pour ce déterrage de topic (:aie:), mais je pense avoir trouvé quelque chose d'assez intéressant.

Y a pas de souci, tout ce qui permet de faire avancer le schmilblik est bon à prendre.

Le seul problème, c'est que tu ne nous as pas donné tes versions de FPC et Lazarus, car par exemple, avec mes vieux coucous tout ce que tu exposes ne mène à rien chez moi (pas de xalign) :
Code:

1 2 3 4 5 6 7 procedure LCLIntfCellRenderer_Init({%H-}Instance:PGTypeInstance; {%H-}theClass: Pointer); cdecl; // Instance: PLCLIntfCellRenderer; // theClass: PLCLIntfCellRendererClass begin //DebugLn(['LCLIntfCellRenderer_Init ']); end;
J'en conclus qu' "ils" ont dû un peu bosser la Listview, dès que la 1.8 définitive (car dans une 1.8rc1 qui traîne dans un coin, dézippée mais pas installée, c'est les mêmes lignes que ci-dessus) sort, je migre -- enfin, j'attends un petit mois, histoire d'attendre la sortie de patches, on ne sait jamais...

Citation:

Envoyé par supersnail

Le seul problème c'est que toutes les ListBox/ComboBox (qui utilisent également le CellRenderer créé par LCLIntfCellRenderer_Init) ont leur texte centré par contre avec cette modification :aie:.

On verra quand on y sera, un problème à la fois, ;)

Merci en tout cas :ccool:

09/09/2017, 08h37
supersnail

Bonjour,

Je crois que j'ai pas été compris en fait :aie:.

Il faut remplacer la procédure dont t'as montré le code par celle que j'ai posté (écrite par mes soins suite à mes investigations). Les développeurs semblent en effet avoir abandonné ce composant.

Sinon je tourne encore sur Lazarus 1.6.4 (et FPC 3.0.2) des dépôts Archlinux.
09/09/2017, 11h29
Jipété
Citation:

Envoyé par supersnail

Je crois que j'ai pas été compris en fait :aie:.

Ça m'apprendra à regarder du code le soir à pas d'heure, surtout après un après-midi fatigant !

Merci bien pour cette piste, it works ! :plusser:
Plus qu'à trouver comment splitter sur plusieurs lignes les chaînes très loooooooongues (ou utiliser "..." pour les raccourcir), surtout en n'ayant pas OwnerDraw à True.
EDIT :
Bon ben ça m'a l'air mort, si je regarde dans lcl/interfaces/gtk2/gtk2wscustomlistview.inc version 1.8rc1 la proc class procedure TGtk2WSCustomListView.SetPropertyInternal, je trouve :
Code:

1 2 3 lvpWrapText: begin // TODO: implement ??? end;
Et y en a plein d'autres dans cette proc, des propriétés avec le même code redoutable d'efficacité : // TODO: implement ???...

Citation:

Envoyé par supersnail

Les développeurs semblent en effet avoir abandonné ce composant.

Dramatique :cry:

Citation:

Envoyé par supersnail

Le seul problème c'est que toutes les ListBox/ComboBox (qui utilisent également le CellRenderer créé par LCLIntfCellRenderer_Init) ont leur texte centré par contre avec cette modification :aie:.

Mais comment ça se passe avec Gtk3 alors, si la valeur de xalign est fixée par défaut à 0,5 ?
09/09/2017, 12h44
supersnail

Il semblerait que oui effectivement (d'après le miroir GitHub de Gtk). Cependant les listBox ont leur propre implémentation sous Gtk3 au lieu de réutiliser Gtktreeview sous Gtk2, ce qui doit résoudre le problème du centrage je pense.

Salut,

je reviens 3 secondes là-dessus, un mois plus tard, car, oui, j'ai bien constaté le défaut du centrage dans ListBox, ComboBox, et c'est assez moche (et horripilant :mrgreen:)...
Citation:
Envoyé par supersnail
Code:

1 2 3 4 5 6 7 8 procedure LCLIntfCellRenderer_Init(Instance:PGTypeInstance; Data:Pointer); cdecl; var CellRenderer: PGtkCellRenderer; begin CellRenderer := GTK_CELL_RENDERER(Pointer(Instance)); CellRenderer^.xalign := 0.5; end;
Le seul problème c'est que toutes les ListBox/ComboBox (qui utilisent également le CellRenderer créé par LCLIntfCellRenderer_Init) ont leur texte centré par contre avec cette modification :aie:.
Alors plutôt que de supprimer ta proc et décommenter l'original, j'ai fait comme ça :
Code:

1 2 3 CellRenderer := GTK_CELL_RENDERER(Pointer(Instance)); // CellRenderer^.xalign := 0.5; // centré mais très moche pour listbox-combobox CellRenderer^.xalign := 0; // ok, aligné à gauche
Plus qu'à trouver une combine pour passer un paramètre permettant à la proc de s'adapter à la cible...

2 pièce(s) jointe(s)

hello,
voici une solution au texte non centré dans une listview avec gtk2 :
L'astuce consiste à créer une procédure d'appel différente suivant que l'on a une combobox, listbox ou une listview :
cela se passe d'abord dans gtk2wscustomlistview.inc

Code:

1
2
3
      // add renderers
      pixrenderer := gtk_cell_renderer_pixbuf_new();
      textrenderer := LCLIntfCellRenderer_New_Center; // au lieu de  LCLIntfCellRenderer_New

Ensuite il faut modifier le fichier gtk2cellrenderer.pas où se trouve la gestion du renderer pour y ajouter des procédures :

Code:

1
2
3
 
function LCLIntfCellRenderer_GetType_Center: TGtkType;
function LCLIntfCellRenderer_New_Center: PGtkCellRenderer;

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
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
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
procedure LCLIntfCellRenderer_ClassInit(aClass: Pointer); cdecl;
//aClass: PLCLIntfCellRendererClass
var
  LCLClass: PLCLIntfCellRendererClass;
  RendererClass: PGtkCellRendererClass;
begin
  LCLClass := PLCLIntfCellRendererClass(aClass);
  DebugLn(['LCLIntfCellRenderer_ClassInit']);
  RendererClass := GTK_CELL_RENDERER_CLASS(aClass);
  LCLClass^.DefaultGtkGetSize := RendererClass^.get_size;
  LCLClass^.DefaultGtkRender := RendererClass^.render;
  RendererClass^.get_size := @LCLIntfCellRenderer_GetSize;
  RendererClass^.render := @LCLIntfCellRenderer_Render;
end;
 
procedure LCLIntfCellRenderer_ClassInitCenter(aClass: Pointer); cdecl;
//aClass: PLCLIntfCellRendererClass
var
  LCLClass: PLCLIntfCellRendererClass;
  RendererClass: PGtkCellRendererClass;
begin
  LCLClass := PLCLIntfCellRendererClass(aClass);
  DebugLn(['LCLIntfCellRenderer_ClassInitCenter']);
  RendererClass := GTK_CELL_RENDERER_CLASS(aClass);
  LCLClass^.DefaultGtkGetSize := RendererClass^.get_size;
  LCLClass^.DefaultGtkRender := RendererClass^.render;
  RendererClass^.get_size := @LCLIntfCellRenderer_GetSize;
  RendererClass^.render := @LCLIntfCellRenderer_Render;
end;
 
procedure LCLIntfCellRendererCenter_Init({%H-}Instance:PGTypeInstance;
  {%H-}theClass: Pointer); cdecl;
// Instance: PLCLIntfCellRenderer;
// theClass: PLCLIntfCellRendererClass
var
  CellRenderer: PGtkCellRenderer;
begin
  CellRenderer := GTK_CELL_RENDERER(Pointer(Instance));
  CellRenderer^.xalign := 0.5;
  DebugLn(['LCLIntfCellRendererCenter_Init']);
end;
 
procedure LCLIntfCellRenderer_Init({%H-}Instance:PGTypeInstance;
  {%H-}theClass: Pointer); cdecl;
// Instance: PLCLIntfCellRenderer;
// theClass: PLCLIntfCellRendererClass
var
  CellRenderer: PGtkCellRenderer;
begin
  CellRenderer := GTK_CELL_RENDERER(Pointer(Instance));
  CellRenderer^.xalign := 0;
  DebugLn(['LCLIntfCellRenderer_Init']);
end;
 
function LCLIntfCellRenderer_GetType: TGtkType;
const
  CR_NAME = 'LCLIntfCellRenderer';
  crType: TGtkType = 0;
  crInfo: TGTKTypeInfo = (
    type_name: CR_NAME;
    object_size: SizeOf(TLCLIntfCellRenderer)+100; // a TLCLIntfCellRenderer
    class_size: SizeOf(TLCLIntfCellRendererClass)+100;
    class_init_func: @LCLIntfCellRenderer_ClassInit;
    object_init_func : @LCLIntfCellRenderer_Init;
    reserved_1: nil;
    reserved_2: nil;
    base_class_init_func: nil;
  );
var
  IID: TGUID;
  S: AnsiString;
begin
  if (crType = 0)
  then begin
    // patch by tk: in case of shared library we must create unique name
    if CreateGUID(IID) = 0 then
      S := Format('LCL%d%d%d', [Word(IID.time_low), Word(IID.time_low shr 16), IID.time_mid]);
    crType := gtk_type_from_name(PAnsiChar(S));
    if crType = 0 then begin
      crInfo.type_name:=PAnsiChar(S);
      crType := gtk_type_unique(gtk_cell_renderer_text_get_type, @crInfo);
    end;
  end;
  Result := crType;
end;
 
function LCLIntfCellRenderer_GetType_Center: TGtkType;
const
  CR_NAME = 'LCLIntfCellRenderer';
  crType: TGtkType = 0;
  crInfo: TGTKTypeInfo = (
    type_name: CR_NAME;
    object_size: SizeOf(TLCLIntfCellRenderer)+100; // a TLCLIntfCellRenderer
    class_size: SizeOf(TLCLIntfCellRendererClass)+100;
    class_init_func: @LCLIntfCellRenderer_ClassInitCenter;
    object_init_func : @LCLIntfCellRendererCenter_Init;
    reserved_1: nil;
    reserved_2: nil;
    base_class_init_func: nil;
  );
var
  IID: TGUID;
  S: AnsiString;
begin
  if (crType = 0)
  then begin
    // patch by tk: in case of shared library we must create unique name
    if CreateGUID(IID) = 0 then
      S := Format('LCL%d%d%d', [Word(IID.time_low), Word(IID.time_low shr 16), IID.time_mid]);
    crType := gtk_type_from_name(PAnsiChar(S));
    if crType = 0 then begin
      crInfo.type_name:=PAnsiChar(S);
      crType := gtk_type_unique(gtk_cell_renderer_text_get_type, @crInfo);
    end;
  end;
  Result := crType;
end;
 
function LCLIntfCellRenderer_New_Center: PGtkCellRenderer;
begin
  DebugLn(['LCLIntfCellRenderer_New_Center']);
  Result := g_object_new(LCLIntfCellRenderer_GetType_Center, nil,[]);
end;
 
function LCLIntfCellRenderer_New: PGtkCellRenderer;
begin
  DebugLn(['LCLIntfCellRenderer_New']);
  Result := g_object_new(LCLIntfCellRenderer_GetType, nil,[]);
end;

et voilà le résultat sous LUbuntu 16.04 gtk2 Lazarus 1.8 :
Pièce jointe 357048

EDIT : en pièce jointe les fichiers modifiés à mettre dans lcl/interfaces/gtk2 . Testés avec Lazarus 1.8.2 gtk2 sous Lubuntu 16.04

Ami calmant, J.P (santé)

05/03/2018, 08h20
Jipété

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

Et moi je rajoute : respect ! :bravo::applo::hola:

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

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

Grand :merci: par avance
06/03/2018, 18h45
Jipété

1 pièce(s) jointe(s)

Citation:

Envoyé par Jipété

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

Ça me démangeait... :mouarf:

Et donc :

Pièce jointe 357617

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 :merci: plus fort que comme ça :king:
:yaisse2:

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

Et je coche :resolu: ! Elle est pas belle la vie ? :applo:
06/03/2018, 23h35
Jipété
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:

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

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, :mouarf:

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 !
:ccool: