_WinAPI_CreateFile / DllStructCreate: Wie groß muss der Puffer sein?

Hallo zusammen

Ich sitze seit Tagen an einem Problem.
Ich Habe einen Barcodeleser, dessen Ausgabe ich über den virtuellen Bluetooth-COM Port im SPP Modus auslesen möchte.
Leider kann CommMG.au3 / CommAPI.au3 nicht mit diesen virtuellen Bluetooth COM-Ports umgehen, mit einem USB -> COM Adpater jedoch schon.

Ich habe herausgefunden, dass man COM-Ports auch mittels "_WinAPI_CreateFile("COM5", 2, 2)" ansprechen kann.
Soweit so gut, das klappt auch zuverlässig mit den BT-COM Ports.

Aber: Wenn ich den Output des Barcodelesers auslesen will, dann muss ich ja diesen Befehl anwenden:

; Öffnet COM5
$Input = _WinAPI_CreateFile($COMPort, 2, 2)


; Setzt eine Art 10Byte großen Puffer, in dem sich wohl später die Daten befinden
$tBuffer = DllStructCreate("byte[10]")


; An dieser Stelle wartet das Scrpit, bis der Barcodeleser etwas übermittelt
_WinAPI_ReadFile($Input, DllStructGetPtr($tBuffer), 10, $nBytes)


; Das erste Zeichen (von links) brauche ich nicht, deshlab kürze ich es weg.
$instr = StringReplace(StringTrimLeft(BinaryToString(DllStructGetData($tBuffer, 1)), 1), @LF, '')


; Obligatorische Wartezeit
Sleep(250)


; Zeigt mir die korrekte eingelesene Barcode-Nummer an
MsgBox(0,"Output Barcodeleser", $instr)


; Wenn ich das nicht nachschiebe und der nächste Barcode hat weniger Zeichen, dann bleiben die letzten Zeichen übrig
; Beispiel: 1. Code: XXXXXXXX -> Ergebnis: XXXXXXXX, 2. Code: YYYYYY -> Ergebnis: YYYYYYXX
$tBuffer = DllStructCreate("byte[10]")

Nun kommt das kuriose:

Wenn ich "$tBuffer = DllStructCreate("byte[10]")" z.B. auf "$tBuffer = DllStructCreate("byte[20]")" setze und "_WinAPI_ReadFile($Input, DllStructGetPtr($tBuffer), 10, $nBytes)" auf "_WinAPI_ReadFile($Input, DllStructGetPtr($tBuffer), 20, $nBytes)" , dann muss ich 2x scannen, damit _WinAPI_ReadFile den Barcode verarbeitet und ausgibt. Dann habe ich aber auch meist beide eingescannte Codes in einer Ausgabe.

Muss ich diese "Puffergröße" immer nahe an den 100% "füllen", damit _Win_API_ReadFile greift?
Gibt es eine zuverlässigere Methode meinen BT-Com Port auszulesen?
Wenn ich einen Barcodeleser über USB -> COM anschließe und mit CommAPI.au3 / CommMG.au3 arbeite ist alles perfekt, aber da funktionieren (obwohl Ports aufgelistet werden) die BT-COM Ports nicht.

Hallo zusammen

Vielen Dank für die rege Anteilnahme an meinem Problem

Da ich es aber auch nicht leiden kann, wenn jemand irgendwann schreibt: "Danke, geht." und auf Nachfrage nicht mitteilt wie es nun bewerkstelligt wurde, hier meine Lösung zu o.g. Problem.

; Das sind alle includes die ich in meinem Programm brauche, von daher etwas mehr als für den Code-Schnipsel benötigt:


#include <Array.au3>
#include <Excel.au3>
#include <Process.au3>
#include <StaticConstants.au3>
#include <TrayConstants.au3>
#include <WinAPI.au3>
#include <WinAPIFiles.au3>
#include <WindowsConstants.au3>


### [...] ###


; Liest die Einstellungen aus "ComPort.ini" und öffnet den entsprechenden Anschluss
Func _SetPort()


Global $COMPort = IniRead("ComPort.ini", "COM", "Port", "COM1")


; Oft stimmen die Anschlussparameter nicht (bei mir immer fälschlicher Weise 1200baud und 7bit)
; Vielleicht mag mir jemand den coolen DllCall dazu verraten, so lange geht es auch so.
; Der MODE Befehl funktioniert bei mir nicht mit virtuellen Bluetooth COM-Ports, Gott sei Dank stimmten da immer die Einstellungen.
_RunDos("MODE " & $COMPort & ":9600,N,8,1,P")
Global $Input = _WinAPI_CreateFile($COMPort, 2, 2)
Global $tBuffer = DllStructCreate("char[20]")


EndFunc   ;==>SetPort


### [...] ###


; Erkennt eine Eingabe, wenn folgende Bedingungn erfüllt sind: Empfange Wert aus $Input, solange bis ein @CR erscheint.
	  Do


		_WinAPI_ReadFile($Input, DllStructGetPtr($tBuffer), 1, $nBytes)
		$instr = String($instr & BinaryToString(DllStructGetData($tBuffer, 1)))


	  Until BinaryToString(DllStructGetData($tBuffer, 1)) = @CR


	; Je nach Barcodeleser wird ein @CR und / oder ein @LF an den übermittelten String gehangen. Diese Zeichen stören bei mir die Suche im Array.
		$instr = StringReplace($instr, @CR, '', 0, 2)
		$instr = StringReplace($instr, @LF, '', 0, 2)


### [...] ###

Hi Bitnugger,

ja... Es ist eine bodenlose Frechheit, dass man hier niemanden zwischen 0:00 Uhr und 05:00 Uhr antrifft...
(Damit das auch richtig verstanden wird )

Vielen Dank für den Tipp
Ich kann deine Verbesserung zwar gerade im Kopf nicht nachvollziehen (soll jedoch nichts heißen), werde das aber später zu Hause ausprobieren und berichten

Hi Bitnugger,

ich habe deine Änderung mal umgesetzt.

Leider funktioniert das nicht so ganz.
Nach deiner Schleife wird "$instr" verwendet und danach geleert ($instr = "").

Soweit so gut.
Dann kommt deine Schleife erneut zum Einsatz und dann rennt sie mit einem leeren String durch.
Die Do Until Schleife scheint beim zweiten Mal nicht auf "_WinAPI_ReadFile($Input, DllStructGetPtr($tBuffer), 1, $nBytes)" zu warten, bis etwas eingescannt wird.

Das stimmt, beim zweiten Durchlauf kommen keine Daten mehr an.
Wenn ich deine Funktion richtig verstanden habe, dann soll sie ja "Do" ausführen bis $sRead nichts mehr beinhaltet.
Da du innerhalb der Do...Until Schleife schon meinen "Endmarker" (@CR) rausfilterst, geht die Schleife beim zweiten Mal natürlich direkt durch.
$sRead ist ja leer. Normalerweise wartet die Do...Until Schleife an der _WinAPI_ReadFile Funktion.
Ich habe allerdings noch nicht verstanden, warum sie das beim zweiten Mal nicht tut.

EDIT:
Ich habe versucht $sRead vorher (außerhalb Do...Until) einen Wert zu geben ($sRead = "Test") bevor es in die zweite Runde der Do..Until Schleife geht. Jedoch ohne Erfolg.
Geht einfach durch

Hallo Bitnugger,

ich arbeite an einem KEVin-Modus (KEVIn = Kontrolliert Eingehenden Versehentlichen Input-Modus) für mein Programm.
Von daher habe ich die Scanroutine ein wenig überarbeitet.

Func _ScanBarcode()


	  Dim $nBytes, $Inventarnummer, $SN
	  $InStr = ""


	  Do


		_WinAPI_ReadFile($Input, DllStructGetPtr($tBuffer), 1, $nBytes)
		$InStr = String($InStr & BinaryToString(DllStructGetData($tBuffer, 1)))


	  Until BinaryToString(DllStructGetData($tBuffer, 1)) = @CR


		$InStr = StringReplace($InStr, @CR, '', 0, 2)
		$InStr = StringReplace($InStr, @LF, '', 0, 2)




	  Select
		  Case StringIsDigit($InStr) And StringLen($InStr) = 6
			  GUICtrlSetData($Inventarnummer, $InStr)
		  Case StringIsAlNum($InStr) And StringLeft($InStr, 1) = "S"
			  $InStr = StringTrimLeft($InStr, 1)
			  GUICtrlSetData($SN, $InStr) ; Erstellt dann die Seriennummer für das Statusfenster.
			  MakeBarcode() ; Erstellt den Barcode
		  Case Else
			  MsgBox(48+65536, "Hinweis", "Der Barcode entspricht nicht dem vorgegeben Muster." & @CRLF & @CRLF & "                            Bitte erneut scannen.")
			  _ScanBarcode()
	  EndSelect




EndFunc ;==> _ScanBarcode

Ich muss nach wie vor zwei Barcodes einscannen.
Die Funktion wird bei erfolgreichem Durchlaufen erneut ausgeführt.
Das sieht im Programm dann so aus:

### [...] ###


_ScanBarcode
_ScanBarcode


### [...] ###

Zweck dieser Funktion:
Den eingescannten Barcode auswerten und der richtigen Variable zuordnen.

Möglichkeit 1 (Zeile 18): Wenn der Barcode nur aus Zahlen besteht (StringIsDigit) und 6 Stellen (StringLen($InStr) = 6) hat, dann ist es die Inventarnummer ($Inventarnummer)

Möglichkeit 2 (Zeile 20): Wenn der Barcode aus Zahlen und / oder Buchstaben besteht (StringIsAlNum) und mit einem S anfängt (StringLeft($InStr), 1), dann ist es die Seriennummer.

Möglichkeit 3 (Zeile 24):
Möglichkeit 1 & 2 traten nicht auf. Hier kommt die Kernfunktion des KEVin-Modus zum tragen. Es erscheint ein Hinweis und die Funktion wird neugestartet, solange bis beide Barcodes stimmen.
Die vielen Leerzeichen in der MsgBox-Funktion sind notwendig, sonst steht die zweite Zeile nicht mittig unter der ersten Zeile.

P.S. Den Barcodegenerator (MakeBarcode()) habe ich von andybiochem aus dem autoitscript-Forum abgekupfert und an meine Bedürfnisse angepasst.
Andy, du bist der Geilste

P.P.S. Namen und damit verknüpfte Klischees sind rein zufälliger Natur

Zitat von Bitnugger

AutoIt

$InStr = String($InStr & BinaryToString(DllStructGetData($tBuffer, 1)))

BinaryToString wandelt die Binärdaten doch bereits in einen String um... wieso also nochmals einen String in einen String konvertieren wollen?

Weil ich doof bin und mir es beim Umstellen früherer Funktionen nicht auffiel, dass es noch da ist

Zitat von Bitnugger

Meine zweite Frage hast du aber nicht beantwortet!

Das habe ich in "Möglichkeit 1" und "Möglichkeit 2" erläutert.
Oder ich habe dich falsch verstanden.

Dann probiere ich es nochmal:
Ein Barcode besteht nur aus Zahlen und besteht immer aus sechs Ziffern zzgl. der @CR Stelle am Ende.
Der andere Barcode besteht aus Zahlen und / oder Buchstaben und beginnt immer mit einem "S". Dieser Barcode ist bisher immer 8 Zeichen lang, zzgl. der @CR Stelle am Ende).