TListboxGroupHeader, redessin au runtime

Bonjour

en trois images et un peu de code le problème
design
Pièce jointe 632870

exécution
Pièce jointe 632871 Pièce jointe 632872

Code

Code:

---

1 2 3 4 5 6 7 8 9 10 11

procedure TForm4.Button1Click(Sender: TObject); begin if Sametext(Clients.Text,'not expanded') then clients.text:='Paramètres Clients' else Clients.Text:='not expanded'; if SKSVG2.RotationAngle=180 then SKSVG2.RotationAngle:=0 else SKSVG2.RotationAngle:=180;   // vérification de la modification dans un TlistboxItem if SKSVG1.RotationAngle=180 then SKSVG1.RotationAngle:=0 else SKSVG1.RotationAngle:=180;   ClientPays.Visible:=not ClientPays.Visible; ClientDevises.Visible:=not ClientDevises.Visible; end;

---

Comme vous le constaterez, la flèche du groupe ne change pas de sens :aie: alors que la flèche d'un TlistBoxItem n'a aucun souci.
Un bogue avait été signalé (puis corrigé) quand on changeait le texte de Groupe (testé en première ligne de code) mais il me semble que le souci est plus grave, votre avis ?

P.S. j'ai tenté, les styles, les beginupdate/endUpdate etc.. sans succès

tu peux tenter ça ?

Code:

---

1 2	SKSVG2.RotationAngle := 180 - SKSVG2.RotationAngle;

---

c'est à la fois plus simple et évite la comparaison d'un Single avec une constante...ce qui est toujours un peu douteux :)

Bonjour,
Élégant :hola:, mais ne change rien au fait que le Header reste inchangé.

La seule solution que j'ai pour l'instant, c'est d'utiliser, à la place d'un TListBoxGroupHeader, un TTistBoxItem et de changer sa propriété StyleLookup en 'listboxPlainHeader'
Dommage, la notion de GroupHeader disparait (sauf au niveau du StyleLookup)

J'ai refait un essai avec un autre TListBroupBoxHeader et pas de problème (la flèche bouge correctement)
Du coup, j'ai repris mon code en ajoutant

Code:

---

1 2 3 4 5 6 7

procedure TForm4.ArticlesClick(Sender: TObject); begin SKSVG2.RotationAngle:=SKSVG2.RotationAngle-180; ListboxItem1.Visible:=not ListboxItem1.Visible; ListboxItem2.Visible:=not ListboxItem2.Visible; ListboxItem3.Visible:=not ListboxItem3.Visible; end;

---

Le deuxième groupe fonctionne correctement.

Pièce jointe 632953

Si je rajoute un item, même de taille faible (hauteur=0) au-dessus de mon premier groupe, le premier groupe a le bon comportement !
Si je rends invisible le filler, je retombe sur le même :bug: bogue, car désormais, je pense pouvoir le qualifier ainsi non ?

Pour ceux qui auraient envie de tester et pour ceux qui ont aussi la prochaine version en test ;) (Delphi 11 + SKIA nécessaire, SkiaSVG à changer par une image si besoin)
j'ai "dépersonnalisé" le programme dans ce zip

alors j'ai fait un test rapide avec un TLabel...et j'ai le même problème, c'est très surprenant...même le changement de texte ne se fait pas...comme si le composant était figé.

Code:

---

1 2 3 4 5 6 7 8 9

procedure TForm1.Button1Click(Sender: TObject); begin Label1.RotationAngle := 180 - Label1.RotationAngle; Label1.Text := Char(1 - (Ord(Label1.Text[1]) - Ord('A')) + Ord('A'));   Label2.RotationAngle := Label1.RotationAngle; Label2.Text := Label1.Text; end;

---

Pièce jointe 632957

=> https://quality.embarcadero.com/browse/RSP-40432

Merci Paul, mais peut-être un dépôt un peu rapide.
Entre temps (fouille dans les sources FMX.TListBox ) , j'ai découvert une propriété de ListBox qui change la donne (ligne 5090, juste au-dessus du { TListBoxGroupHeader }) , GroupingKind. Par défaut à Plain si tu la mets à Grouped, tu devrais obtenir le comportement attendu.

Je ne m'étais penché sur les groupes qu'avec la TListView, il faudra que j'étudie un peu plus s'il y a une équivalence dans la TListBox.

En tout cas, j'oublie le filler, je mets GroupingKind à Grouped et mon problème est :resolu:

alors en effet, changer le GroupingKind corrige le problème, mais quel est le rapport ?!

d'autant que l'aide en ligne n'est pas d'une grande utilité sur cette propriété :/

ah faut regarder ici...mais ça ne change pas qu'il y a un bug :)

Citation:

---

Envoyé par Paul TOTH

alors en effet, changer le GroupingKind corrige le problème, mais quel est le rapport ?!

---

Je ne vois pas le rapport, mais il faudrait certainement fouiller plus dans les sources...

Citation:

---

mais ça ne change pas qu'il y a un bug :)

---

c'était aussi mon ressenti depuis samedi ! :aie: Sauf si la doc est plus explicite car je ne vois pas du tout pourquoi ce qui est codé pour un TListBoxSeparatorItem (première fois que je vois ce type). TlistBoxItemSeparator est la classe de base pour les groupes, mais je ne suis pas allé plus loin

je n'ai pas le temps de creuser...je pense qu'il y a un loup probablement lié aux styles (qui sont des composants instanciés dynamiquement)...

si tu ajoutes une procédure MouseDown sur la fiche

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

procedure TForm1.MouseDown(Button: TMouseButton; Shift: TShiftState; X, Y: Single); begin inherited; var Obj := ObjectAtPoint(ClientToScreen(TPointF.Create(X, Y))); if Obj <> nil then begin var Ctl := Obj.GetObject; AllocConsole; WriteLn('click on ', Ctl.Name, ':', Ctl.ClassName); if Ctl.Name = '' then TButton(Ctl).Visible := False; end; end;

---

tu pourras constater que le composant du haut n'a plus de nom...en fait ce n'est plus Label1 !

et si je le cache, Label1 n'est pas visible pour autant... je ne sais pas où il est passé.