Hilfe - Barcode-Scanner

Warum baust du in die GUI nicht einfach ein Input mit Autofokus, einen "Defaultpushbutton" und eine Edit in die als Event auf dem Button geschrieben wird?

Idee dahinter:

Durch Autofokus steht der Cursor automatisch in dem Input. Jedes Zeichen wird automatisch an das Input gesendet. => Die Zeichenfolge landet in dem Input.

Durch den defaultpushbutton haben wir ein Control, dass auf Enter reagiert und damit ein Event auslöst. => Wir können jedes Enter als Ende einer Zeichenfolge sehen.

In das Edit wird nun über das Event vom Button der Inhalt aus dem Input geschrieben und der Fokus erneut auf das Input gesetzt (den Fokus hat da aktuell der Button)

Hi,
generell ist es völlig egal, an welches Control du den String vom Scanner sendest.
Wie von dir vermutet, ist das _ispressed() das Problem. Das brauchst du aber auch garnicht, da das @CRLF ja sowieso im String ist und dementsprechend abgefragt/verarbeitet werden kann.
Du brauchst auch keinen extra Button und auch kein extra Event (obwohl es sicherlich ein ENTER-Event in der InputBox gibt)

#include <array.au3>
#include <file.au3>
#include <MsgBoxConstants.au3>
#include <date.au3>
#include <GuiButton.au3>
#include <GuiEdit.au3>
#include <GuiStatusBar.au3>
#include <GUIConstantsEx.au3>
#include <FontConstants.au3>
#include <Misc.au3>


HotKeySet("{ESC}", "Terminate")


Global $oError = ObjEvent("AutoIt.Error", "_ErrFunc")
Global $zeitstempel
Global $value[7]
Global $inhalt[7]
Global $hDLL = DllOpen("user32.dll")


Main()
Func Main()
Global $key
    GUICreate("")
	  Local Const $sFont = "Comic Sans Ms"
		 Global $label_1 = GUICtrlCreateLabel("Ich brauche Nachschub", 10, 10, 300, 35)
		 GUICtrlSetFont($label_1, 15, $FW_NORMAL, $GUI_FONTUNDER, $sFont)
		 Global $auftrags_nr = GUICtrlCreateInput("", 10, 70, 300, 35)
		 GUICtrlSetFont($auftrags_nr, 15, $FW_NORMAL, $sFont)
		 GUISetState(@SW_SHOW)
Local $idMsg
	$trigger = 0
While $trigger = 0


	  $idMsg = GuiGetMsg()
	  switch $idMsg
		 Case $GUI_EVENT_CLOSE
                ExitLoop
		  case $auftrags_nr
				consolewrite(guictrlread($auftrags_nr)&@crlf)
				GUICtrlSetData($auftrags_nr,"")
	 EndSwitch


WEnd
EndFunc






 Func Terminate()
	Exit
EndFunc

@Andy
Bezugnehmend auf die Zeile 25 vom Script, frage ich mich, was Du gescannt hast. Spontane viel mir ein "6-Pack".

@Alina, das war das Script des TE, ich habe nur einige Zeilen geändert so dass es funktioniert.

Mein Script funktioniert mit diversen Scannern einwandfrei, ich bin daher hier raus...
Eins noch, wenn man Scanneranwendungen für eine GUI schreibt, sollte man dem Fenster den TopMost-Modus gönnen, falls mobile Scanner eingesetzt und benutzt werden. Nichts ist ärgerlicher, als mit dem Scanner Barcodes einzulesen, an den Rechner zurückzukommen und dort festzustellen, dass ein freundlicher Kollege zwischenzeitlich ein anderes Programm bedient hatte...
Ich habe u.a. daher auf Scanner mit Speicherfunktion zurückgegriffen, nach dem zurückkommen an den Rechner werden auf Knopfdruck alle Daten ausgelesen,

Der Thread ist zwar schon nicht mehr ganz frisch, aber ich denke, es gibt ein paar grundsätzlich erwähnenswerte Hinweise zu Scanner-Problemen:

1) Man vergewissere sich, ob der Scanner so konfiguriert wurde, dass er am Ende wirklich CRLF sendet und nicht nur CR, oder LF.
Oder gar LFCR ...
Es ist eine sehr gute Idee und hat sich bestens bewährt, den Output eines Scanners zunächst mit einem geeigneten Terminalprogramm (bei seriellen Scannern) zu überprüfen, das auch Hexdarstellung beherrscht!
Nur ein in Hex dargestellter String lügt nicht!
"HTerm" ist dazu bestens geeignet: http://www.der-hammer.info/terminal/
(Für USB-Scanner vielleicht direkt in einen Hexmonitor scannen).
Man überprüfe penibel sowohl die exakte Anzahl der Zeichen, als auch das korrekte Zeilenende!

2) Anschließend vergewissere man sich, dass das Programm, das den String empfängt, auch wirklich das gleiche Zeilenende haben will, das der Scanner sendet.
Denn wenn der Scanner CRLF sendet, das jeweilige Programm aber bereits mit CR glücklich ist, dann wandert das "überflüssige" LF als führendes Zeichen in den nächsten String! Der nächste Barcode stimmt dann folglich nicht mehr, weil sich alles um ein Zeichen verschiebt.

3) CRLF vom Scanner ist zwar praktisch, aber auch gefährlich! Ich hatte mal den Fall, dass Anwender meines Artikelverwaltungsprogrammes über ständigen Datenverlust klagten. 1000 Artikel gescannt, aber am Ende nur rund 800 neue Artikel in der Datenbank und solche Späße.
Des Rätsels Lösung, der ich erst auf die Schliche kam, als ich den Leuten mal beim Arbeiten zusah: Der Bediener hatte zwischendurch einen Artikel aus der Datenbank gelöscht und den Mauszeiger einfach auf dem "Löschen"-Button stehen gelassen ...
Da der Scanner am Ende CRLF sendete, was den Button "betätigte"(!) wurde mit jedem weiteren Scan daher ein weiterer Artikel aus der DB gelöscht!
Und die Leute haben es gar nicht bemerkt, sondern einfach "blind" weiter gescannt!
(Die Dialogbox "Löschen bestätigen" ist zuvor natürlich wegkonfiguriert worden, "weil die dauernd nervte"!)

4) Man berücksichtige den Fall, dass das, was vom Scanner kommt, nicht unbedingt EAN-13 ist.
Bei manchen Artikeln kommen auch (zumeist) kürzere, oder (seltener) längere Barcodes zum Einsatz.
Das empfangende Programm darf dann nicht stur auf eine bestimmte Zeichenzahl eingestellt sein.

Erst wenn all das überprüft wurde, kann man sich gezielt ans Programmieren machen, andernfalls erlebt man womöglich immer wieder tolle Überraschungen.