Lecture QRCode avec lecteur Zebra MC300 et Android

Bonjour à tous,

j'ai actuellement un projet nécessitant la lecture d'un QRCode. Cette lecture se fera sur un lecteur Zebra MC300 sur lequel tourne un système android. J'ai donc fait une petite application Delphi (10.3) dans laquelle il y a un champ Edit. Je précise que la lecture se fera à l'aide du laser et non pas d'un appareil photo.
Le code lu s'inscrit bien dans le champ, mais (sinon je ne serais pas là :) ) dans le texte il a été ajouté des caractères de séparation que visiblement je reçois, mais pas au bon endroit. J'ai essayé le control stylé et le control natif, même résultat.
Comme il y a une application GMail installée sur le lecteur, j'ai fait un petit test : j'ai créé un nouvel e-mail, et j'ai scanné le qrcode en mettant le focus sur un champ d'adresse. Là le résultat est similaire à ce que je reçois dans Delphi. J'ai ensuite fait la même chose mais dans le corps du mail : là c'est parfait les séparateurs sont bien là où ils doivent se trouver.
J'ai pensé donc mettre un TMemo plutôt qu'un TEdit, mais là on est pire. Que ce soit en mode natif ou stylé, il s'arrête dès qu'un caractère de séparation est rencontré le reste n'est pas écrit.

Est-ce que quelqu'un aurait déjà fait ce genre de chose avec un lecteur similaire ?

merci pour votre attention.

@++
Dany

Quand tu parles de "caractère de séparation", c'est pour différencier plusieurs données dans le QRCode ?
Si c'est un QRCode GS1, le caractère FNC1 mais c'est un caractère affichable en ANSI 8 Bits par contre si il y a un encodage UTF8 puis Unicode du texte saisie depuis le Scan vers l'Edit, ça peut ne pas lui plaire

en FMX, un OnKeyPress ou équivalent existe pour que tu puisses récupérer les caractères non ASCII ?

Si c'est un encodage QRCode plus bas niveau, je n'ai pas exploité le QRCode suffisamment pour apporter mon aide, j'ai toujours imprimé qu'une simple série Chiffres+Lettres

Bonjour,

merci pour ta réponse. A priori le séparateur devrait être le caractère ascii 29 (Group Separator)
J'ai pas de onkeypress, mais un onkeydown, j'ai logué ce que je reçois et il y a une différence avec l'affichage final ...

Voilà ce que j'ai au final dans mon TEdit (je met seulement le sébut de la chaine) :

Pièce jointe 586927

image prise de Notepad++, en fait dans le champ j'ai un carré avec une croix dedans à la place de chaque GS

et voilà ce que j'obtiens en concaténant les keychar :

Pièce jointe 586928

alors ce qui est aussi assez étrange, c'est que d'un scan à l'autre les GS dans le champ ne sont jamais vraiment au même endroit, par contre la concaténation des keychar est toujours la même.

Quel est le composant utilisé dans l'application GMail pour le corps du mail ? Lui il affiche correctement la chaine avec les séparateurs au bon endroit... Alors qu'un champ d'édition classique a le même comportement que le TEdit de Delphi. J'avais pensé à un TMemo mais ça ne marche pas mieux, que ce soit en natif ou en stylé. Et je ne vois pas d'autres composants dans la palette Delphi pour faire cela.

Si quelqu'un a une idée ou suggestion ?

Encore merci.

@++
Dany

Bonjour,

Citation:

---

J'ai pas de onkeypress, mais un onkeydown, j'ai logué ce que je reçois et il y a une différence avec l'affichage final

---

ben non pas de onkeypress avec FMX (ce qui est déstabilisant) par contre j'ail lu quelque part qu'il valait mieux utilisé onKeyUp (même si cela ne doit pas changer grand chose).

Citation:

---

Cette lecture se fera sur un lecteur Zebra MC300 sur lequel tourne un système android.

---

Je n'y connait pas grand chose, en cherchant de la documentation sur le lecteur je ne trouve en première recherche que des informations "commerciales".

Donc, ma question semblera bête mais ce lecteur Zebra interprête t'il la valeur du Code ou, ne fait-il que scanner le code ?
En effet ce que tu montres comme chaine de caractères reçu me parait bien peu explicite du coup je me pose la question ne serait-ce point un stream d'image que tu reçois ?
Enfin quand je dis image c'est au sens large, je pense plutôt à un Stream que ZXing peut déchiffrer.

Sans matériel difficile de faire une tentative ne ce sens. Je suggère de récupérer le "scan" dans un Stream et de tenter de traiter ce Stream comme une image ou directement avec ZXing. Comment ? Là je ne fais que supposer que c'est un peu comme une acquisition d'une image d'un appareil photo un peu spécial (ce qui implique permission d'accès etc..)
Le principe en serait là https://blog.andreamagni.eu/2017/06/...d-tframestand/

Bonjour,

Merci Serge. En fait le device scan le qrcode et renvoi la chaine de caractères lue dans un champ d'édition, comme pour un code à barre classique. La plupart des QRCODES sont lus sans problèmes, mais pour ujn projet avec un client on a un QRCode un peu particulier dans lequel il y a un code séparateur imposé par le client. C'est ce code qui n'arrive pas bien placé, je ne sais pas pourquoi.

Je comprends que sans matériel ça n'est pas simple (déjà qu'avec ça ne l'est pas :) ). J'insiste sur un point mais il me parait important et curieux : sur ce même lecteur (il comporte un écran tactile et un OS Android) on peut faire tourner des applications classiques, comme sur un téléphone ou une tablette. Il y a installé la suite Google, donc GMail. Je me suis amusé à scanner le qrcode en mettant le focus suru n champ adresse dans GMail et là j'ai le même résultat que dans mon application. J'ai alors mis le focus sur le champs corps du mail et j'ai à nouveau scanné le qrcode. Et là surprise, tout est bien avec le séparateur au bon endroit ! (les séparateurs en réalité, il y en a 13). Tous les caractères utiles sont bien récupérés dans mon application, il n'y a pas d'erreur, ni de blocage. Seulement j'ai besoin des séparateurs aux bons endroits sinon j vais avoir du mal à découper les informations contenues dans la chaine reçue.
Donc ce que je me demande c'est qu'elle différence y a t-il entre le champ adresse de GMail et le champ Corps. De prime abord j'ai pensé que le corps était un memo, j'ai donc essayé de remplacer ma zone dans mon appli par un memo, j'ai essayé la version stylée et la version native. Mais là c'est pire. J'ai l'impression qu'il rencontre le CS au même endroit, mais en plus il arrête de recevoir les caractères à cet endroit. Je ne récupère que entre 1 et 3 lettres suivant où va se placer le premier CS.

par contre dans le onkeydown du TEDit je récupère toujours la même suite de caractères... J'ai aussi essayer de loguer les caractères ascii. Les specs du clients disent que ce caractère est le code ascii 29, mais dans la suite de codes que j'ai logué je ne trouve aucun code 29... mais pleins de codes 0 par contre (qui correspondent logiquement aux null de ma copie d'écran)
Je suppose qu'il y a un problème d'encodage, mais je ne sais trop où chercher. Mais pourquoi GMail arrive à l'afficher correctement, je ne pense pas que Google ait développé un system particulier pour les lecteurs Zebra :) donc ça ne doti quand même pas être si exotique que ça.

J'ai un contact chez Zebra, je vais lui poser la question, mais j'ai peur de connaître sa réponse, je l'ai déjà eu une fois au téléphone pour un pb d'installation de mon poste de développement (Delphi ne le voyait pas connecté. Au final ils ne nous avaient pas livrés le bon socle, celui que j'avais ne permettait pas les échanges de données via USB :D ). Mais déjà il m'avait fait une réflexion qu'avec Delphi il y avait une couche graphique particulière et que ça ne récupérait pas bien les données...
Je n'attend donc pas une grande aide de leur part, donc je me tourne vers vous même si je sais que c'est un peu particulier comme problème :) .

@++
Dany

Bonsoir,

Problème finalement résolu ! Au final, rien à voir avec Delphi. Après un petit break on a souvent les idées plus claires :) E fouillant dans les paramètres du scanner je suis tombé sur une rubrique "gestion des évènements clavier". En allant voir dedans je me suis aperçus qu'il y avait une incohérence entre le mode d'envoi des caractères ascii de 32 à 128 qui généraient des évènements clavier et les code ascii de control qui n'en généraient pas. Du coup j'ai compris pourquoi ils se retrouvaient toujours en début de chaine mais pas forcément toujours placés au même endroit.
J'ai décoché la génération des évènements clavier pour les caractères ascii de 32 à 128 et maintenant je reçois bien tout et dans le bon ordre :)

Merci à tous ceux qui ont passé un peu de temps sur mon sujet.

@++
Dany