Discussion :

[Anselme45]

Bonjour à tous,

Dans une app Android, j'ai du code qui se déclenche sur l'event Form1.OnKeyDown.

L'event se déclenche correctement... Je clique sur des boutons, l'event se déclenche toujours... Je clique sur un edit, puis un bouton, l'event ne se déclenche plus!

Avec VCL, la solution serait simple avec un KeyPreview à true, mais KeyPreview n'existe pas avec FMX pour Android!

Aussi bien un bouton qu'un edit peuvent garder le focus...

Pourquoi est-ce que le clic d'un bouton n'empêche pas le fonctionnement de l'event Form1.OnKeyDown, mais qu'un edit court-circuite l'event Form1.OnKeyDown?

Si au démarrage de l'app, on ne donne pas explicitement le focus à un objet, qui a le focus?

Est-ce qqn à une explication à proposer?

[pprem]

Hello

Par défaut c'est la fiche qui a le focus sur les mobiles ou le composant ayant le TabOrder le plus bas dans toute la hiérarchie.

Quand un champ de saisir prend le focus il traite les touches, du coup l'événement ne remonte pas au niveau de la fiche. Il faut le faire à la main si tu veux appeler le onKeyDown de la fiche.

[Anselme45]

Hello

Par défaut c'est la fiche qui a le focus sur les mobiles ou le composant ayant let aborder le plus bas dans toute la hiérarchie.

Quand un champ de saisir prend le focus il traite les touches, du coup l'événement ne remonte pas au niveau de la fiche. Il faut le faire à la main si tu veux appeler le onKeyDown de la fiche.

Hello pprem,

Quand tu dis le faire à la main, tu penses à quoi?

Est-ce que je pourrai déclencher l'event form1.onKeyDown avec une commande du style "form1.keydown"?

Sur clic de l'edit, l'edit prend le focus OK... Mais quand je clique ensuite sur un bouton, c'est le bouton qui prend le focus, non? Pourquoi alors est-ce que le form1.onKeyDown ne se déclencherait pas à nouveau (comme discuté après démarrage de l'app, je peux cliquer sur tous les boutons que je veux, l'event form1.OnKeyDown se déclenche toujours)?

J'ai aussi essayé de redonner le focus à la form, mais cela ne fonctionne pas les form1.SetFocused(form1), form1.SetFocused(self) plantent à la compilation, form1.SetFocused(form1.Focused) est accepté mais je n'ai pas le résultat escompté...

[pprem]

Les événements sont juste des pointeurs sur des méthodes, donc tu peux directement l'appeler comme n'importe quelle méthode/procédure/fonction.

Par mesure de prudence il est préférable de vérifier que c'est pas nil avant au cas où.

Code :

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

if assigned(onkeydown) then onkeydown(jesaisplusquelsparametresdetete);

[Anselme45]

Bon, je dois avouer je suis dans le flou complet...

J'ai trouvé par hasard un cas qui évite le problème mais je n'arrive pas à comprendre le pourquoi du comment.

J'ai donc 3 scenario possibles:

1. Je lance l'app, clic sur des boutons et mon form1.onKeydown va tjrs se déclencher
2. Je lance l'app, et dès que je clique sur un edit, c'est terminé...Je peux cliquer sur tous les boutons de l'app (ou forcer le focus sur un objet de la form par un setfocus), la form1.onKeydown ne fonctionnera plus
3. Le cas magique: Je lance l'app, et dès que je clique sur edit, la form1.onKeydown ne fonctionne plus... Avec ShowMessage, j'affiche un message qui doit être validé par le clic du bouton OK, la situation se débloque et le form1.onKeydown se remet à fonctionner!!!

Est-ce que qqn peut expliquer ce comportement?

Est-ce que qqn saurait comment le "singer" via code?

[SergioMaster]

Bonjour,

Tout d'abord, je me suis permis de déplacer la discussion vers Composants FMX. Même si l'intitulé est un peu ambigu (à cause de "composants"), le sujet est bien FMX et non sur L'EDI Delphi.

N'étant pas fan de form.Keydown, j'ai tendance à éviter. Je ne saurais pas répondre exactement à la question ni répondre aux arcanes du "pourquoi ?", sauf peut-être que le TEdit fait appel au clavier virtuel (normalement) et que cela à peut-être une relation. Il me semble que dans ce cas OnVirtualKeyBordHidden pourrait servir pour appeller Keydown

Code :

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

1
2
3
4
5
procedure TForm18.FormVirtualKeyboardHidden(Sender: TObject;
  KeyboardVisible: Boolean; const Bounds: TRect);
begin
 FormKeydown(Sender, // autres paramètres à définir) 
end;

J'ai aussi la souvenance d'avoir lu il y a peu un article qui parlait d'évènements FMX et qui pourrait peut-être répondre à la question "singe" je n'ai pas la référence mais des articles sur les FMX Events cela ne doit pas courrir les rues. Ce serait peut-être une piste

[pprem]

Est-ce que qqn peut expliquer ce comportement?

Que le Edit intercepte tout est normal.

Qu'une fois qu'il a perdu le focus la fiche ne redéclenche pas le onKeyDown est anormal. Le fait que ça réagisse suite à l'affichage d'un ShowMessage veut probablement dire qu'il y a un truc en interne dans le fonctionnement de la gestion du clavier qui ne reprend pas la valeur standard et comme il ne doit pas y avoir des tonnes de développeurs avec des claviers sur des appareils Android ayant besoin d'intercepter les touches en dehors d'un champ de saisie, il est probable que ce défaut n'ait jamais été décelé.

Si ça le fait sur la 10.4.2, il faut le rapporter sur QP avec un exemple. Comme ici je n'ai pas de clavier bluetooth à connecter sur un smartphone, je ne peux faire le test et fournir un code d'exemple pour qu'Embarcadero fasse les vérifications nécessaires.

[Anselme45]

Bonjour,

Tout d'abord, je me suis permis de déplacer la discussion vers Composants FMX. Même si l'intitulé est un peu ambigu (à cause de "composants"), le sujet est bien FMX et non sur L'EDI Delphi.

Pas de problème. J'ai moi-même hésité sur l'emplacement de la discussion. C'était du FMX mais pas un composant FMX.

N'étant pas fan de form.Keydown, j'ai tendance à éviter. Je ne saurais pas répondre exactement à la question ni répondre aux arcanes du "pourquoi ?", sauf peut-être que le TEdit fait appel au clavier virtuel (normalement) et que cela à peut-être une relation.

Je pense également que le clavier virtuel y est pour quelque chose dans mon problème. Cela donne l'impression qu'à la clôture du clavier virtuel, l'OS Android perd le focus sur l'app et que c'est avec le clic du bouton OK du message affiché par ShowMessage que le focus est redonné à l'app.

Je suis conforté dans mon analyse par 2 observations:

1. Si je force le focus sur un objet de l'app dans l'event OnVirtualKeyBordHidden, je constate que l'event form1.onFocusChanged ne se déclenche pas!
2. Si à la sortie de l'edit (donc à la fermeture du clavier virtuel), je clique sur le bouton Andoid "Apercu" qui affiche les fenêtres de toutes les app en cours de fonctionnement et resélectionne l'app, l'app s'affiche à nouveau en plein écran et... le form1.onKeyDown fonctionne de nouveau!!!

Il me semble que dans ce cas OnVirtualKeyBordHidden pourrait servir pour appeller Keydown

Code :

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

1
2
3
4
5
procedure TForm18.FormVirtualKeyboardHidden(Sender: TObject;
  KeyboardVisible: Boolean; const Bounds: TRect);
begin
 FormKeydown(Sender, // autres paramètres à définir) 
end;

Mouais, mais cela ne me sert à rien puisque que j'ai besoin de form1.onKeydown que lorsque des caractères seront envoyés à l'app. Ce qu'il me faudrait c'est ajouter une ligne de code dans l'event OnVirtualKeyBordHidden qui redonne le focus à l'app... (J'ai également essayé un setfocus sur pression d'un bouton après l'edit mais cela ne résoud pas le problème)

Il me reste la solution d'afficher un message alibi du genre Showmessage('Hello les gars!') après l'edit mais il faut avouer qu'ajouter une demande de validation qui ne sert à rien, cela gâche le paysage! Est-ce qu'il y aurait la possibilité d'avoir le même comportement que le clic sur le bouton OK du ShowMessage via du code pour faire une rustine invisible pour l'utilisateur? Mystère!

[Anselme45]

Qu'une fois qu'il a perdu le focus la fiche ne redéclenche pas le onKeyDown est anormal. Le fait que ça réagisse suite à l'affichage d'un ShowMessage veut probablement dire qu'il y a un truc en interne dans le fonctionnement de la gestion du clavier qui ne reprend pas la valeur standard et comme il ne doit pas y avoir des tonnes de développeurs avec des claviers sur des appareils Android ayant besoin d'intercepter les touches en dehors d'un champ de saisie, il est probable que ce défaut n'ait jamais été décelé.

En l'occurence, c'est pas un clavier mais un terminal Android qui envoie ses données via events. Mais je suis d'accord avec toi, il y a du bug dans l'air qui n'a pas été décelé

Si ça le fait sur la 10.4.2, il faut le rapporter sur QP avec un exemple. Comme ici je n'ai pas de clavier bluetooth à connecter sur un smartphone, je ne peux faire le test et fournir un code d'exemple pour qu'Embarcadero fasse les vérifications nécessaires.

Le fait de savoir si cela le fait sur Sydney ne résoud pas mon problème à court terme parce qu j'ai été confronté au même problème que SergioMaster avec des requêtes REST qui ne fonctionnent pas avec Sydney. J'ai dû revenir à Rio pour que mon app fonctionne.

[Anselme45]

Question subsidiaire:

Est-ce qu'il y a un moyen avec FMX de faire un log de tous les events qui se déclenchent dans l'app (VCL avait un TApplicationEvents.onMessage si je me souviens bien)?

Cela permettrait de voir ce qui se passe au niveau des events de l'app en cours de fonctionnement.

[Paul TOTH]

Alors, sous FMX, tant que tu n'es pas sur des composants "natifs", tout passe par TForm

il te suffit de surcharger la méthode Keydown de ta fiche et le tour est joué

Code :

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

1
2
3
4
5
6
 
type
  TForm1 = class(TForm)
...
  protected
    procedure KeyDown(var Key: Word; var KeyChar: System.WideChar; Shift: TShiftState); override;

il faut évidemment appeler inherited, mais tu peux par là intercepter le Keydown, y compris quand le TEdit a le focus car c'est cette méthode qui va appeler FFocused.KeyDown(Key, KeyChar, Shift) quand FFocused est le TEdit

je pense que ce qu'il se passe sous Android, c'est que le bouton ne capture pas la focus, à la différence du bouton Windows...euh d'ailleurs comme tu fais pour avoir un Keydown sous Android sans qu'une zone de saisie n'ai le focus ?

[pprem]

je pense que ce qu'il se passe sous Android, c'est que le bouton ne capture pas la focus, à la différence du bouton Windows...euh d'ailleurs comme tu fais pour avoir un Keydown sous Android sans qu'une zone de saisie n'ai le focus ?

Ca peut être le cas avec un device extérieur comme une télécommande ou un joystick sous Android TV. Certains boutons sont envoyés comme des touches, ce qui permet de gérer les déplacements à l'écran par exemple.

[Anselme45]

Alors, sous FMX, tant que tu n'es pas sur des composants "natifs", tout passe par TForm

il te suffit de surcharger la méthode Keydown de ta fiche et le tour est joué

Code :

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

1
2
3
4
5
6
 
type
  TForm1 = class(TForm)
...
  protected
    procedure KeyDown(var Key: Word; var KeyChar: System.WideChar; Shift: TShiftState); override;

il faut évidemment appeler inherited, mais tu peux par là intercepter le Keydown, y compris quand le TEdit a le focus car c'est cette méthode qui va appeler FFocused.KeyDown(Key, KeyChar, Shift) quand FFocused est le TEdit

J'ai essayé différentes méthodes:

1. Avec form1.onKeyDown
2. Comme je gère les différentes écrans de mon app avec un TTabControl, j'ai forcé le focus sur un edit avec l'events TTablControl.onChange (qui se déclenche à chaque changement d'écran) en essayant de capturer les data sur un event edit.onKeyDown
3. Avec la surcharge comme tu le proposes (y compris le "inherited" )

Le résultat est toujours le même: les 3 solutions fonctionnent: Je récupère les données attendues parfaitement tant que je ne saisi pas une info qui appelle le clavier virtuel (j'ai également essayé de forcer le focus sur un edit de l'app à la fermeture du clavier virtuel).

je pense que ce qu'il se passe sous Android, c'est que le bouton ne capture pas la focus, à la différence du bouton Windows...euh d'ailleurs comme tu fais pour avoir un Keydown sous Android sans qu'une zone de saisie n'ai le focus ?

Je peux te confirmer que le bouton ne capture pas le focus dans mon cas.

Je me suis posé la même question (j'ai d'ailleurs essayé de savoir qu'elle objet avait le focus au démarrage de l'app avec un "form1.ActiveControl.Name", cela me donne un "violation d'accès"!).

Je n'ai malheureusement pas de détail technique sur la méthode de transfert des données. Mon device Android est livré avec un "driver" du fabriquant qui transmet les données sous forme de "sortie de touches" (selon la dénomination du fabricant) et il est précisé que les "caractères sont envoyés en tant qu'évènements clavier pour code ASCII".

Apparemment cette méthode n'est pas un truc exotique, j'ai appris que des pda Zebra permettant la lecture de code barre transmettaient le code-barres lu avec une méthode analogue.

[Paul TOTH]

ok tu as un scanner qui simule un clavier

> "form1.ActiveControl.Name", cela me donne un "violation d'accès"!).

normal si ActiceControl = nil

la méthode Keydown en override ne doit pas te donner le même résultat, vu qu'elle se déclenche aussi quand le focus est sur le TEdit ce qui n'est pas le cas du Form.OnKeydown qui ne se déclenche que si ActiveControl = nil ou que le contrôle actif ne traite pas le clavier.

[Anselme45]

ok tu as un scanner qui simule un clavier

C'est pas un scanner mais un appareil de mesure de labo mais le comportement est le même, l'appareil simule le clavier.

> "form1.ActiveControl.Name", cela me donne un "violation d'accès"!).

normal si ActiceControl = nil

la méthode Keydown en override ne doit pas te donner le même résultat, vu qu'elle se déclenche aussi quand le focus est sur le TEdit ce qui n'est pas le cas du Form.OnKeydown qui ne se déclenche que si ActiveControl = nil ou que le contrôle actif ne traite pas le clavier.

Quand j'ai indiqué les 3 solutions testées, il faut comprendre 1 ou 2 ou 3! Avec le Keydown en override ou le form.OnkeyDown, je ne force par le focus sur un TEdit qui déclenche un TEdit.onKeyDown.

Donc, si je considère ton commentaire sur le "form1.ActiveControl.Name", au démarrage de l'app, il n'y a pas dans la form un objet qui a le focus (d'où le ActiveControl = nil) et aussi bien Keydown en override que form.onKeyDown capturent les caractères envoyés. Par contre, quand on insère des données via un TEdit, le focus devrait être sur l'Edit puis entrainer l'ouverture du clavier virtuel.

Puis en toute logique, à la fermeture du clavier virtuel, le focus devrait être sur l'Edit, non? Et donc le KeyDown en override devrait continuer à capturer les caractères envoyés. Mais ce n'est pas ce que je constate.

[Paul TOTH]

alors comme indiqué plus haut Keydown() est appelé dans TOUS les cas, y compris quand TEdit a le focus

si ça ne fonctionne pas c'est que le problème est plus profond.

ça fait un petit moment que je n'ai pas creusé le coeur des applications Android, et je ne sais pas comment elles sont gérées aujourd'hui

mais il y a tout de même une sorte de fille d'attente d'évènements équivalente aux messages Windows

l'évènement remonte en fait ici

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
procedure TAndroidTextInputManager.KeyDown(var AKey: Word; var AKeyChar: System.WideChar; const AShift: TShiftState);
var
  Form: TCommonCustomForm;
begin
  PlatformAndroid.WindowService.HideContextMenu;
  Form := FindActiveForm;
  if Form <> nil then
    try
      Form.KeyDown(AKey, AKeyChar, AShift);
    except
      Application.HandleException(Form);
    end;
end;

et FindActiveForm ne me semble pas pouvoir retourner nil

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
function TAndroidTextInputManager.FindActiveForm: TCommonCustomForm;
var
  I: Integer;
begin
  Result := Screen.ActiveForm;
  if Result = nil then
    for I := Screen.FormCount - 1 downto 0 do
      if Screen.Forms[I].Visible then
        Exit(Screen.Forms[I]);
end;

donc je ne vois pas comment ton évènement clavier peut ne pas remonter dans TForm.KeyDown...sauf à avoir une ActiveForm qui ne serait pas ta fiche...à vérifier

[SergioMaster]

Sauf à avoir une ActiveForm qui ne serait pas ta fiche... à vérifier

Justement, c'est peut-être là que le bogue se cache, l'appel au clavier virtuel changerait la forme active mais surtout, le retour du clavier virtuel ne rendrait pas complètement "la main" ?

[Anselme45]

Bon, j'ai sorti l'artillerie lourde en utilisant un Android Device Monitor pour voir ce qui se passe au niveau de Android... J'ai mis des message de log dans mon app pour voir ce qui se passe.

Voici le log avec des commentaires



J'en conclus:

1. Toth a raison, le keyDown en override se déclenche chaque fois

2. A aucun moment du test, je n'arrive a obtenir le nom d'un objet dans la form qui aurait le focus

3. Au démarrage de l'app (lignes 5 à 8), le simulateur de clavier s'annonce avec l'envoi d'un caractère (c'est un caractère non imprimable, donc pas présent dans un clavier virtuel Android, donc pas identifiable par Android, il me retourne un code ascii=0 comme pour tous les caractères non imprimables correspondant au caractères 0 à 31 d'une table ASCII)

4. Si je ne fais pas de saisie manuelle dans l'app, l'app collecte normalement les trames envoyées par le simulateur de clavier (lignes 11 à 19)
La transmission de la trame se fait par un déclenchement du keydown en override pour chaque caractère: un caractère d'annonce inconnu au début puis les caractères de la trame. Le form.onKeyDown se déclenche également (il ne récupère rien parce que je n'y ai pas mis de code, je voulais juste savoir si il se déclenche également)

5. Saisie manuelle dans un edit de l'app (ligne 21) puis fermeture du clavier virtuel... suivi de l'apparition d'une erreur!

6. Je déclenche un nouvel envoi du simulateur de clavier (ligne 28), le simulateur envoie un caractère d'entête mais plante sur l'envoi de la trame... avec une erreur


Le lien entre le clavier virtuel et le bug semble se confirmer, maintenant qui est responsable de l'erreur: Delphi, le driver du fabricant, l'OS Android... Cela reste pour l'instant un mystère...

Qu'en pensez-vous?

[Paul TOTH]

alors, la première erreur ne semble pas être en relation avec le clavier
https://android.googlesource.com/pla...974/platform.c

la seconde est déjà plus intéressante, le ScanneFramework et IMGKIT renvoie vers Zebra VC80x Android N LifeGuard
https://docplayer.net/151804255-Rele...-for-ngms.html

[Paul TOTH]

Justement, c'est peut-être là que le bogue se cache, l'appel au clavier virtuel changerait la forme active mais surtout, le retour du clavier virtuel ne rendrait pas complètement "la main" ?

d'après mes tests, ce n'est pas le cas, et d'après le log posté juste avant, c'est à plus bas niveau que cela se passe