Barcodescanner und nicht druckbare Steuerzeichen

[Lemmy]

Servus,

ich versuche mich gerade mit einem Barcodescanner. In der Datamatrix sollten neben den eigentlichen Daten auch (nicht druckbare) Trennzeichen vorhanden sein. Mir fehlt gerade die Idee, wie ich die in Delphi "empfangen" kann um die Daten auszuwerten

Grüße

[himitsu]

Da hier alles an wichtigen Infos fehlt ... was soll man da denn sagen?

welchen
wie
und
nein

[Lemmy]

keine Ahnung was Du da sagen sollst. Ich dachte auf die Frage: Wie kann ich die auch die Steuerzeichen eines Barcodes abgreifen? könnte es eine einfache Antwort geben.

Zitat von himitsu:

welchen
wie
und
nein

Zebra DS2278

keine Ahnung

gut dass wir drüber gesprochen haben

[ol1uw]

Hallo allerseits

Mein Erfahrungen im allgemeinen umschalten auf COM-Emulation dort wird das FNC1 meist als #29 übertragen.

von Zebra zum Thema Software 123Scan und https://www.youtube.com/watch?v=ZNUj...t5Hb-z&index=6

[himitsu]

Per se sind bei den "einfachen" Barcodes keine oder selten "unsichtbare" Zeichen / Steuerzeichen enthalten.


Also via Tastatur-Emulation geht am Wenigsten. (ist auch immer blöd, wenn man aufpassen muß wo der Fokus steht ... also für eine zuverlässige Arbeit eher nicht zu empfehlen)
Vorallem mit welcher "sichtbaren" Taste soll das "unsichtbare" Zeichen "gedrückt" werden? (Tab gibt es fast nie, bzw. in dem Video zum Trennen von mehreren gleichzeitig gescannten Codes, und Zeilenumbruch wird meistens schon als "Ende"-Markierung verwendet)


Über serielles COM geht Vieles, aber kommt auch auf das Format drauf an.
* kann quasi nur der "codierte Text" + #13 sein
* oder ein komplexeres Protokoll, inkl. Zusatzinfos
Und was für Zeichen im Barcode möglich sind, kommt auch drauf an, was für ein Barcode es nun ist.
Es gibt sogar Barcodes, die auch binäre Daten kennen, nicht nur "Text".

Wenn du Glück hast, dann gibt es eine API (DLL, ActiveX oder Dergleichen), womit man alles "direkt" auslesen/steuern kann.
Zebra hat da schon ein großes SDK rumliegen. (gut, direkt für Delphi ist natürlich nichts dabei und man muß auch noch .NET und Java installiert haben)


Was sind "Trennzeichen"?

Wir haben z.B. im Code39 ein * mit drin und bei einigen Scannern mussten wir das nochmal selbst übersetzen, weil die stattdessen was Anderes ausgeben, da nicht überall alles gleich decodiert wird.


Einige 3D-Barcdes besitzen Daten-Blöcke, welche auch jeweils verschiede Datenformate/Informationen enthalten können.
Da muß man nichts selbst trennen und kann auch sonstwas im Barcode speichern, sogar "irgendwelches" binäres Zeugs, wie Bilder oder kleine EXEn.

[Lemmy]

Guten MOrgen,

Zitat von himitsu:

Also via Tastatur-Emulation geht am Wenigsten. (ist auch immer blöd, wenn man aufpassen muß wo der Fokus steht ... also für eine zuverlässige Arbeit eher nicht zu empfehlen)
Vorallem mit welcher "sichtbaren" Taste soll das "unsichtbare" Zeichen "gedrückt" werden? (Tab gibt es fast nie, bzw. in dem Video zum Trennen von mehreren gleichzeitig gescannten Codes, und Zeilenumbruch wird meistens schon als "Ende"-Markierung verwendet)

Danke, das hatte ich befürchtet.

Der Treiber installiert einen COM-Server den ich in Delphi importieren kann, da werde ich mich dann wohl mit dem rumschlagen müssen.

[hoika]

Hallo,
liefern die meisten Barcodes nicht die Daten als Tasturausgabe?
Dann reicht doch ein TEdit zum "Empfangen" der Daten.

[Lemmy]

theoretisch ja, aber da kommen dann keine nchtdruckbaren Zeichen halt dann auch nicht.
Aber das hat mich auf die Idee gebracht mal KeyPress anzuschauen und siehe da: Die Steuerzeichen stehen da drin, damit sollte ich die entsprechend umkodieren können.

[himitsu]

Viele Barcode-Scanner geben über COM das auch als "Text" raus, so ähnlich wie über die Tastatur,
nur dass dort die Daten immer an einem definierten Ziel ankommen, anstatt "irgendwo", wo grade Fokus steht.

Im GetIt hast eine Serial-Komponente (wir haben einfach noch die gute alte ComPortLib4 in Verwendung).
Theoretisch kannst auch einfach mit THandleStream (CreateFile) auf den "COMx" zugreifen.

Bei unseren Kunden schwirrt oft ein Honeywell rum. Diese lassen sich mit Control-Barcodes aus'm Handbuch zwischen Tastatur oder Comport umschalten.
Das ist vermutlich bei vielen Geräten so. (das Gerät stellt hier je nach ein Einstellung "entweder" eine virtuelle Tastatur oder einen virtuellen Comport am USB bereit)
Aber ein Scanner von ner anderen Firma reagiert bissl schlauer. Es stellt beide Schnittstellen bereit und hat es via ComPort eine aktive Verbindung, dann nimmt es Die und sonst geht es über Tastatur raus.

Und nach erfolgreicher Verarbeitung kann man via Serial auch einen Beep (Bestätigung oder Fehler) an den Handscanner schicken.
Wenn der Comport geöffnet ist, zeigt auf dem Scanner auch die LED den Status an (Programm verbungen oder nicht).
Bei einem der Geräte kann man zum/statt des Beeps auch eine grüne LED aktivieren, die auf das Ziel (den gescannten Barcode) einen großen grünen Punkt projiziert.
So hat der Nutzer auch direkt in der Hand eine akustische/visuelle Bestätigung.

Der Standard-Beep vom Scanner sagt ja nur "ich hab was gescannt und zum Rechner geschickt", aber nicht "das kam auch im Programm an und wurde sogar richtig verarbeitet".

Comport oder direkte APIs (SDK) haben einfach enorm viele Vorteile, gegenüber einer Tastaturemulation. (gut, die manuelle Eingabe, z.B. wenn unterm Barcode auch der "Inhalt" mit aufgegruckt ist, das geht da dann nicht unbedingt direkt)