Hallo zusammen,
ich arbeite im Moment viel mit COM-Ports und verwende gern die CommMG UDF, da z.B. die GUI beim Warten auf Daten nicht einfriert.
Setzt man das mittels WinAPI um:
$COMPort = "COM1"
$Input = _WinAPI_CreateFile($COMPort, 2, 2)Dann hängt die GUI (der Teil fehlt hier) während das Script auf Daten wartet (In diesem Beispiel setzt die Schleife die Daten Byte für Byte zusammen und wartet auf den Trenner "@CR"):
Do
_WinAPI_ReadFile($Input, DllStructGetPtr($tBuffer), 1, $nBytes)
$InStr &= BinaryToString(DllStructGetData($tBuffer, 1))
Until BinaryToString(DllStructGetData($tBuffer, 1)) = @CR
Folgenden Workaround habe ich dafür:
#include <CommMG.au3>
Local $PortSetError
$Port = "1"
$Baud = "9600"
$Datenbits = "8"
$Paritaet = "none"
$StopBits = "1"
$Flusssteuerung = "NONE"
RegWrite("HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\SERIALCOMM", "\Device\BthModem0", "REG_SZ", "COM" & $Port)
$PortOpen = _CommSetPort($Port, $PortSetError, $Baud, $Datenbits, $Paritaet, $StopBits, $Flusssteuerung)
ConsoleWrite($PortSetError & @LF)
If $PortOpen = 0 Then
MsgBox(48 + 65536, "Fehler", "Der Anschluss konnte nicht geöffnet werden." & @CRLF & "Das Programm wird beendet.")
Exit
EndIf
; Hier wartet das Script auf Daten, die GUI hängt hierbei jedoch nicht
Do
$InStr = _commGetLine(@CR, 20, 20000)
Until $InStr <> ''
Ich bin zufällig darauf gekommen, da ich feststellte, dass wenn man den COM-Port im Gerätemanager kurz ändert, CommMG doch eine Verbindung mit dem BT COM-Port herstellen kann.
Nach einem Neustart (oder wenn man BT aus- und wieder eingeschaltet hat) muss man das wieder machen.
Wenn man nun den Wert aus dem Script in die Registry schreibt, dann hat das genau den selben Effekt.
Den COM-Port sollte man natürlich an seine Bedürfnisse anpassen. Ggf. heißt der Wert auch nicht "\Device\BthModem0". Aber das kann man sich ja vorher in der Registry anschauen.
Man muss den COM Port auch nicht ändern. Einfaches "überschreiben" reicht. Es wird quasi der Selbe Wert in die Registry geschrieben, der ohnehin schon da ist.
Keine Ahnung warum das so ist, aber es funktioniert.
Die Verbindung mit dem COM-Port wird aufgebaut und das Script läuft dann sauber weiter, wenn auf Daten gewartet wird.
Bei _WinAPI_ReadFile geht nämlich nichts mehr, auch keine Hotkeys wenn keine Daten über den COM-Anschluss laufen, so lange bis die Schleife durch ist.
Anmerkung: Ohne Admin-Rechte klappt die Verbindung mit dem COM-Anschluss per CommMG bei mir nicht.