Laden...

Barcodescanner- & Tastatureingaben unterscheiden

Erstellt von NoLimit vor 12 Jahren Letzter Beitrag vor 12 Jahren 18.099 Views
N
NoLimit Themenstarter:in
191 Beiträge seit 2007
vor 12 Jahren
Barcodescanner- & Tastatureingaben unterscheiden

Hallo zusammen,

hat von euch vielleicht jemand eine Idee wie man die Eingaben eines USB-Barcodescanners von Eingaben einer Tastatur unterscheiden könnte?

"If you give someone a
program, you will frustrate them
for a day; if you teach them how to
program, you will frustrate them
for a lifetime." :evil:

2.891 Beiträge seit 2004
vor 12 Jahren

Bei den Geräten, die sich wie eine Tastatur verhalten (also USB-Barcodescanner, Chipkartenlesegeräte, ...), kann man üblicherweise Pre- und Postfix-Zeichenfolgen einstellen. So wird dann vor und/oder nach dem Einlesen eine besondere Zeichenfolge geschickt (in der Regel Zeichen, die man mit der Tastatur nicht eingeben kann), sodass du dann Start- und Ende des Lesevorgangs mitbekommen kannst.

N
NoLimit Themenstarter:in
191 Beiträge seit 2007
vor 12 Jahren

Das wäre eine feine Sache.
Ich werd mich dann erst mal bei Datalogic umschauen ob dies mit meinem Modell möglich ist.

Ich bin aber auch für weitere Vorchläge bzw. Ansätze offen.

"If you give someone a
program, you will frustrate them
for a day; if you teach them how to
program, you will frustrate them
for a lifetime." :evil:

49.485 Beiträge seit 2005
vor 12 Jahren

Hallo NoLimit,

außerdem wurde das Thema schon einige Male besprochen. Bitte benutze die Forumssuche und poste die besten Treffer hier. Vielen Dank!

herbivore

N
NoLimit Themenstarter:in
191 Beiträge seit 2007
vor 12 Jahren

Nach ein wenig stöbern und ausprobieren kamen für mich nur zwei Möglichkeiten in Betracht:
Man konfiguriert den Scanner so dass er eine RS232 emuliert. Dann ist alles natürlich gar kein Problem mehr. Der Nachteil dabei ist, man braucht natürlich einen Herstellertreiber für den virtuellen Port.

Man konfiguriert den Scanner als HID, und läßt ihn dann Sonderzeichen vor und nach dem Scan ausgeben. Am besten wählt man dafür natürlich Sonderzeichen, die nicht so einfach über die Tasttatur getippt werden können. Bei meinem Modell kann man sogar mehrere und verschiedene Zeichen für Anfang und Ende definieren.
Der Vorteil dieser Methode ist ganz klar: Das Gerät bleibt Plug ´n Play fähig. Der Nachteil ist eben dass man etwas mehr Code tippen muß. Den Aufwand sollte man aber gerne in Kauf nehmen. LibUSB ist natürlich auch noch eine Möglichkeit. Dann wird das Programm aber relativ unflexibel, da, wenn der Scanner mal getauscht werden muss, man entweder den Quellcode anfassen muß, oder aber zumindest die Konfiguration ändern muß.

"If you give someone a
program, you will frustrate them
for a day; if you teach them how to
program, you will frustrate them
for a lifetime." :evil:

T
708 Beiträge seit 2008
vor 12 Jahren

Eine dritte, etwas unkonventionelle Methode ist, die Dauer der Eingabe bis zum Validieren des Textfeldes zu berechnen.
In der Regel schickt der Barcodescanner die Werte + Return (Carriage Return | Linefeed) in wenigen Millisekunden. Ein schneller Lagermitarbeiter wird dort schlecht drankommen 😉

Sicherlich nicht die schönste Lösung, sie sollte aber mit allen Scannermodellen funktionieren. Die Modelle unterscheiden sich deutlich in ihren Fähigkeiten. Setzt du nun auf z.B. STX & ETX als Start- und Endzeichen, so könnte es passieren das ein günstiger Scanner diese Zeichen nicht unterstützt.

Persönlich würde ich es davon abhängig machen, wie Wahrscheinlich es ist andere Scanner einzusetzen. Oder man dem Kunden das als Mindestanforderung verkauft.

N
NoLimit Themenstarter:in
191 Beiträge seit 2007
vor 12 Jahren

So einfach ist das auch wieder nicht.
Du müßtest dann auch auf eine Mindesteingabelänge prüfen, denn du darfst auch den frustrierten Lagerarbeiter nicht vergessen, der einfach mal auf paar Tasten haut 😉

"If you give someone a
program, you will frustrate them
for a day; if you teach them how to
program, you will frustrate them
for a lifetime." :evil:

T
708 Beiträge seit 2008
vor 12 Jahren

Du müßtest dann auch auf eine Mindesteingabelänge prüfen, [...]

Nein, warum?
Eine Textbox löst erst ein Validate aus, wenn er mit der Enter- oder TabTaste das Feld verlässt. Dann ist es doch vollkommen egal ob er 3 Sekunden oder 20 Minuten auf seiner Tastatur herumtippt.
Alles was länger als (aus der Luft gegriffen) 0,5 Sekunden dauert, ist ein Mensch => Fertig 😃

Je nach Arbeitsweise der Lageristen, kann man mit Validate oder LostFocus arbeiten oder auch KeyDown auf den Return Key prüfen.

N
NoLimit Themenstarter:in
191 Beiträge seit 2007
vor 12 Jahren

Was passiert bei einer Copy - Paste Aktion?

"If you give someone a
program, you will frustrate them
for a day; if you teach them how to
program, you will frustrate them
for a lifetime." :evil:

49.485 Beiträge seit 2005
vor 12 Jahren

Hallo trib,

Alles was länger als (aus der Luft gegriffen) 0,5 Sekunden dauert, ist ein Mensch

NoLimit meinte, dass es auch Fälle geben kann, in denen ein (frustrierter) Mensch weniger lange für die Eingabe braucht und dann fälschlich für einen Barcode-Scanner gehalten wird. Allerdings ist das in meinen Augen kein stichhaltiger Einwand, weil es ein Mensch kaum schaffen wird, in der Zeit eine (formal und inhaltlich) korrekte Eingabe zu machen. Das könnte mal also auch noch prüfen.

Wenn man dann noch den Fall Clipboard/Ctrl-V berücksichtigt, mit dem auch ein Mensch innerhalb von quasi Nullzeit eine korrekte Eingabe ins Eingabefeld bringen kann, sollte man aber spätestens auf der sicheren Seite sein. Erkennen kann man das z.B. daran, dass es nur ein einziges TextChanged gibt und nicht für jedes Zeichen eins.

herbivore

N
NoLimit Themenstarter:in
191 Beiträge seit 2007
vor 12 Jahren

Ich werde diesen Ansatz wohl doch auch noch testen.

Bisher hab ich mir zwei Eventhandler gebaut, einer der beim Startzeichen, und einer der beim Endezeichen triggert. So kann ich recht komfortabel reagieren.

Was mir allerdings bei dem Ansatz mit dem timing sehr gut gefällt, er ist nicht so sehr von der Scannerhardware abhängig.

"If you give someone a
program, you will frustrate them
for a day; if you teach them how to
program, you will frustrate them
for a lifetime." :evil:

463 Beiträge seit 2009
vor 12 Jahren

Dumme Frage: Aber warum ist es wichtig zu unterscheiden, woher die Eingabe kommt? Geht es dir nur um die Verfizierung der Prüfziffer hinterher, oder gibt es noch einen anderen Grund?

N
NoLimit Themenstarter:in
191 Beiträge seit 2007
vor 12 Jahren

Dumme Frage: Aber warum ist es wichtig zu unterscheiden, woher die Eingabe kommt? Geht es dir nur um die Verfizierung der Prüfziffer hinterher, oder gibt es noch einen anderen Grund?

Fragen sind nie dumm 😉
Ich möchte (muss) verhindern dass in einer der Textboxen manuell etwas eingegeben werden kann. Es darf dort eben nur eine Eingabe per Barcodescanner erfolgen.
Einfach um Fehleingaben (Manipulationen?) zu vermeiden.

"If you give someone a
program, you will frustrate them
for a day; if you teach them how to
program, you will frustrate them
for a lifetime." :evil:

T
708 Beiträge seit 2008
vor 12 Jahren

Dann würde ich vielleicht besser die Textbox nicht editierbar machen und nur den Wert dort anzeigen. Dann weiß der Lagerist, dass er manipulativ nicht eingreifen kann.

Die Eingabe des Handscanners kannst du dann über die Form empfangen.
(Natürlich inklusive der Eingabedauer-Überprüfung)

protected override bool ProcessCmdKey(ref Message msg, Keys keyData)
{
}

Für mich persönlich gilt: Was der User nicht sieht (nicht editierbar ist) macht auch garnicht erst den Reiz aus, es zu nutzen 😃

Quasi ein "Sie dürfen Form XY nicht öffnen" verhindern, in dem man direkt den Menüpunkt ausblendet.

Gruß,
trib

49.485 Beiträge seit 2005
vor 12 Jahren

Hallo trib,

die MSDN sagt:

Control.ProcessCmdKey-Methode
Verarbeitet eine Befehlstaste.
Beispiele für Befehlstasten sind Zugriffstasten und Tastenkombinationen.

Hier geht es aber um normalen Eingabetasten. Aber ich verstehe, was du meinst, nämlich die Eingaben im Form anzufangen und programmtechnisch in die ausgegraute TextBox zu schreiben. Dazu könnte man KeyDown/Press/Up zusammen mit Form.KeyPreview verwenden. Aber bringt das was?

Es besteht ja das Problem, dass man erkennen muss, wann eine Eingabe für die TextBox mit dem Barcode gedacht ist. Wenn man Enabled = false verwendet, dann kann die TextBox keinen Focus mehr bekommen und man kann das nicht erkennen. Wenn also die TextBox nicht gerade die einzige Eingabemöglichkeit im Form ist, scheidet Enable = false aus. Ok, von Enable = false hast du auch nichts gesagt, du hast von ReadOnly gesprochen.

Wenn man sie ReadOnly macht, kann sie zwar den Focus bekommen, ändert sie ihr Aussehen nicht; das Ziel dem Benutzer optisch zu signalisieren, dass keine Eingabe möglich ist, wird also nicht erreicht.

Er erkennt das lediglich daran, dass keine Eingaben möglich sind (und je nach Einstellung vielleicht noch an einem kurzen Piepen). Das ist aber auch der Fall, wenn man die Prüfungen einbaut, ob die Eingaben von einem Scanner stammen. Dann kann der Mensch auch in eine an sich eingebbare TextBox nichts eingeben. Wenn man als Ergebnis der Prüfung die menschlichen Eingaben sofort wieder entfernt (was auf heutigen Rechnern nicht mal flackern sollte) und es vielleicht kurz piepen lässt, dann sieht es auch bei einer an sich eingebbaren TextBox so aus, als wäre sie ReadOnly.

Da auch bei deinem Vorschlag, die Prüfung auf menschlichen Eingaben erforderlich ist, spart man also nichts, sondern hat nur mehr Aufwand.

Damit sind wir allerdings schon ein gutes Stück vom Thema weg.

herbivore

1.820 Beiträge seit 2005
vor 12 Jahren

Hallo,

Wenn man sie ReadOnly macht, kann sie zwar den Focus bekommen, ändert sie ihr Aussehen nicht; das Ziel dem Benutzer optisch zu signalisieren, dass keine Eingabe möglich ist, wird also nicht erreicht.

Dass könnte man erreichen, indem man die Textbox bei erhalten des Fokus selbst optisch ändert. Zumindest der Aufwand dafür hält sich noch in Grenzen (GotFocus/LostFocus-Events).

Nobody is perfect. I'm sad, i'm not nobody 🙁

463 Beiträge seit 2009
vor 12 Jahren

Wenn man sie ReadOnly macht, kann sie zwar den Focus bekommen, ändert sie ihr Aussehen nicht; das Ziel dem Benutzer optisch zu signalisieren, dass keine Eingabe möglich ist, wird also nicht erreicht.

Also bei mir ändert sich die Hintergrundfarbe einer Textbox wenn diese "ReadOnly" ist automatisch!

A
764 Beiträge seit 2007
vor 12 Jahren

Welche Zeichen eignen sich denn als Präfix & Suffix?

T
708 Beiträge seit 2008
vor 12 Jahren

Welche Zeichen eignen sich denn als Präfix & Suffix?

Gute Frage, bei COM ist es oft STX & ETX also ASCII 02 und 03.
Ansonsten kann man jedes Zeichen nehmen, welches nicht beim Scannen übermittelt wird.
Die Barcodescanner die ich des öfteren im Einsatz hatte, geben allerdings die Zeichen vor. Man hat eine Einrichtungskarte mit mehreren Barcodes drauf und je nach dem welchen man Scannt, kann man den Zeichensatz ändern oder eben die Pre-Suffixe aktivieren.

N
NoLimit Themenstarter:in
191 Beiträge seit 2007
vor 12 Jahren

Es eignen sich praktisch alle Zeichen die man per Tastatur nicht so leicht erzeugen kann.

"If you give someone a
program, you will frustrate them
for a day; if you teach them how to
program, you will frustrate them
for a lifetime." :evil: