Discussion :

[Anselme45]

Hello!

Je suis confronté à un problème qui est peut-être plus un problème Android que "Delphien".


Mon objectif:
Capturer le code barre lu par une douchette bluetooth dans une app Android développée en Delphi FMX (Delphi Rio 10.3.3).


Principe de fonctionnement:

• La douchette transmet le code barre lu comme une suite de caractères saisies au clavier.
• La douchette compatible Windows/Android est configurée pour fournir le code sous la forme: 1 caractère pour indiquer le début du code barre ("!"), un caractère pour indiquer le type de code barre ("c" pour indiquer qu'il s'agit d'un code barre EAN8), les caractères codés dans le code barre (8 caractères pour un EAN8) et les caractères CR LF pour indiquer la fin du code barre.
• L'app récupère chaque caractère reçu sur un event OnKeyDown et forme le code barre en récoltant les caractère un à un (d'où un caractère qui indique le début du code barre et un caractère de fin du code barre).

Problème rencontré

Sous Windows et sous Android, on n'obtient pas le même résultat.

Si on lit un code barre de type EAN8 (=8 chiffres):

Sous Windows, on obtient: !C20010003 CR LF (cela correspond à la configuration de la douchette)

Sous Android, rien ne va plus:

1. CR et LF ne sont pas détectés (je crois me souvenir que Unix ne traite pas les CR et autre LF)

2. Si on visualise les caractères saisis dans un Tmemo en affichant la valeur du string qui a capturé un à un les caractères reçus, on a !C20010003 (sans CR et LF)

3. Je contrôle le nombre de caractères reçus en contrôlant length(string)=21 (21 et pas 10 qui serait la longueur d'un string "!C20010003"!!!)

4. Je vérifie donc le code ASCII des caractères reçus au niveau de l'event onKeyDown:

33 99 0 50 0 48 0 48 0 49 0 48 0 48 0 48 0 51 0 0 0

Ce qui correspond à:
! C 2 0 0 1 0 0 0 3


On a le bon code ASCII suivi d'un 0 après chaque caractère et un 0 final en lieu et place de CR LF.


Conclusion

Sous Android, l'event reçoit 21 caractères, la string montre 10 caractères mais indique une longueur de 21 caractères et ajoute à la fin un "0" qui correspond à "je ne sais pas quoi".

Sous windows, l'event reçoit 12 caractères (les 10 caractères visibles + CR + LF), la longueur du string=12 et le string montre les 10 caractères visibles.


Est-ce que quelqu'un a une expérience dans le traitement des string au niveau de Android, une explication sur le fonctionnement obtenu sous Android et une solution pour détecter les CR et LF envoyés sous Android?

Merci d'avance à tous ceux qui pourront m'éclairer...

[ShaiLeTroll]

Cela aurait été 33 0 99 0 50 0 ... cela aurait fait penser à l'unicode avec un 0 0 terminal

length(string) et string.length donne la même chose ?

Key, KeyChar et Shift dans OnKeyDown donne-t-il des informations complémentaires

[Anselme45]

Cela aurait été 33 0 99 0 50 0 ... cela aurait fait penser à l'unicode avec un 0 0 terminal

length(string) et string.length donne la même chose ?

Key, KeyChar et Shift dans OnKeyDown donne-t-il des informations complémentaires

J'ai pensé à l'unicode mais je confirme que j'ai un "33 99 0" et pas un "33 0 99 0"...

Length(string) et string.length donnent le même résultat (21 dans l'exemple) pour la simple et bonne raison qu'il y a effectivement 21 caractères: des caractères affichables (les "c", "0", "1", etc-.) et des caractères non affichables (des NUL codé en ASCII par la valeur 0 qui suit l'envoi d'un caractère visible, exception faite du premier caractère "!").

Explication possible: les derniers caractères reçus pourraient correspondre au code ASCII=0 suivi d'un zéro. ASCII=0 correspond à NUL. Le string envoyé par la douchette avec un CR LF pourrait être traité comme une chaîne de caractère à zéro terminal, non?

[pprem]

le onkeydown est-il sur un TEdit avec focus ou sur un autre élément de l'interface

si c'est sur un TEdit, comment as-tu configuré les propriétés KillFocusByReturn et ReturnKeyType ?

peux-tu vérifier si tu as ces caractères dans le onkeyup ?

[Anselme45]

le onkeydown est-il sur un TEdit avec focus ou sur un autre élément de l'interface

si c'est sur un TEdit, comment as-tu configuré les propriétés KillFocusByReturn et ReturnKeyType ?

peux-tu vérifier si tu as ces caractères dans le onkeyup ?

Le onkeydown est sur la TForm principale de l'app parce que les code barres servent non seulement à lire des codes barres d'identification mais également d'outil de navigation de l'app (un code barre X et l'app déclenche la fonction Y).

Par contre dans le code du onkeydown, je fais un setfocus sur un TEdit caché pas visible par l’utilisateur pour s'assurer qu'à aucun moment un composant de l'app puisse capturer les info provenant de la douchette. Les données de la douchette sont donc "collectées" par le TEdit caché et utilisés "réellement" par le code du onkeydown.

Pour le TEdit caché, le KillFocusByReturn=false et le ReturnKeyType=default. Si je ne m'abuse ces paramètres interviennent au niveau de la gestion du clavier virtuel. Dans mon cas, le TEdit n'est pas utilisable par l'utilisateur et ne permet pas d'activer le clavier virtuel.

Les caractères sont récupérés directement au niveau du onkeydown de la TForm, le TEdit n'intervient donc pas dans cette saisie.

***
Je peux tout de même récupérer le code barre reçu en filtrant les codes ASCII=0 (équivalent à NUL), mais la question qui subsiste est de savoir si ces ajouts de NUL se limitent à certains modèles d'appareils Android, à certaines version de Android ou encore à certains modèles de douchettes

[SergioMaster]

J'ai lu quelque chose pour un sujet similaire, mais il y a un bail, impossible de remettre la main dessus

[pprem]

Pour le TEdit caché, le KillFocusByReturn=false et le ReturnKeyType=default. Si je ne m'abuse ces paramètres interviennent au niveau de la gestion du clavier virtuel. Dans mon cas, le TEdit n'est pas utilisable par l'utilisateur et ne permet pas d'activer le clavier virtuel.

Les caractères sont récupérés directement au niveau du onkeydown de la TForm, le TEdit n'intervient donc pas dans cette saisie.

Un focus sur un champ caché, je n'aurais pas tenté, mais c'est bien si ça passe.

En effet le ReturnKeyType concerne l'affichage du clavier virtuel et le comportement de sa touche RETURN donc ne devrait pas entrer en jeu.
En revanche le KillFocusByReturn est géré par FMX qui déclenche l'affichage et le masquage du clavier selon les touches saisies, du coup il intercepte le RETURN.

Je peux tout de même récupérer le code barre reçu en filtrant les codes ASCII=0 (équivalent à NUL), mais la question qui subsiste est de savoir si ces ajouts de NUL se limitent à certains modèles d'appareils Android, à certaines version de Android ou encore à certains modèles de douchettes

Pour les zéros envoyés, ça doit venir de la couchette, il n'y a pas de raison que Delphi génère une touche 0/0 s'il n'y en a pas eu sans correspondance.

Juste par curiosité tu devrais voir ce qu'il se passe avec un KillFocusByReturn à true sur le onchange du TEDit et vérifier si par hasard tu ne reçois pas le CRLF dans le onkeydown de ce composant plutôt qu'au niveau de la fiche.

Après, si c'est une touchette Bluetooth, tu peux aussi la configurer de sorte qu'elle envoie ses données lues sur un service BT et le consulter depuis Delphi.