[1.4.0] Bug avec RadioGroup et ItemIndex à -1

Salut tout le monde,

Voilà le souci, et c'est très simple :
un RadioGroup sur une Form, 3 lignes d'items, je ne touche pas à la propriété ItemIndex qui reste donc à -1, F9 pour exécuter et vous pouvez comparer le résultat entre 1.0.10 et 1.4.0 :

Pièce jointe 178073

Ça fout les boules car dans certains cas on peut vouloir n'avoir aucun item sélectionné pour laisser un contrôle total à l'utilisateur.

Rien de plus à dire... 8O

Bonjour,

Je viens de tester sous Windows en 1.4.0 et j'obtiens le même comportement que la version 1.0.10. Et si je met un bouton pour appliquer l'itemindex à -1 ça désélectionne bien tous les items... Bizarre ce comportement !

@+

Citation:

---

Envoyé par Jipété

Salut tout le monde,

Voilà le souci, et c'est très simple :
un RadioGroup sur une Form, 3 lignes d'items, je ne touche pas à la propriété ItemIndex qui reste donc à -1, F9 pour exécuter et vous pouvez comparer le résultat entre 1.0.10 et 1.4.0 :

Pièce jointe 178073

Ça fout les boules car dans certains cas on peut vouloir n'avoir aucun item sélectionné pour laisser un contrôle total à l'utilisateur.

Rien de plus à dire... 8O

---

Bonsoir,

J'ai regardé sous Linux Mint 17 et j'obtiens le même résultat alors que sous Windows 8.1 tout va bien (c'est le comble :mouarf:).
En regardant dans le source de TCustomCheckedBox.SetChecked, j'ai vu que le programmeur d'origine a ajouté un commentaire : certains ensembles graphiques comme ceux de la famille gtk n'autorisent pas de désélectionner un bouton radio. Du coup, je me demande si les exemples que tu fournis proviennent de la même machine et s'ils sont compilés avec le même ensemble graphique.

@ bientôt,

Gilles

Re-bonsoir,

J'ai trouvé aussi ceci en me baladant sur une discussion posant le même problème :

Citation:

---

Aha, I think I know what's the problem now, just not sure how to solve it.
On windows, radio buttons are unchecked by default. Linux/gtk/don't know what sets them checked by default. The problem is that radio button can't be unchecked, it can only be unchecked if you check another radio button in the same group (container), while unchecking works under windows perfectly. So i tried button.checked := false after component creation but that does nothing, radio button remains selected.
Actually, even if you put a single RadioButton on a form, you can't change it's Checked property in Object Inspector, it always remains True, and this is not how it behaves in Windows.

---

Source du texte :

http://forum.lazarus.freepascal.org/...ic=4426.5;wap2

C'est en anglais, mais ça semble confirmer ce que j'ai relevé dans le code source :roll: Le problème viendrait de Linux, pas de Lazarus.

Bon courage !

Gilles

Citation:

---

Envoyé par gvasseur58

C'est en anglais, mais ça semble confirmer ce que j'ai relevé dans le code source :roll: Le problème viendrait de Linux, pas de Lazarus.

---

Je rebondis sur ce qui précède et aussi sur ça (mince j'ai oublié de l'inclure en citation, en quote à la mano ça le fera) :

Citation:

---

Du coup, je me demande si les exemples que tu fournis proviennent de la même machine et s'ils sont compilés avec le même ensemble graphique.

---

Les deux exemples viennent bien de la même machine qui est installée avec gtk, ils ont juste 30 secondes d'intervalle, le temps de fermer 1.0.10 (où je me souvenais que ça fonctionnait as expected) après la copie d'écran puis lancer 1.4.0 et créer le même projet et voilà, quoi...

Et donc, non, je ne peux pas être d'accord avec Le problème viendrait de Linux, pas de Lazarus... Car ce que je note c'est que selon la version de Lazarus le problème dans la même session de Linux (pas de reboot, pas de logoff/logon) est présent ou pas !

Et c'est le comportement généré par l'ide qui induit ça : quand j'ai regardé ce défaut visuel, j'ai essayé de forcer la propriété ItemIndex à -1 comme on la trouve quand on pose un RadioGroup vierge sur une Form. Hé bien, impossible ! Je mets -1, je valide avec <ENTRÉE>, la valeur repasse à 0. :aie:

Ça ne peut pas être gtk, àmha...

Citation:

---

Envoyé par gvasseur58

[...] certains ensembles graphiques comme ceux de la famille gtk n'autorisent pas de désélectionner un bouton radio.

---

Je suis d'accord avec le fait qu'on ne puisse pas désélectionner une fois qu'on en a sélectionné un. Mais on peut parfaitement démarrer un prog avec aucun sélectionné, pour laisser un choix total à l'utilisateur : imagine un sondage, un vote, etc. Avec un comportement où une entrée est obligatoirement sélectionnée par défaut, tu orientes le choix de l'utilisateur, tu vois le truc ? Ça craint du boudin :mrgreen:

Bon,

après avoir lu ici, ici (dernière entrée de la liste) et surtout là, je me suis livré à une épouvantable bidouille :mrgreen:, mais une bidouille qui fonctionne !

Il y a donc trois RadioButtons mis par moi dans mon RadioGroup et un bouton hidden, le tout confirmé par

Code:

---

1 2 3 4 5

var i,j: integer; begin j := 0; for i := 0 to rdg.ControlCount-1 do inc(j); showmessage(inttostr(i) +'-'+ inttostr(rdg.ControlCount)); //3-4

---

À partir de là, comme il faut attendre que la feuille soit visible pour que les contrôles réagissent, j'ai posé un timer avec un interval de 10, enabled par default, et dans son code, l'astuce de la mort qui tue (penser à rajouter StdCtrls dans le uses pour les TRadioButton) :

Code:

---

1 2 3 4 5 6 7

procedure TForm1.Timer1Timer(Sender: TObject); begin Timer1.Enabled:=False; TRadioButton(rdg.Controls[rdg.ControlCount-1]).Visible:=True; rdg.ItemIndex:=-1; TRadioButton(rdg.Controls[rdg.ControlCount-1]).Visible:=False; end;

---

Une super-épine du pied bien ôtée, ouf !, ça fait du bien :ccool:

Pièce jointe 178084

Et on peut même rajouter TRadioButton(RadioGroup1.Controls[RadioGroup1.ControlCount-1]).SetFocus; sur la ligne 38 pour enlever le focus de un ; désolé, je l'ai vu après la copie d'écran...

Citation:

---

Envoyé par Jipété

Bon,

après avoir lu ici, ici (dernière entrée de la liste)

---

Bonjour,

Effectivement, étant donné ce premier article, l'origine du problème n'est pas tout à fait celle des ensembles graphiques gtk. J'utilise à dessein pas tout à fait, car c'est quand même gtk qui contraint à définir un bouton actif au risque de ne pas savoir s'il y en a un ou pas !
J'ai lu ce fameux "ici" et ce qui me turlupine, c'est qu'il s'agit d'un pseudo-bogue antérieur à la version 1.0 de Lazarus et qui ne sera jamais corrigé puisqu'il s'agit d'un fonctionnement établi par la conception elle-même (seulement pour les plateformes gtk). Dès les plus anciennes versions, un bouton caché est créé en arrière-plan. Par conséquent, SI la cible est un ensemble graphique de la famille des gtk, le comportement que tu as décrit est inéluctable. Alors, pourquoi ton programme 1.0 fonctionne-t-il selon ton bon vouloir ? Comme je ne crois pas à la magie, je suppose qu'il y a une différence subtile entre les options des projets.
Je n'ai hélas pas gardé de version ancienne de Lazarus (en deçà de la 1.2.4) et ne peut par conséquent pas vérifier complètement. Les codes sources sont-ils accessibles ?

Sinon, la solution trouvée fait un peu usine à gaz, mais si elle fonctionne, bravo !

Gilles

Bonjour Gilles,

Citation:

---

Envoyé par gvasseur58

Alors, pourquoi ton programme 1.0 fonctionne-t-il selon ton bon vouloir ? Comme je ne crois pas à la magie, je suppose qu'il y a une différence subtile entre les options des projets.

---

Les options des projets ? Mais je ne suis pas allé trifouiller là-dedans, j'ai juste fait Projet / Nouveau projet / Application et en avant, coller un TRadioGroup, lui insérer 3 items et F9, pas plus !

Non, moi je me demande si ça ne serait pas des changements au niveau de l'ide lui-même :

Citation:

---

Envoyé par Jipété

Et c'est le comportement généré par l'ide qui induit ça : quand j'ai regardé ce défaut visuel, j'ai essayé de forcer la propriété ItemIndex à -1 comme on la trouve quand on pose un RadioGroup vierge sur une Form. Hé bien, impossible ! Je mets -1, je valide avec <ENTRÉE>, la valeur repasse à 0.

---

Et ce comportement n'existe pas en 1.0.10 : je pose un RdG sur une Form vierge, ItemIndex est à -1, F9 et comme dit hier, aucun bouton sélectionné. J'arrête, je force ItemIndex à 1 et j'ai bien le deuxième bouton sélectionné, en design comme en runtime. J'arrête, je repasse à -1 et ça reste à -1, pas comme en 1.4.0.
Et dans la quote ci-dessus je disais que la valeur repasse à 0, hé bien ce n'est pas tout à fait vrai (je viens de refaire un test) : la valeur repasse à la dernière utilisée ! Là j'avais -1 à la construction et donc l'item 0 sélectionné au runtime, j'arrête et je force 1, j'ai donc le deuxième item sélectionné, j'arrête et je force -1, quand je valide l'ide remet 1. Et ça c'est un autre 'blème...

Mais qu'est-ce qu'ils ont trafiqué ?

Citation:

---

Envoyé par gvasseur58

Je n'ai hélas pas gardé de version ancienne de Lazarus (en deçà de la 1.2.4) et ne peut par conséquent pas vérifier complètement. Les codes sources sont-ils accessibles ?

---

Les codes sources (de radiogroup.inc je suppose) ? Oui, c'est la première idée qui m'est venue à l'esprit après avoir lu les réponses ici, et je n'y ai rien trouvé de significatif. Mais comme quelque chose aurait pu m'échapper, je te mets en pj un zip contenant radiobutton et radiogroup .inc, des fois que ton œil soit plus aiguisé que le mien ;) : Pièce jointe 178095

Citation:

---

Envoyé par gvasseur58

Sinon, la solution trouvée fait un peu usine à gaz, mais si elle fonctionne, bravo !

Gilles

---

Rhôôô, un timer et 4 lignes de code, tu trouves que ça fait usine à gaz ? :mrgreen:

Citation:

---

Envoyé par Jipété

Non, moi je me demande si ça ne serait pas des changements au niveau de l'ide lui-même [...] Mais qu'est-ce qu'ils ont trafiqué ?

---

Je ne sais pas, mais ils ont trafiqué :mouarf:
Le problème est récurrent, mais semble toucher tour à tour Windows et Linux : pas de jaloux.

Citation:

---

Les codes sources (de radiogroup.inc je suppose) ? Oui, c'est la première idée qui m'est venue à l'esprit après avoir lu les réponses ici, et je n'y ai rien trouvé de significatif. Mais comme quelque chose aurait pu m'échapper, je te mets en pj un zip contenant radiobutton et radiogroup .inc, des fois que ton œil soit plus aiguisé que le mien ;)

---

Myope comme je suis, il y a peu de chance :weird: Cependant, le code s'est considérablement alourdi et il y a au moins un truc bizarre :

Code:

---

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

{------------------------------------------------------------------------------   procedure TCustomRadioGroup.UpdateRadioButtonStates;     Read all Checked properties of all radiobuttons, to update any changes in   the interface to the LCL.  ------------------------------------------------------------------------------} procedure TCustomRadioGroup.UpdateRadioButtonStates; var i: Integer; begin FItemIndex:=-1; // si FItemIndex = -1 alors le bouton radio coché est le bouton caché (astuce pour permettre la désactivation avec gtk) FHiddenButton.Checked; // comment se fait-il que rien ne soit affecté à la propriété ??? for i:=0 to FButtonList.Count-1 do if TRadioButton(FButtonList[i]).Checked then FItemIndex:=i; UpdateTabStops; end;

---

Citation:

---

Rhôôô, un timer et 4 lignes de code, tu trouves que ça fait usine à gaz ? :mrgreen:

---

Pour un simple bouton radio non coché, c'est énorme :ptdr: D'autant plus que les limitations de gtk2 sont soi-disant dépassées re-:ptdr:

Bonjour,

petit déterrage (oh, juste deux ans, ça va encore)

La vie n'est pas toujours aussi simple que ce qu'on peut lire dans les codes :

Citation:

---

Envoyé par gvasseur58

Code:

---

FItemIndex:=-1; // si FItemIndex = -1 alors le bouton radio coché est le bouton caché (astuce pour permettre la désactivation avec gtk)

---

---

Voici une superbe image d'un RadioGroup en action, rempli dynamiquement et dont aucun item n'est coché, pour laisser le choix à l'utilisateur (ItemIndex := -1; dans le FormCreate et sans timer, malgré la discussion d'il y a deux ans) :
Pièce jointe 296329

Ensuite l'utilisateur travaille (choisit un filtre, des dimensions, etc.) puis change de fichier à analyser, la moindre des choses est alors de remettre ItemIndex := -1; et là, paf ! SIGSEGV là : radiogroup.inc ligne 395, FHiddenButton.Checked:=true; dans XP et la version 1.6.rc1 (le code de la 1.8rc1 est exactement le même).

Un bout de code ? Allez, soyons fous :

Code:

---

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

try if (FItemIndex <> -1) then TRadioButton(FButtonList[FItemIndex]).Checked := true else FHiddenButton.Checked:=true; // là, le SIGSEGV // uncheck old radiobutton if (OldItemIndex <> -1) then begin if (OldItemIndex>=0) and (OldItemIndex<FButtonList.Count) then TRadioButton(FButtonList[OldItemIndex]).Checked := false end else FHiddenButton.Checked:=false; finally FIgnoreClicks:=OldIgnoreClicks; end;

---

Si quelqu'un a une idée...

Attention, je décide (enfin, pas moi mais les OS qui m'entourent) de mettre la barre plus haut, beaucoup plus haut !

Citation:

---

Envoyé par Jipété

Voici une superbe image d'un RadioGroup en action, rempli dynamiquement et dont aucun item n'est coché :
Pièce jointe 296329

---

et voilà le même RadioGroup en mode Disabled (sans importance) mais avec un item coché, alors que je pensais avoir trouvé la solution pour le post de ce matin : méthode bourrin, tout supprimer et tout recréer, sous Windows ça fonctionne, sous Linux -- ci-dessous -- va te rouler :
Pièce jointe 296347

Franchement ingérable, totalement démotivant...

Bon, ça aura été l'enfer mais je m'en suis sorti.

Toute une aventure et au passage, je signale/rappelle que le timer de la conversation d'il y a deux ans n'est là que pour attendre l'affichage de la fiche, la preuve, là je m'en sors autrement.

Étant entendu que je veux choisir des fichiers par le biais d'un OpenPictureDialog appelé par un bouton, voilà la manip :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

if IsValidBmp(source) then begin // source c'est le bitmap du fichier préalablement chargé //... // nouveau fichier --> nouvelles valeurs donc reset/disable des précédentes. with rdgFilterChoice do begin Visible := False; // pour éviter le flicker : +1 ! Enabled := True; // hack pour pouvoir VRAIMENT basculer à False ! + 327 215 ! ! ! for i := Items.Count-1 downto 0 do Items.Delete(i); // si pas suppression de tout (dessus) et re-création (dessous) --> SIGSEGV CreateFiltersList; Visible := True; Enabled := False; // enfin ok grâce au hack // 3 lignes pour tous les items désélectionnés : {$IFDEF LINUX} TRadioButton(Controls[ControlCount-1]).Visible:=True; ItemIndex := -1; TRadioButton(Controls[ControlCount-1]).Visible:=False; {$ELSE} ItemIndex := -1; {$ENDIF} end; end;

---

Notez bien le hack pour pouvoir VRAIMENT basculer à False, ce truc ayant failli me rendre fou et me dégoûter à tout jamais de coder même un simple HelloWorld.

Hé oui, je voulais simplement que l'affichage soit disabled et ne bascule enabled que lorsque d'autres conditions étaient remplies mais bernique et que dalle !
Le truc était enabled, mais à moitié : visuellement enabled (gris normal, "vivant"), mais ne réagissant pas à la souris, un truc de malade...
En forçant enabled := true; d'abord, le enabled := false; fonctionne ensuite as expected. Ça ne s'invente pas !
Notez-le en gros.

Ce soir, parties de Solitaire, j'en peux plus de ce Lazarus...

EDIT : gag loufoque, vraiment, avec les lignes 7, 8 et 9 du code précédent :

Code:

---

1 2 3 4 5 6

{$IFDEF Windows} for i := Items.Count-1 downto 0 do Items.Delete(i); // sous Windows ces 2 lignes sont obligatoires sinon SIGSEGV // sous Linux on peut s'en passer -- non mais, on se demande, hein !... CreateFiltersList; {$ENDIF}

---

Allez, Solitaire, ça va me reposer.

Citation:

---

Ensuite l'utilisateur travaille (choisit un filtre, des dimensions, etc.) puis change de fichier à analyser, la moindre des choses est alors de remettre ItemIndex := -1;

---

Mais si un utilisateur distrait oublie de faire une sélection avec un itemindex resté à -1 ça risque de faire un beau crash sauf à mettre en place des tests pour vérifier qu'il y-aie bien une sélection active. A mon sens il est de loin préférable d'avoir toujours une sélection active par défaut quelque soit le cas de figure.

Salut,

Citation:

---

Envoyé par mm_71

Mais si un utilisateur distrait oublie de faire une sélection avec un itemindex resté à -1 ça risque de faire un beau crash sauf à mettre en place des tests pour vérifier qu'il y ait bien une sélection active. A mon sens il est de loin préférable d'avoir toujours une sélection active par défaut quelque soit le cas de figure.

---

voilà ce que je disais il y a deux ans :

Citation:

---

Envoyé par Jipété

Je suis d'accord avec le fait qu'on ne puisse pas désélectionner une fois qu'on en a sélectionné un. Mais on peut parfaitement démarrer un prog avec aucun sélectionné, pour laisser un choix total à l'utilisateur : imagine un sondage, un vote, etc. Avec un comportement où une entrée est obligatoirement sélectionnée par défaut, tu orientes le choix de l'utilisateur, tu vois le truc ? Ça craint du boudin :mrgreen:

---

Je n'ai pas changé de philosophie.
Il suffit d'avoir un bouton pour la validation, disabled par défaut et qui passera enabled lorsque l'utilisateur aura choisi un item.

Bonjour,

Citation:

---

Envoyé par Jipété

EDIT : gag loufoque, vraiment, avec les lignes 7, 8 et 9 du code précédent

---

Hier soir j'écrivais ce qui précède, ce matin j'aurais pu faire un EDIT de l'EDIT mais ça risquait de devenir un peu le foutoir.

Je récapitule donc ici, en précisant que cette histoire de gag loufoque était liée à un effet de bord bien vicieux car, en effet (et confirmé en mode pas-à-pas), le fait d'affecter ItemIndex := -1; fait passer par la procedure TMainForm.rdgFilterChoiceClick(Sender: TObject); on se demande bien pourquoi puisqu'il est question de click et donc je ne m'attendais vraiment pas à ce que le code du composant (procedure TCustomRadioGroup.SetItemIndex(Value : integer);) interagisse avec le click.

Bref, la solution consiste à bidouiller, encore et toujours, avec un boolean global, ModeHack :

Code:

---

1 2 3 4 5 6

procedure TMainForm.rdgFilterChoiceClick(Sender: TObject); begin // on passe ici lors du hack pour désélection des items du radiogroup ! Comment l'éviter ? if ModeHack then exit; // autres trucs à moi end;

---

et

Code:

---

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

with rdgFilterChoice do begin Enabled := False; // 3 lignes et un hack pour désélectionner tous les items : ModeHack := True; {$IFDEF LINUX} TRadioButton(Controls[ControlCount-1]).Visible:=True; ItemIndex := -1; // fait passer par OnClick ! TRadioButton(Controls[ControlCount-1]).Visible:=False; {$ELSE} ItemIndex := -1; // fait passer par OnClick ! {$ENDIF} ModeHack := False; end;

---

Au passage on notera que les bidouilles avec Visible et Enabled ont disparu ; liées à d'autres effets de bord bien cachés ?

Testé et validé sous Linux et Windows.


EDIT :
image collector ! :ccool:

On en a parlé par ci par là dans les posts qui précèdent, je ne l'avais jamais vu, mais suite à une microscopique et malencontreuse ligne de code erronée et vite corrigée, je vous rassure !, je l'ai vu apparaître, donc copie d'écran et joie de vous faire partager ce grand moment :
Pièce jointe 296487

Bon, ça n'est pas très beau car l'engin est désactivé à cet instant et j'ai donc un peu bidouillé avec The Gimp, mais on voit bien, en bas à gauche, un RadioButton qui met d'ailleurs la pagaille à l'intitulé de ceux qui sont à droite (on devrait lire 80, 100, 150 et 200).
Bah...

Citation:

---

on se demande bien pourquoi puisqu'il est question de click

---

Parce-que dans ce cas il est aussi question de choix et changer d'index équivaut à l'action provoquée par un clic de souris. C'est à peu près pareil pour tous les composants. Dans un TStringGrid un simple row:=qqchose provoque un on click de même qu'un déplacement fait avec les flèches du curseur.
Quand ce genre de truc me prend la tête j'élimine la procédure par un:

Code:

---

1 2 3

G_Files.OnClick:=NIL; // Virez moi ce click que je ne saurais voir. .... G_Files.OnClick:=@G_FilesClick;//Et je le remet en place quand j'ai fini.

---