Discussion :

[Jipété]

Bonjour,

un soupçon d'explications, en s'appuyant sur cette jolie image :


de gauche à droite 24 TPanel's, qui embarquent chacun une TCheckBox, et à droite toute 3 TLabeledEdit's pour afficher les valeurs R, G et B.
Entre ces deux parties on voit les sommets de 3 TrackBar's pour les informations H, S et L.

Bien.
Pour parcourir dans un sens ou dans l'autre ces panneaux, j'utilise les flèches gauche et droite du clavier, c'est tellement plus sympa et plus rapide, et donc je gère l'événement OnKeyDown, et c'est là que je vous conseille d'arrêter de fumer et d'attacher votre ceinture, on arrive dans une zone de turbulences...

En effet, selon le sens de parcours, les logs montrent qu'un événement est généré complètement en dehors de mon contrôle, si si !
J'ai planté des lignes de log partout dans mon code (True pour avoir l'heure), je le résume ainsi :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
// j'appuie sur "flèche droite"
10:17:23 deb FormKeyDown, key 39
10:17:23 fin FormKeyDown
// j'attends 2 secondes et j'appuie sur "flèche gauche"
10:17:25 deb FormKeyDown, key 37
10:17:25 fin FormKeyDown
// le saut de ligne ici c'est juste visuel pour séparer le bloc suivant
 
10:17:25 deb ComputeHSLcolor, gestion événements des trackbars HSL
10:17:25     ComputeHSLcolor après test d''entrée
10:17:25 deb SetupRGBcounters
10:17:25 fin SetupRGBcounters
10:17:25 fin ComputeHSLcolor

Ce bloc n'existe pas dans le déplacement vers la droite à 10:17:23, très bien, je n'en veux pas, il ne devrait pas exister dans le déplacement vers la gauche, et pourtant il est là !, sorti de nulle part...

La détection du sens de circulation, dans la sous-procédure SetupColonne de FormKeyDown :

Code :

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

1
2
3
4
5
6
7
8
    previusPanel := currentPanel; // 2 TPanel's de travail
    id := StrToInt(Copy(currentPanel.Name,6,Length(currentPanel.Name)-1));
    if sens = 0 then begin // on recule
      dec(id); if id = -1 then id := 23;
    end else begin // on avance
      inc(id); if id = 24 then id := 0;
    end;
    currentPanel := TPanel(gpbxColonnes.Controls[id]);

et le case de détection de la touche enfoncée, dans le begin...end; de FormKeyDown :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
  log('FormKeyDown, avant case, Key '+inttostr(Key), True);
  case Key of
    37: SetupColonne(0); // en arrière à gauche
    39: SetupColonne(1); // en avant à droite
    72: begin verrouHSL:=True; trkH.SetFocus;end; // h
    76: begin verrouHSL:=True; trkL.SetFocus;end; // l
    83: begin verrouHSL:=True; trkS.SetFocus;end; // s
    70: ; // f en attente
    78: begin verrouHSL:=True; ckbxGris.SetFocus;end; // n
  end;
  log('FormKeyDown, après case, Key '+inttostr(Key), True);
  log('fin FormKeyDown', True);
end;

J'ai écrit "sorti de nulle part" car si j'ai mis un point d'arrêt à l'entrée de la proc ComputeHSLcolor (c'est elle qui gère les événements des 3 trackbars) pour demander l'affichage de la pile d'appels, tout ce que j'y vois c'est qu'il y aurait un événement concernant un TrackBar, oui, mais je n'y touche pas, ni ma souris ni mon code.
Alors ?
Le seul endroit où il y a une instruction trkH.Position:=une_valeur c'est dans la proc SetupHSLcurseurs, qui n'est pas appelée (point d'arrêt inefficace).
Cette proc est équipée des mêmes lignes de log que les autres, et il n'y a rien dans le log la concernant.
Alors ?

Sur cette image on voit bien en bas ligne 8 l'événement concernant un trackbar, ok, mais il sort d'où ? Qui a tripoté mon trackbar dans mon dos ?


En cliquant sur cette ligne 8 on se retrouve là, et un point d'arrêt sur la 1^re ligne ligne puis F9 pour continuer et flèche à gauche à nouveau, même pas je fais une copie d'écran, c'est juste incompréhensible.


Bref, je suis sec comme une éponge au soleil, là.
Je compte sur vous, parce que mine de rien, ce gag met le bronx dans la gestion des couleurs je vous dis pas...
Bon dimanche et joyeuses Pâques,

EDIT :
un examen attentif de la première image tout en haut montre que le trackbar H a le focus, et ce dès l'affichage de la fiche après F9. Comment ? Pourquoi ? La seule ligne pouvant le lui donner est dans le case, Key 72 = touche "h" appuyée, et je jure de ne pas avoir appuyé sur cette touche.
En désespoir de cause, je tente un truc de malade, forcer l'ActiveControl dans l'inspecteur d'objets, qui est vide, au GroupBox contenant les TPanel's et là, ô miracle, ça tombe en marche !
À la réflexion, je vais plutôt le mettre dans le FormCreate, des fois que dans l'inspecteur d'objets ça saute (parfois constaté).

Je vais tester dans tous les sens avant de cocher , je pourrais tout aussi bien supprimer totalement ce post mais je préfère le garder pour l'édification des générations futures…
Bon sang, le diable se cache vraiment dans les détails !

Oui, je sais, il y a une faute d'orthographe non corrigée, j'ai écrit Previus au lieu de Previous, mais c'est pour l'alignement vertical :

Code :

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

1
2
    (previusPanel.Controls[0] as TCheckBox).Checked:=False;
    (currentPanel.Controls[0] as TCheckBox).Checked:=True;

Vous imaginez ça comm' ça :

Code :

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

1
2
    (previousPanel.Controls[0] as TCheckBox).Checked:=False;
    (currentPanel.Controls[0] as TCheckBox).Checked:=True;

Non mais allô quoi,

[Andnotor]

Les touches de direction permettent de déplacer le curseur d'un barre de défilement. Jusque là, rien d'anormal.
Elle est le premier contrôle actif de la fiche et reçois le focus au démarrage, rien d'anormal non plus.

Mettre KeyPreview à TRUE n'empêche pas la propagation du message au composant, c'est juste un preview !
Key := 0 pour l'empêcher (peut-être aussi l'ajouter dans FormKeyUp).

Vous imaginez ça comm' ça

Non, comm' ça :

Code :

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

1
2
(PreviousPanel.Controls[0] as TCheckBox).Checked := FALSE;
(CurrentPanel.Controls[0]  as TCheckBox).Checked := TRUE;

Après, les goûts et les couleurs...

[Jipété]

Pas bien compris ta réponse :

1)- il n'y a pas de barres de défilement sur ma fiche ;
2)- s'il n'y en a pas, sur quel contrôle va tomber le focus au démarrage ? Comment le savoir ? Où est-ce documenté ? Depuis 25 ans que je cause en Pascal, c'est la première fois que je tombe sur l'embrouille salée que j'ai décrite.
3)- j'ai besoin de KeyPreview puisque je vais intensément utiliser les touches du clavier pour piloter l'ihm ; quand tu écris "c'est juste un preview !" qu'est-ce que tu sous-entends avec ce "juste" ?

4)- à la limite,

Code :

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

1
2
(PreviousPanel.Controls[0] as TCheckBox).Checked := FALSE;
 (CurrentPanel.Controls[0] as TCheckBox).Checked := TRUE

[Andnotor]

1. Trackbar, Scrollbar, même combat ! Les touches de direction font variés la position du curseur
   .
2. Le composant avec focus à la création de la fiche dépend de la propriété TabOrder. Si tu n'y touches pas, cette propriété est indexée (par rapport à son conteneur : fiche, panel, groupbox, etc.) à chaque fois que tu poses un nouveau composant. Le contrôle avec TabOrder à 0 du conteneur avec TabOrder à 0 (et ainsi de suite jusqu'à remonter à la fiche) est le contrôle actif au démarrage.
   .
3. Il y a une boucle de messages au niveau de TApplication. TApplication va ensuite les faire suivre à la fiche active qui les fera suivre au contrôle détenant la focalisation. Dans cette cascade, tu peux ordonner à la fiche de générer ses propres événements en rapport au clavier (KeyPreview) mais ça n'interrompt pas automatiquement la cascade. Ces messages sont donc traités par la fiche ET par le composant (voir point 1).
   Si tu ne veux pas que la fiche les fasse suivre au composant, il faut fixer Key := 0 (un VK invalide) dans les événements de la fiche.
   .
4. Bof !

[Jipété]

Bonjour,

Si tu ne veux pas que la fiche les fasse suivre au composant, il faut fixer Key := 0 (un VK invalide) dans les événements de la fiche.

Prenons un exemple concret, je suis dessus en ce moment : j'utilise les 4 flèches du clavier pour activer avec gauche-droite 1 TPanel sur 24 et ça fonctionne bien.
Avec haut-bas je pilote un TUpDown qui est activé ou pas par une lettre en mode bascule : j'appuie sur la touche ça active et il va accepter les flèches, je rappuie ça désactive. Easy.

Maintenant, le souci, c'est que j'ai rajouté un composant TRadioGroup avec 3 items et lui, il prend tellement la main qu'il réagit aux 4 flèches et les composants ci-dessus ne sont plus pilotés.
Comment faire avec ton Key := 0; ? Où le mettre ? Pas dans FormKeyDown quand même, c'est là que je dispatche ma petite cuisine, et sinon, je ne vois pas.
Dans le OnKeyDown du radiogroup ?
Parce que mine de rien, pour que cet animal réagisse aux flèches, je n'ai pas eu besoin de coder, c'est d'origine, et je ne vois aucune propriété pour désactiver ce comportement un peu... dictatorial je dirais,

Merci,

[Andnotor]

Où le mettre ? Pas dans FormKeyDown quand même

Ben si !

Après, tu peux toujours le conditionner par ActiveControl is ou ActiveControl = si tu veux tout de même que l'événement se propage.

Bien sûr que ça demande du travail si tu veux intercepter certains événements ; globalement, ou certains événements pour certains composants. Pas de miracle !
Tu peux aussi le faire au niveau des composants mais il y aura du tri à implémenter.

[Jipété]

Moui oui oui...

Va donc falloir que je revoie toute la gestion de la fiche, j'ai du boulot !

Merci,

[Jipété]

Bonjour,

En fait c'est plus compliqué que prévu, car certains événements ne se comportent pas de la même manière que d'autres malgré des noms très similaires (et pour trouver la différence, tiens fume ! Qu'est-ce qui change entre MouseDown [ou Up] et MouseClick ? Lire le code plus bas), et le focus n'est pas toujours passé comme on s'y attendrait (voir le code du Button1), bref, il y a de quoi "tomber" la boîte d'aspirine…

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
procedure TForm1.Button1Click(Sender: TObject);
begin
  // selon qu'une ligne est commentée et l'autre non, ou l'inverse,
  rdg.ItemIndex := 1; // l'item n'a pas le focus
  //Button2.SetFocus; // Button2 récupère le focus
end;
 
procedure TForm1.FormKeyDown(Sender: TObject; var Key: Word; Shift: TShiftState);
begin // sans oublier le KeyPreview à True
  if key = 65 then rdg.ItemIndex := 2; // a
  if key = 66 then rdg.ItemIndex := 0; // b
  if key = 67 then Button1Click(nil);  // c
//  key := 0; sert à rien -- il suffit de ne pas cliquer et les flèches
// ne réagiront pas -- et pour interdire les clicks, voir dessous
end;
 
procedure TForm1.rdgClick(Sender: TObject); // et PAS MouseDown ou MouseUp
begin // à noter que la sélection des items fonctionne : il se passe donc
  // quelque chose ENTRE rdgClick et Button1.SetFocus,
  // <<<ici très précisément>>>
  Button1.SetFocus; // pour supprimer le focus du rdg, le mettre ailleurs
//  Form1.SetFocus; // mais pas n'importe où ! ici = bad, le rdg réagit aux flèches
end;
 
 
// gardé pour l'édification des générations futures
procedure TForm1.rdgKeyDown(Sender: TObject; var Key: Word; Shift: TShiftState);
begin // à partir du moment où le rdg a le focus par un click souris,
  // les touches de direction sont fonctionnelles, c'est mort
  // EDIT : pas avec la bidouille rdgClick, mais le rdg ne réagit plus aux keys
  if key = 65 then rdg.ItemIndex := 2;
  if key = 66 then rdg.ItemIndex := 0;
  if key = 67 then begin Button1Click(nil); Button1.SetFocus; end;
//  key := 0; // sert à rien
end;

[anapurna]

salut ,

tu as quelques soucis avec la compréhension des événements on dirait

le fait de faire un clic sur un composant il prend le focus
si tu attribues dans cet événement une valeur qui va déclencher dans un autre événement sur un contrôle c'est celui-ci qui reprend le focus

si tu cherches dans les sources du composant tu t’aperçois qu'un clic est déclenché dès que tu changes l’état de la Tcheckbox

ne pas confondre l’événement Click attaché à un composant et mouseClick qui lui dépend directement de la souris

[tourlourou]

Un MouseClick est déclenché par un MouseDown puis un MouseDown sur le même contrôle sans déplacer la souris, sinon il y a déclenchement d'un ou plusieurs MouseMove, OnBeginDrag, etc.
L'OS ne sait pas ce qui va suivre comme action.
C'est donc au codeur de prévoir les options dans les événements de bas niveau (quand ceux de plus haut niveau ne suffisent pas), quitte à interrompre la chaîne de traitements en annulant une touche pressée au OnKeyDown, par exemple.

[Jipété]

Bonsoir,

si tu attribues dans cet événement une valeur qui va déclencher dans un autre événement sur un contrôle c'est celui-ci qui reprend le focus

ou pas…

Code :

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

1
2
3
4
5
6
7
8
9
procedure TForm1.Button1Click(Sender: TObject);
begin
  Button2.SetFocus; // Button2 récupère le focus
end;
 
procedure TForm1.Button1Click(Sender: TObject);
begin
  rdg.ItemIndex := 1; // l'item n'a pas le focus
end;

Et quand je navigue avec les touches du clavier dans le radiogroup, les items n'ont pas le focus (heureusement que le bouton radio fonctionne) alors qu'en cliquant à la souris on voit le rectangle de focalisation.

En fait, je me suis rendu compte que l'utilisation de la souris interfère d'une manière désagréable avec la gestion par touches du clavier, heureusement, à coups de Key := 0; glissés ici et là, j'arrive à avoir quelque chose de fonctionnel, mais mine de rien, c'est bien tordu la programmation événementielle quand il y a des choses qu'on ne maîtrise/contrôle pas, dans les couches bas niveau.
C'est comme ça…

si tu cherches dans les sources du composant tu t’aperçois qu'un clic est déclenché dès que tu changes l’état de la Tcheckbox

Je ne vous cacherai pas que j'en ai un peu marre de mettre les mains dans le cambouis à chaque fois que je dois utiliser ma voiture.
J'aimerais bien pouvoir rouler sereinement, des fois.