<\/p>\n
Ob Sie nun ein WaWi (Warenwirtschaftssystem) entwickeln, eine Inventurdatenbank oder eine Zugangskontrolle – fast immer treffen Sie auf Barcodes, die zur Identifikation eines Objekts dienen. Das Erstellen solcher Barcodes ist die einfachere, das Lesen die schwierigere Sache. Wir zeigen, wie Sie sich die Entwicklung mithilfe von OPOS – nicht Opus! – erleichtern können.<\/b><\/p>\n
Es ist eigentlich nicht besonders schwierig, Barcodes mit einem handelsüblichen Barcode-Scanner in eine Anwendung einzulesen. In vielen Fällen sind das Geräte, die in die Tastaturschnittstelle eingeschleift werden. Ein Scan erzeugt dann genau so Zeichen, als seien diese über die Tastatur eingegeben worden.<\/p>\n
Der Scanner ist damit universell einsetzbar und Barcodes können in Notepad, Excel, Word oder eben auch in eine Textbox eines Access-Formulars eingelesen werden.<\/p>\n
Früher gab es am Kabelanschluss des Barcode-Scanners einen Adapter, an den man den PS2-Stecker der Tastatur andockte. Heute, da fast jedes externe Gerät über eine USB-Schnittstelle verfügt, findet man diese Technik eher selten und auch Barcode-Scanner sind meist mit USB-Steckern ausgerüstet oder zumindest mit einer seriellen RS232-Schnittstelle.<\/p>\n
Die Umsetzung dieser seriellen Signale in Tastaturanschläge übernimmt dann ein Treiber des Herstellers, der auf dem System installiert wird und häufig mit einer zusätzlichen Anwendung namens Softwedge daherkommt.<\/p>\n
Umständlichkeiten<\/b><\/p>\n
Gehen wir von einer Anforderung aus, wie sie an jedes Kassensystem gestellt wird: Für eine Reihe von Artikeln auf dem Laufband ist der Preis aus einer Datenbank zu ermitteln.<\/p>\n
Die Artikel sind bereits in einer Artikeltabelle gespeichert, die neben eindeutiger IDs für die Datensätze zusätzlich jeweils EAN-Nummern enthält. Der Barcode jedes Artikels wird nun eingescannt, die EAN-Nummer gelesen und über eine Abfrage auf die Artikeltabelle und der EAN-Nummer als Kriterium der Preis ermittelt. <\/p>\n
Rein datenbanktechnisch ist das eine leichte Aufgabe, wenn man einmal davon absieht, dass der Vorgang sehr zügig erfolgen muss, was eine ausreichend schnelle Verbindung zum Backend erforderlich macht.<\/p>\n
Sehen wir uns aber an, wie hier die üblichen Voraussetzungen aussehen, wenn man dabei einen im Tastaturmodus betriebenen Barcode-Scanner verwendet.<\/p>\n
Als Eingabesteuerelement kommt hier praktisch nur ein Textfeld in einem Formular infrage. Das erste Problem, das sich hier stellt, ist die Tatsache, dass dieses Textfeld zu Beginn des Scans zwingend den Fokus haben muss, sich also die Einfügemarke darin befinden muss. In der Eile eines Kassiervorgangs werden Sie dazu sicher weder die Maus, noch die Tab<\/b>-Taste bemühen wollen.<\/p>\n
Alternativ könnte man auch ohne Textfeld arbeiten, die Eigenschaft Tastenvorschau<\/b> des Formulars auf Ja <\/b>setzen und so alle „Anschläge“ des Scanners etwa in KeyDown<\/b>-Ereignissen abfangen.<\/p>\n
In beiden Fällen aber ist ungewiss, wann denn der Scan abgeschlossen ist. Schließlich kommen die Ziffern als eine Serie von zeitlich versetzten Anschlägen an, was noch nicht mal besonders schnell geht – man kann durchaus dabei zuschauen, wie die Zeichen nach und nach eintrudeln. Nun ist zusätzliche Logik erforderlich, die erst einen vollständigen Barcode identifiziert.<\/p>\n
Als Regel könnte man etwa festlegen, dass für einen EAN13-Code nach 12 Zeichen Schluss ist. Was aber, wenn auch Artikel mit EAN8-Barcodes vorkommen, was für kleine Verpackungen etwa gang und gäbe ist Hier schlägt die Regel fehl und andere Mittel zur Ermittlung des letzten Zeichens sind gefragt.<\/p>\n
Eine sehr unzuverlässige Methode wäre etwa, die Zeit zu messen, die zwischen den Anschlägen verstreicht, und festzulegen, dass ein Scan dann vollständig ist, wenn innerhalb eines definierten Zeitraums keine neue Tastatureingabe erfolgt.<\/p>\n
Machen Sie sich besser keine Gedanken, wie solch ein Vorhaben wasserdicht zu realisieren ist. Es gibt eine erheblich einfachere und stabilere Lösung. Wenn ein Gerät schon serielle Signale sendet, warum sollte man diese dann in Tastaturbefehle umwandeln, statt sie gleich in Ereignisse zu überführen, die von einer maßgeschneiderten Schnittstelle ausgewertet werden können Und genau das ist OPOS.<\/p>\n
OPOS<\/b><\/p>\n
OPOS ist die Abkürzung für OLE for Retail POS. POS wiederum steht für Point Of Sales. Das ist der Oberbegriff für alle Hardware-Komponenten, die im Umfeld der Warenwirtschaft vorkommen können – also Barcode-Scanner, Bondrucker, Kassenladen, Chipkarten- und Magnetstreifenleser, Waagen und vieles mehr. All diese Komponenten verfügen über Treiber, die häufig das Signal der Geräte in serielle Byte-Folgen umwandeln. Das Abgreifen dieser Byte-Folgen über API-Funktionen ist schwierig und setzt mindestens voraus, dass die Spezifikation der Datenpakete bekannt ist. Die Hersteller veröffentlichen diese Spezifikationen jedoch in den seltensten Fällen.<\/p>\n
Mit dem OLE im Begriff kommt nun eine weitere Schnittstelle ins Spiel. Tatsächlich ist die Bezeichnung OLE in diesem Zusammenhang veraltet und irreführend. Richtiger wäre COM oder ActiveX, denn das Wesen von OPOS sind ActiveX-Schnittstellen zu den Treibern der Geräte.<\/p>\n
Kurz und bündig zusammengefasst funktioniert OPOS für unsere Aufgabe so: Sie instanzieren ein Objekt einer ActiveX-Schnittstelle, die Sie in die Verweise Ihres VBA-Projekts aufnehmen – hier eine OPOS-Scanner<\/b>-Komponente -, nehmen ein paar Einstellungen vor und werten nun nur noch die Scan-Ereignisse aus, die die Komponente erzeugt. Wie das genau vonstatten geht, finden Sie im Folgenden erläutert.<\/p>\n
Voraussetzungen<\/b><\/p>\n Der letzte Punkt ist nicht zwingend erforderlich, weil sich die Konfiguration im Prinzip auch manuell über Einträge in die Registry erledigen ließe. <\/p>\n Modell<\/b><\/p>\n Es ist verblüffend: Da hat ein Konsortium von Herstellern schon vor über zehn Jahren einen Standard verabschiedet und fortlaufend weiterentwickelt, ohne dass dieser trotz aller Vorteile wirklich wahrgenommen würde. Zwar bieten praktisch alle Hersteller OPOS-Support und die entsprechenden Treiber an, dennoch sucht man nach Anleitungen oder Beispiel-Codes im Netz fast vergebens. Die einzigen Dokumentationen dazu finden sich nahezu ausschließlich in recht dürftiger Form in PDFs auf den Support-Seiten der POS-Hersteller.<\/p>\n Auch die Seite des Konsortiums ARTS selbst [1] gibt nicht viel her. Dort kann man das Hauptwerk zu UnifiedPOS, einer kompatiblen Weiterentwicklung von OPOS, herunterladen, die auch die Referenz zu OPOS enthält. Auf den fast 2000 Seiten dieses Dokuments kann man zwar haarklein Spezifikationen zu jeder Hardware-Gattung finden, aber keine konkreten Entwicklerbeispiele.<\/p>\n Eine etwas ältere Version des OPOS Programmers Guide ist übrigens auch auf der Begleit-CD zum Magazin gespeichert.<\/p>\n Dabei ist das Ganze so schwierig nicht. Beginnen wir mit dem generellen Modell von OPOS, wie es in Bild 1 veranschaulicht ist. <\/p>\n Bild 1: OPOS-Modell<\/span><\/b><\/p>\n Der Barcode-Scanner ist über USB an den Rechner angeschlossen. Es handelt sich hier um ein Modell des Herstellers Metrologic. Beim ersten Einstecken wird Windows vergeblich nach Treibern für das Gerät suchen, aber auch online nicht fündig werden. Entweder Sie haben nun eine mit dem Gerät gelieferte CD zur Hand oder Sie laden die passenden Treiber vom Hersteller-Support herunter.<\/p>\n Dort finden Sie meist allerlei Downloads ohne weitere Anmerkungen, kümmern sich zunächst aber nur um den USB-Treiber, der gemeinhin lediglich die Aufgabe hat, das USB-Gerät über einen virtuellen COM-Port zu veröffentlichen. Ohne diesen Treiber funktioniert alles Weitere nicht.<\/p>\n Sie entpacken also das heruntergeladene Treiberpaket, stecken den Scanner ein und folgen den Anweisungen von Windows, die letztlich in der Aufforderung münden, das Verzeichnis mit den Treibern anzugeben.<\/p>\n Das Gerät zeigt sich nach erfolgreicher Installation im Zweig Anschlüsse des Geräte-Managers von Windows und im Prinzip könnten Sie nun bereits über eine COM-Schnittstelle Kontakt mit dem Scanner aufnehmen und seinem seriellen Port lauschen.<\/p>\n API-Geraffel wollen Sie aber wohl nicht und laden deshalb im zweiten Schritt die OPOS-Treiber zum Gerät herunter. Im Falle unseres Metrologic-Scanners nennt sich die Software etwa MetrOPOS Driver. Die enthält häufig nicht allein den OPOS-Treiber, der lediglich aus einer einzelnen kleinen DLL besteht, sondern auch noch Konfigurationsanwendungen.<\/p>\n Der OPOS-Treiber hat eine bestimmte Aufgabe. Er kennt das Gerät und dessen Treiber ganz genau und kann mit ihm in allen Belangen kommunizieren. Nur der Hersteller des Geräts kann deshalb diesen OPOS-Treiber entwickeln. Die Kommunikation verläuft in beiden Richtungen: OPOS kann vom Gerät lesen und Anweisungen zu ihm senden.<\/p>\n Der Witz an der Geschichte ist, dass der OPOS-Treiber eine standardisierte ActiveX-Schnittstelle anbietet, die einen definierten Satz von Methoden und Eigenschaften beherbergt. Nach außen sieht ein OPOS-Treiber also immer gleich aus. Tatsächlich könnte man diese Schnittstelle verwenden – in unserem Beispiel wäre ein Verweis auf die MetroSO 1.0 Type Library <\/b>der metroSO.dll <\/b>zu setzen -, um vom Scanner zu lesen. Allerdings noch ohne Unterstützung durch Events.<\/p>\n Auch sonst wäre noch ziemlich aufwendige Programmierung nötig, um mit dem OPOS-Treiber direkt zu sprechen. <\/p>\n Unabhängigkeit<\/b><\/p>\n Das größte Manko bei direkter Ansprache des OPOS-Treibers ist jedoch, dass man damit dem Scanner-Hersteller ausgeliefert ist. Schließlich ist ein Verweis auf die herstellerspezifische DLL zu setzen.<\/p>\n Wollte man den Barcode-Scanner am Kassensystem aber durch ein anderes Modell ersetzen, so müsste man die Anwendung komplett neu erstellen und einen Verweis auf den neuen OPOS-Treiber setzen. <\/p>\n <\/p>\n Damit man hier unabhängig bleibt, wurde für OPOS eine weitere Ebene eingezogen, die die Abstraktion erhöht. In Bild 1 ist das die Ebene der geräteunabhängigen OPOS-ActiveX-Komponenten.<\/p>\n Die ActiveX-Komponente kennt den Satz von standardisierten Methoden und Eigenschaften eines OPOS-Treibers. Über diesen Methodensatz spricht sie ihn an. Der Clou daran aber ist, dass die Komponente den Treiber selbst gar nicht kennen muss. Sie erfährt alles Nötige dazu aus der Windows-Registry, nachdem man ihr lediglich den Namen eines sogenannten Service Objects angegeben hat. Dort steht dann, welche Treiber-DLL anzusprechen ist, um die Kommunikation herzustellen. <\/p>\n Natürlich müssen zuvor diese Registry-Einträge gesetzt worden sein. Das erledigt man entweder manuell oder sinnvoller über eine Anwendung, die dafür bestimmt ist. In unserem Fall kommt diese Anwendung gleich mit dem Metrologic-OPOS-Treiberpaket, das bereits heruntergeladen und installiert wurde.<\/p>\n OPOS-Konfiguration<\/b><\/p>\n In Bild 2 sehen Sie einen Ausschnitt der Konfigurationssoftware MetrOPOS<\/b>.<\/p>\n Bild 2: OPOS-Konfiguration eines Metrologic-Barcodescanners<\/span><\/b><\/p>\n Die Sache ist denkbar einfach: Sie geben nur an, über welche Hardware-Schnittstelle der Scanner angeschlossen ist (USB), um welches Modell es sich handelt (Voyager 9520) und vor allem einen benutzerdefinierten Namen (metroscanner), über den der Scanner später angesprochen werden soll. Nach Übernehmen der Einstellungen schreibt das Tool alle benötigten Daten in die vorgesehenen Stellen der Registry.<\/p>\n Sie können auch mehrere Profile anlegen, falls Sie mehrere Scanner am System betreiben. Wichtig sind dabei jeweils die eindeutigen Namen zur Kennzeichnung der Scanner.<\/p>\n Besonders komfortabel ist es allerdings nicht, wenn Sie auf dem Zielsystem, etwa dem Kassensystem, immer erst die Konfigurationssoftware installieren müssen, um den Scanner einzurichten. Das ist aber auch nicht unbedingt erforderlich, wenn Sie wissen, welche Einträge in die Registry geschrieben werden müssen. Dann reicht schon die Weitergabe und ActiveX-Registrierung des OPOS-Treibers aus – hier: metroSO.dll <\/b>– und eine .reg<\/b>-Datei, die den passenden Zweig der Registrierungsdatenbank enthält. Dieser Zweig ist ebenfalls standardisiert und findet sich immer unter:<\/p>\n Für jede Geräteart gibt es hier einen eigenen Zweig – Scanner, Scale, Printer et cetera.<\/p>\n Unterhalb dieser Schlüssel befinden sich die benutzerdefinierten Einstellungswerte unter dem Namen, den Sie für das Gerät vergeben möchten.<\/p>\n Der Baum für den in Bild 2 konfigurierten Scanner stellt sich unter Vista etwa wie in Bild 3 dar.<\/p>\n Der Schlüssel metroscanner <\/b>enthält die Werte aus Bild 4.<\/p>\n Bild 3: Registry-Baum für eine OPOS-Scanner-Konfiguration (Vista)<\/span><\/b><\/p>\n Bild 4: Einstellungen für den OPOS-Scanner in der Registry<\/span><\/b><\/p>\n Für eine Weitergabe brauchen Sie nun lediglich den Zweig metroscanner <\/b>aus der Registry in eine .reg<\/b>-Datei zu exportieren und auf dem Zielrechner wieder zu importieren, ohne eine Konfigurationssoftware zu installieren. Bedenken Sie jedoch, dass der OPOS-Treiber nur dann funktionieren kann, wenn bereits ein serieller Treiber für das Gerät installiert wurde.<\/p>\n Übrigens enthält der Schlüssel mehr Werte als unbedingt nötig. Wichtig sind meist nur zwei: Die ProgID <\/b>des OPOS-Treibers (Metrologic.Opos.Scanner<\/b>) und der Name der Treiberdatei (MetroSO.dll<\/b>). <\/p>\n OPOS-Controls<\/b><\/p>\n Damit wären wir endlich auf der untersten Ebene des OPOS-Modells (siehe Bild 1) angekommen, der OPOS-ActiveX-Komponente, die sich in Gestalt eines OPOS-Scanner<\/b>-Steuerelements manifestiert.<\/p>\n Diese Komponenten auf Grundlage des ARTS-Standards kann eigentlich jedermann entwickeln, der sich dazu bemüßigt fühlt.<\/p>\n Es ist aber eine weitere Eigentümlichkeit von OPOS und Beweis für dessen Nischendasein, dass diese Komponenten fast ausschließlich aus der Feder von Curtis Monroe [2] stammen.<\/p>\n Seine freien Komponenten sind quasi Referenz und werden selbst von so namhaften Herstellern wie Metrologic verwendet. Folgerichtig sind sie auch bereits im OPOS-Treiberpaket MetrOPOS <\/b>enthalten. <\/p>\n Sollte Ihr Hersteller keine OPOS-Steuerelemente anbieten oder beipacken, dann laden Sie einfach Monroes Komponenten <\/b>unter [3] herunter.<\/p>\n Der Download enthält alle Komponenten für jede Geräteklasse. Sie brauchen daraus zum Barcode-Scannen nur die Dateien oposscanner.ocx <\/b>und opos_constants.dll<\/b>.<\/p>\n Ich empfehle Ihnen in jedem Fall den Einsatz der Monroe-Komponenten, auch wenn Ihr Scanner-Hersteller eigene ActiveX-Controls anbieten sollte. Diese sind nämlich häufig nicht so stabil oder sie lassen hinreichende OLE-Kompatibilität mit Access-Formularen vermissen.<\/p>\n Alles, was man schlussendlich braucht, ist das OPOS Scanner Control 1.8 <\/b>(Versionsnummer kann abweichen), welches man in ein Formular einfügt. Dort zeigt es sich im Entwurf als etwas krakeliges Icon (siehe Bild 5).<\/p>\n Bild 5: Das Icon des OPOS Scanner Controls <\/span><\/b><\/p>\n Das Steuerelement kann nun mit wenigen Code-Anweisungen auf das Service<\/b>-Objekt des Scanners eingestellt werden und feuert dann bei jedem Scan das Ereignis DataEvent<\/b>.<\/p>\n Man kann sich mit Recht die Frage stellen, wofür man denn ein Steuerelement in einem Formular braucht, wenn dieses zur Laufzeit gar nicht sichtbar ist Tatsächlich kann eine Instanz des OPOS-Scanner<\/b>-Objekts genauso gut als Objektvariable mit WithEvents <\/b>deklariert angelegt und auf das Control verzichtet werden.<\/p>\n In der Beispieldatenbank zum Artikel wurde eben diese Methode gewählt. Bevor wir uns den Einzelheiten zur Programmierung zuwenden, folgt noch eine Zusammenfassung über die Schritte, die bisher erörtert wurden.<\/p>\n Zusammengefasst<\/b><\/p>\n Hier in Kurzform das Vorgehen, um Ihren Barcode-Scanner unter Access OPOS-funktionstüchtig zu machen:<\/p>\n Beispieldatenbank<\/b><\/p>\n Die Beispieldatenbank zu diesem Beitrag heißt scanner.mdb<\/b>. Nach ihrem Start öffnet sich ein Formular namens frmScantest<\/b>, das für die einfache Speicherung von Scan-Ereignissen ausgelegt ist (siehe Bild 6).<\/p>\n Bild 6: Barcode-Scanner-Formular der Beispieldatenbank<\/span><\/b><\/p>\n Aus dem Kombinationsfeld oben kann ein zuvor im System konfigurierter Barcode-Scanner ausgewählt werden. Die Anwendung sucht dazu selbst in der Registry nach verfügbaren Scanner-Profilen. Nach Auswahl des Scanners kann er über das entsprechende Kontrollkästchen aktiviert werden. Gelingt das, so erscheint der Schriftzug Bereit zum Scannen <\/b>und andernfalls eine Fehlermeldung. Sobald Sie dann einen Barcode einscannen, wird ein neuer Datensatz angelegt und der Code sowie dessen Typ in zwei Textfelder eingetragen. Zur Kontrolle zeigt ein ActiveX-Steuerelement den Strichcode an.<\/p>\n Die dem Formular zugrunde liegende Tabelle hat einen einfachen Aufbau (siehe Bild 7).<\/p>\n Bild 7: Tabelle, in der die Scan-Ereignisse gespeichert werden<\/span><\/b><\/p>\n Die Datenbank wird nur dann laufen, wenn zuvor die benötigten ActiveX-Komponenten registriert wurden. Diese befinden sich im Unterverzeichnis \\Komponenten <\/b>auf der Begleit-CD. Führen Sie dort die Batch-Datei register_ocx.bat <\/b>aus.<\/p>\n Unter Vista muss sie als Administrator gestartet werden, nachdem ihr Inhalt in einem Texteditor angepasst wurde – siehe die entsprechende Anmerkung in der Datenbankdatei.<\/p>\n Neben den OPOS-Dateien ist mit der gdsbarcode.ocx <\/b>ein freies Steuerelement enthalten, das zum Anzeigen von Barcodes der Typen EAN8<\/b>, EAN13<\/b>, Code39 <\/b>und Code128 <\/b>geeignet ist. Diese Komponente können Sie sich alternativ unter [4] besorgen. Sie funktioniert auch in Berichten, wie rptScans <\/b>in der Demodatenbank zeigt.<\/p>\n Service-Objekt initialisieren<\/b><\/p>\n Im Formular frmScantest <\/b>werden Sie weder ein OPOS-Scanner<\/b>-Steuerelement vorfinden noch eine Objektvariable, die auf die gleichnamige Klasse verwiese. Im Interesse der Wiederverwendbarkeit wurde der komplette Code zur Steuerung des Service<\/b>-Objekts in ein Klassenmodul clsScanner <\/b>ausgelagert.<\/p>\n Dort ist als zentrales Objekt eine Objektvariable CScan <\/b>definiert:<\/p>\n Durch die Deklaration WithEvents <\/b>kann das Objekt CScan <\/b>Ereignisse auslösen, von denen uns nur das DataEvent <\/b>interessiert, das bei einem Scan-Vorgang hervorgerufen wird.<\/p>\n Damit das OPOSScanner<\/b>-Objekt weiß, welchen Scanner es ansprechen soll, wird der Klasse über die Eigenschaft SOName <\/b>der Profilname mitgeteilt:<\/p>\n Der Profilname wird nur dann in der privaten Variablen m_Name <\/b>zwischengespeichert, wenn das Öffnen des Service<\/b>-Objekts über dessen Open<\/b>-Methode klappt (OPOS_SUCCESS<\/b>). Andernfalls erscheint eine Fehlermeldung, die über die vom OPOSScanner <\/b>zurückgegebene Fehlernummer und die Hilfsprozedur GetOPOSError <\/b>der Klasse ermittelt wird.<\/p>\n Die Open<\/b>-Methode ist übrigens allen OPOS-Komponenten gemein, also auch Komponenten für Bondrucker (OPOSPOSPrinter.ocx<\/b>), Kassenladen (OPOSCashDrawer.ocx<\/b>), Kassendisplays (OPOSLineDisplay.ocx<\/b>) und so weiter.<\/p>\n Sie hat intern die Aufgabe, in der Registry nach den Angaben zum Profilnamen zu suchen, dort den OPOS-Treiber zu ermitteln, Einstellungen zu überprüfen und schließlich die Kommunikation mit dem Service-Objekt einzuleiten.<\/p>\n Ebenfalls allen Komponenten gemein ist die Claim<\/b>-Methode, die in der Prozedur OpenScanner <\/b>der Klasse zu finden ist, und hier ausschnittsweise wiedergegeben wird:<\/p>\n Claim <\/b>bedeutet, dass das Service<\/b>-Objekt versucht, den Treiber des Geräts in den Zugriff zu bekommen. Die Open<\/b>-Methode stellt ja nur sicher, dass die Konfiguration okay ist und alle Treiber vorhanden sind, weiß aber noch nichts vom Status des seriellen Treibers.<\/p>\n Der Treiber kann bereits besetzt sein, wie weiter unten im Abschnitt Entweder oder <\/b>erläutert wird. Deshalb wird der Claim<\/b>-Methode auch ein Wert für das Timeout <\/b>(in Millisekunden) als Parameter übergeben.<\/p>\n Sie gibt erst dann einen Fehlercode zurück, wenn dieses Timeout überschritten wurde, das Gerät oder dessen Treiber also nicht innerhalb der geforderten Zeitspanne antwortet.<\/p>\n War die Claim<\/b>-Methode erfolgreich, dann ist der OPOS-Scanner zwar betriebsbereit, jedoch immer noch nicht aktiv. Dazu muss erst eine Eigenschaft gesetzt werden:<\/p>\n DataEventEnabled <\/b>sagt dem Objekt zusätzlich, dass es Ereignisse feuern soll, und DecodeData <\/b>weist an, dass die Barcode-Daten intern dechiffriert werden sollen.<\/p>\n Diese beiden Eigenschaften sind im Gegensatz zu DeviceEnabled <\/b>nur beim OPOSScanner<\/b>-Objekt verfügbar, nicht generell bei anderen OPOS-Controls.<\/p>\n Nach dem Durchlauf dieser Codezeilen ist der OPOSScanner <\/b>fertig initialisiert und man kann mit dem Scannen loslegen.<\/p>\n Scans auswerten<\/b><\/p>\n Ein Scan ruft nun das DataEvent<\/b>-Ereignis des OPOSScanner<\/b>-Objekts CScan <\/b>hervor:<\/p>\n Leider werden der Ereignisprozedur vom Objekt keine Parameter übergeben, die etwa schon die Strichcodedaten enthielten. Die muss man erst über die Eigenschaften ScanDataType <\/b>und ScanData <\/b>auslesen. ScanData <\/b>enthält dabei einen String, der den fertig entschlüsselten Barcode zurückgibt, falls DecodeData <\/b>aktiviert wurde, und ScanDataType <\/b>ist ein Long<\/b>-Wert, den die Hilfsfunktion BCType <\/b>der Klasse in einen aussagekräftigen String umwandelt, also etwa EAN13<\/b> oder Code39<\/b>.<\/p>\n Die Ereignisprozedur löst ihrerseits das im Modulkopf definierte Event Scan <\/b>der Klasse aus:<\/p>\n Und dieses Ereignis schließlich ist es, auf welches das Formular reagiert:<\/p>\n Hier wird nach dem Scan ein neuer Datensatz angesprungen und in die Textfelder Barcodetyp <\/b>und Barcodedatum <\/b>eingetragen. Sie sehen: Gerade mal drei Zeilen Code sind dafür nötig. Vergegenwärtigen Sie sich, um wie viel komplizierter die Angelegenheit ausfiele, wenn ein Scanner im Tastaturmodus zum Einsatz käme!<\/p>\n Ein Vorteil des OPOS-Scanners tritt hier außerdem zutage: Da auch der Typ des Barcodes ermittelt wird, kann die Datenbank entscheiden, wofür er verwendet werden soll. Kommt etwa ein EAN-Code hereinspaziert, so handelt es sich möglicherweise um einen Artikel, zu dem der Preis ermittelt werden soll. Ist es ein Code128, der alphanumerische Zeichen unterstützt, dann wurde vielleicht eine Mitgliedskarte eingescannt und die Datenbank kann nun in der Kundentabelle nachsehen, ob der Kunde rabattierfähig ist.<\/p>\n Verfügbare Scanner<\/b><\/p>\n Die Klasse clsScanner <\/b>enthält als Bonbon noch eine Funktion, über die alle im System registrierten Scanner-Service-Profile ausgelesen werden können. GetAvailableSOScanners <\/b>gibt einen semikolonseparierten String mit der Liste aller ermittelten Scanner-Profile zurück, der direkt als Datenquelle für ein Kombinationsfeld oder ein Listenfeld verwendet werden kann. Das Formular frmScantest <\/b>macht davon für seine Auswahl-Combo Gebrauch.<\/p>\n Die Routine liest dazu über API-Funktionen den Registry-Zweig aus Bild 3 aus und enumeriert die vorhandenen Service-Namen. <\/p>\n Entweder oder<\/b><\/p>\n Vielleicht haben Sie zusätzlich eine Hilfsanwendung wie eine SoftwareWedge <\/b>installiert, die die Emulation von Tastaturanschlägen für serielle Scanner ermöglicht, damit Sie wahlweise auch in andere Anwendungen, etwa Excel, einscannen können.<\/p>\n Dann sollten Sie sich eines klarmachen: Auf den seriellen Treiber kann nicht von mehreren Anwendungen gleichzeitig zugegriffen werden. Ist die SoftwareWedge aktiv, dann beansprucht sie den Treiber allein für sich und das Service<\/b>-Objekt wird eine Fehlermeldung von sich geben, sobald Sie das Öffnen per Open<\/b>-Methode veranlassen. Umgekehrt kann die SoftwareWedge nicht arbeiten, sobald ein Service<\/b>-Objekt den Scanner per Open <\/b>und Claim <\/b>aktiviert hat.<\/p>\n Selbstverständlich gilt der gleiche Sachverhalt auch, wenn zweimal auf dasselbe Service<\/b>-Objekt zugegriffen wird.<\/p>\n Sie können das überprüfen: Öffnen Sie die Beispieldatenbank in zweiter Instanz und versuchen Sie, den gleichen Scanner zu aktivieren. In der zweiten Instanz wird die Meldung erscheinen, dass das Gerät nicht vorhanden sei. Der Scanner-Treiber ist für das zweite Service<\/b>-Objekt quasi unsichtbar, da bereits besetzt.<\/p>\n Epilog<\/b><\/p>\n OPOS ist ein Satz von ActiveX-Komponenten, der den Umgang mit POS-Hardware erheblich erleichtern kann und flexibilisiert. Es schafft Unabhängigkeit Ihrer Anwendung von den eingesetzten Geräten. Ihre Anwendung braucht lediglich den Namen eines konfigurierten OPOS-Profils, um mit der Hardware arbeiten zu können. <\/p>\n Dieser Beitrag vermittelt das grundlegende Rüstzeug, um Datenbanken den Umgang mit Barcode-Scannern beizubringen. Die Vorgehensweise ist aber für alle OPOS-unterstützten Geräte dieselbe, sodass Sie sie leicht auch auf andere Gerätegattungen übertragen können. Manche, wie etwa Bon- und Etikettendrucker, verlangen allerdings aufgrund der Vielzahl von zusätzlichen Eigenschaften und Methoden eingehendere Auseinandersetzung. Deshalb folgt in einer der nächsten Ausgaben ein Beitrag, der die Steuerung von Druckern über OPOS demonstriert.<\/p>\n Und damit Sie solange was zum Einscannen haben, finden Sie in Bild 8 ein passendes Testobjekt.<\/p>\n\n
![\"OPOS_Modell.emf\"](\"..\/fileadmin\/_temp_\/2009_05\/Barcodescanner-web-images\/OPOS_Modell_opt.jpeg\")
<\/p>\n![\"configurator.png\"](\"..\/fileadmin\/_temp_\/2009_05\/Barcodescanner-web-images\/configurator_opt.jpeg\")
<\/p>\nHKEY_LOCAL_MACHINE\\SOFTWARE\\OLEforRetail\\ServiceOPOS\\Scanner<\/pre>\n
![\"regsettings.png\"](\"..\/fileadmin\/_temp_\/2009_05\/Barcodescanner-web-images\/regsettings_opt.jpeg\")
<\/p>\n![\"regtree.png\"](\"..\/fileadmin\/_temp_\/2009_05\/Barcodescanner-web-images\/regtree_opt.jpeg\")
<\/p>\n![\"oposscan_ctl.png\"](\"..\/fileadmin\/_temp_\/2009_05\/Barcodescanner-web-images\/oposscan_ctl_opt.jpeg\")
<\/p>\n\n
![\"testformular.png\"](\"..\/fileadmin\/_temp_\/2009_05\/Barcodescanner-web-images\/testformular_opt.jpeg\")
<\/p>\n![\"scantabelle.png\"](\"..\/fileadmin\/_temp_\/2009_05\/Barcodescanner-web-images\/scantabelle_opt.jpeg\")
<\/p>\nPrivate WithEvents CScan As OPOSScanner\r\nPrivate Sub Class_Initialize()\r\n Set CScan = New OPOSScanner\r\n End Sub<\/pre>\n
Property Let SOName(strName As String)\r\nDim ret As Long\r\nret = CScan.Open(strName)\r\nIf ret = OPOS_SUCCESS Then\r\n m_Name = strName\r\n CScan.Close\r\nElse\r\n Err.Raise vbObjectError + 800, _\r\n \"clsScanner\", GetOPOSError(ret)\r\nEnd If\r\nEnd Property<\/pre>\n
ret = CScan.ClaimDevice(m_Timeout)\r\nIf ret <> OPOS_SUCCESS Then\r\n Err.Raise vbObjectError + 800, _\r\n \"clsScanner\", GetOPOSError(ret)\r\n Exit Function\r\nEnd If<\/pre>\n
CScan.DeviceEnabled = True\r\nCScan.DataEventEnabled = True\r\nCScan.DecodeData = True<\/pre>\n
Private Sub CScan_DataEvent(ByVal Status As Long)\r\n RaiseEvent Scan(BCType(CScan.ScanDataType), _\r\n CScan.ScanData)\r\n CScan.DataEventEnabled = True\r\n End Sub<\/pre>\n
Public Event Scan(ByVal BarcodeType As String, _\r\nByVal Data As String)<\/pre>\n
Private WithEvents CScan As clsScanner\r\nPrivate Sub CScan_Scan(ByVal BarcodeType As _\r\n String, ByVal Data As String)\r\n DoCmd.GoToRecord acDataForm, Me.Name, _\r\n acNewRec\r\n Me!txtScan.Value = Data\r\n Me!txtType.Value = BarcodeType\r\n End Sub<\/pre>\n
![\"testscan.png\"](\"..\/fileadmin\/_temp_\/2009_05\/Barcodescanner-web-images\/testscan_opt.jpeg\")
<\/p>\n