1. Dashboard
  2. Mitglieder
    1. Letzte Aktivitäten
    2. Benutzer online
    3. Team
    4. Mitgliedersuche
  3. Forenregeln
  4. Forum
    1. Unerledigte Themen
  • Anmelden
  • Registrieren
  • Suche
Alles
  • Alles
  • Artikel
  • Seiten
  • Forum
  • Erweiterte Suche
  1. AutoIt.de - Das deutschsprachige Forum.
  2. Mitglieder
  3. Crusoe

Beiträge von Crusoe

  • CommMG und Bluetooth COM-Ports

    • Crusoe
    • 28. Mai 2017 um 20:43

    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:

    AutoIt
    $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"):

    AutoIt
    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:

    AutoIt
    #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 <> ''
    Alles anzeigen


    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.

  • Select...EndSelect: Case-Fälle aus *.ini-Datei auslesen

    • Crusoe
    • 27. Mai 2017 um 21:42

    Vielen Dank an alle :)
    Ich hab es mit euren Beispielen hinbekommen.
    Ich versuche Mal chronologisch zu antworten:

    Zitat von autoiter

    [...]
    ich halte dein gegebenes Beispiel nicht für adäquat.


    So setze ich es aber im Moment um.
    "$InStr" ist der Wert, der (nach ein wenig AutoIt-Voodoo) von einem Barcodeleser über einen Bluetooth COM-Port kommt.
    Dieser wird in der Select...Case...EndSelect Schleife ausgewertet und bei einem Fund in die zuvor erstellte GUI übertragen.
    Es kann ja immer nur ein Wert (oder nichts) gefunden werden.
    Klappt wunderbar, ist nur leider ohne Quellcode nicht erweiterbar.
    Deshalb die Idee, die Case-Fälle aus einer *.ini-Datei zu laden, die bei Bedarf beliebig erweitert werden kann.

    Zitat von autoiter

    Bleibt nur die Frage wie sinnvoll das ist.. Hast du ein besseres Beispiel, dafür was du tun möchtest?

    Das auf biegen und brechen als Select...Case...EndSelect-Variante umsetzen zu wollen, ist natürlich nicht sinnvoll.
    Scheint aber die einzige Lösung zu sein, wenn man (wie ich) in diesem Fall nicht so viel Glück beim Denken hat und nicht auf die coole Idee mit der For...To...Step..Next Schleife kommt.
    Nein, ich habe kein besseres Beispiel, denn genau so habe ich das bisher umgesetzt.

    Zitat von alpines

    Deshalb das ExitLoop. Wenn es gefunden wurde springt er direkt raus.


    Ja, wenn man das erstmal geblickt hat, dann versteht sich das auch von selbst.
    Hat nur dieses Mal ein wenig gedauert :P

    Zitat von BugFix

    @Crusoe: Ich denke, das Problem liegt darin, dass du dich gedanklich auf ein Select-Case als Lösung eingeschossen hast. Aber letztlich ist die Iteration durch ein Array doch gar nichts Anderes. In jedem Schritt wird ein "Case" abgearbeitet, trifft der Fall zu, wird die erforderliche Aktion ausgeführt, wenn nicht, gehts weiter. ;)


    Das hast du richtig erkannt. Ich kannte keine andere Methode und wollte es dann eben so umsetzen. War rückblickend totaler Quatsch X/
    Aber @alpines Lösungsvorschlag war wirklich eine super Idee :thumbup:

    Spoiler anzeigen

    OT: Kannst du was mit "Calbe" anfangen? :D


    Und weil ich jedes Mal platzen könnte, wenn ich am Ende eines Threads lese: "Danke, hat funktioniert." und die Lösung nicht dabei steht, hier meine Umsetzung:

    Wie gesagt, "$InStr" kommt nach etwas AutoIt-Voodoo aus einem Barcodeleser über einen BT COM-Port.

    Das Array wird so aufgesetzt:

    AutoIt
    $aTest = IniReadSection("Test.ini", "Test")


    Der Inhalt der "Test.ini" sieht so aus:

    Code
    [...]
    
    
    ##################################################
    # Test
    ##################################################
    [Test]
    AT0001=Beispiel 1
    AT0002=Beispiel 2
    AT0003=Beispiel 3
    
    
    [...]
    Alles anzeigen


    Und so schaut der AutoIt-Code zur Auswertung des Arrays aus (Ich habe den Vorschlag von @alpines ein wenig an meine Bedürfnisse angepasst):

    AutoIt
    For $i = 0 To UBound($aTest) - 1
       If $InStr = $aTest[$i][0] Then
          GUICtrlSetData($ArbTyp, $aTest[$i][1])
          DllStructSetData($tBuffer, 1, "")
          ExitLoop
       ElseIf $i = UBound($aTest) - 1 Then
          MsgBox(48 + 262144, "Fehler", "Der Eintrag wurde nicht gefunden." & @CRLF & "Bitte Test.ini prüfen.")
       EndIf
    Next


    Nochmals vielen Dank an alle :thumbup:
    Ohne euch hätte ich da sicher wieder ewig dran gesessen X/
    Ich war Mal so frei und habe einen Zehner in die Kaffeekasse geworfen... Ich hoffe das ist ok ^^

  • Select...EndSelect: Case-Fälle aus *.ini-Datei auslesen

    • Crusoe
    • 26. Mai 2017 um 00:02

    Ich bin mir nicht sicher, ob ich mein Vorhaben richtig geschildert habe.

    Ich möchte meine Select...EndSelect Einträge flexibel mit dem Inhalt der *.ini-Datei füllen.

    Vielleicht verstehe ich deinen Lösungsvorschlag falsch, aber würde dabei nicht nur das Array ausgelesen und hintereinander 3x ein anderer Wert in die GUI mittels "GUICtrlSetData($ArbTyp, $aTest[$i][1])" eingetragen?

    Ich möchte ja, dass einfach nur mehr Case-Einträge in meinen Select...EndSelect Abschnitt kommen.
    Ist das überhaupt möglich, die Auswahl nach dem compilieren zu erhöhen?

    Als Alternative kann ich die Case-Fälle natürlich vordefinieren (z.B. 20 Case Fälle) und die mit leeren Einträgen in der *ini-Datei verbinden und wenn sie benötigt werden, dass kann man "InStr[x]" "ArbTyp[x]" einfach ausfüllen
    Aber ich denke, dass wäre nicht so elegant.

  • Select...EndSelect: Case-Fälle aus *.ini-Datei auslesen

    • Crusoe
    • 25. Mai 2017 um 23:27

    Hallo alpines,

    danke für deine schnelle Hilfe :)
    Die Funktion IniReadSection habe ich schon gefunden.
    Was meinst du mit "[...] führst du eine Aktion aus, auch basierend auf einem Array."?

  • Select...EndSelect: Case-Fälle aus *.ini-Datei auslesen

    • Crusoe
    • 25. Mai 2017 um 23:19

    Hallo zusammen :)

    Ich habe Mal wieder ein kleines Anliegen.
    Zuerst ein Code-Schnipsel:

    AutoIt
    Select
    
    
        Case $InStr = "AT0001"
           GUICtrlSetData($ArbTyp, "Beispiel 1")
           DllStructSetData($tBuffer, 1, "")
        Case $InStr = "AT0002"
           GUICtrlSetData($ArbTyp, "Beispiel 2")
           DllStructSetData($tBuffer, 1, "")
        Case $InStr = "AT0003"
           GUICtrlSetData($ArbTyp, "Beispiel 3")
           DllStructSetData($tBuffer, 1, "")
    
    
    EndSelect
    Alles anzeigen

    Nun möchte ich per *.ini-Datei weitere "Case"-Fälle hinzufügen, bzw. die ersten neun Case Fälle können auch daraus erstellt werden.
    So soll das in der *.ini-Datei aussehen:

    Code
    [CaseFaelle]
    InStr1=AT0001
    ArbTyp1=Beispiel 1
    InStr2=AT0002
    ArbTyp2=Beispiel 2
    InStr3=AT0003
    ArbTyp3=Beispiel 3

    Wie könnte man das anstellen?
    Vielleicht per While...WEnd Schleife, welche die Anzahl der *.ini Einträge ausließt und aus deren Daten die "Case"-Liste erstellt?

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

    • Crusoe
    • 14. Mai 2017 um 17:25
    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 :huh:

    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).

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

    • Crusoe
    • 14. Mai 2017 um 16:36

    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.

    AutoIt
    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
    Alles anzeigen

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


    AutoIt
    ### [...] ###
    
    
    _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 :thumbup:

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

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

    • Crusoe
    • 14. Mai 2017 um 12:09

    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

  • Oberfläche auf Veränderung prüfen

    • Crusoe
    • 13. Mai 2017 um 22:36

    Hm...
    Ich habe die "ImageSearch.au3" Datei nicht.
    Ich habe nur Links gefunden, bei denen ich mich erst irgendwo registrieren muss.
    Da soll es auch noch ein DLL dazu geben.
    Kannst du beides Mal hochladen? Am besten in einer *.zip oder *.rar Datei.
    Ich könnte mir vorstellen, dass nackte *.dll Dateien nicht hochgeladen werden können.

    Ich habe zwar eine "ImageSearch.au3" im Netz gefunden, die scheint aber fehlerbehaftet zu sein.

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

    • Crusoe
    • 13. Mai 2017 um 22:14

    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.

  • Oberfläche auf Veränderung prüfen

    • Crusoe
    • 13. Mai 2017 um 21:32

    Hi *wudu*,

    bitte setze deinen Code in das entsprechende Fenster (Siehe Bild im Anhang), dann kann man den besser lesen ;)

    Versuch es Mal damit:

    AutoIt
    #include 'ImageSearch.au3'
    #include <MsgBoxConstants.au3>
    
    
    While -1
      $checksum = PixelChecksum(7,515,39,530)
    
    
      While $checksum = PixelChecksum(7,515,39,530)
        Sleep(100)
      WEnd
    
    
      MsgBox($MB_SETFOREGROUND, "Achtung", "Es hat sich was geändert!")
    
    
      Dim $x = 1, $y = 1
    
    
      _ImageSearch(@ScriptDir & "\suche.jpg", 1,$x, $y, 70)
      if $x = 1 Then Exit
      MsgBox(64, 'Vorsicht', 'Aufpassen' )
    
    
      Sleep(200)
    
    
    WEnd
    Alles anzeigen

    "While -1" und das "WEnd" am Ende sorgen dafür, dass die Schleife ewig läuft.
    Das ist natürlich mit Vorsicht zu genießen.
    Du solltest dann ggf. die Funktion "HotKeySet" benutzen, damit du das Programm schnell beenden kannst, ohne das TrayIcon benutzen zu müssen.

    Dateien

    Bildschirmfoto 2017-05-13 um 21.30.18.png 47,27 kB – 0 Downloads
  • _WinAPI_CreateFile / DllStructCreate: Wie groß muss der Puffer sein?

    • Crusoe
    • 13. Mai 2017 um 13:55

    Hi Bitnugger,

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

    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 :thumbup:

  • Oberfläche auf Veränderung prüfen

    • Crusoe
    • 13. Mai 2017 um 11:23

    Hallo :)
    Hast du die Mal die Funktion PixelSearch angeschaut?
    Viel hast du ja nicht verraten.
    Ich vermute, dass die Änderung die du suchst auch mit einer Farbänderung einhergeht.

    Wenn es ein Text ist, der irgendwann erscheint (so richtiger Text, kein Bild mit einer Aufschrift), kannst du auch mit WinExists experimentieren.

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

    • Crusoe
    • 13. Mai 2017 um 02:18

    Hallo zusammen :)

    Vielen Dank für die rege Anteilnahme an meinem Problem :thumbdown:

    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.

    AutoIt
    ; 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)
    
    
    ### [...] ###
    Alles anzeigen
  • _WinAPI_CreateFile / DllStructCreate: Wie groß muss der Puffer sein?

    • Crusoe
    • 11. Mai 2017 um 00:41

    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:

    AutoIt
    ; Ö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]")
    Alles anzeigen

    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.

  • IniReadSection Ausgabe in String umwandeln

    • Crusoe
    • 12. November 2011 um 14:11

    Hi Micha_he,

    es steht tatsächlich auch unter "Number" (wer hätte es gedacht) in der Hilfe, da gibt es auch "String" was man benutzen könnte (aber nicht in meinem Fall).
    Leider steht es nicht mit IniReadSection() in Verbindung und ich kam auch nicht auf die Idee nach soetwas speziellem zu suchen ^^
    Wieder etwas dazu gelernt... :)

  • IniReadSection Ausgabe in String umwandeln

    • Crusoe
    • 12. November 2011 um 11:57
    Zitat von Micha_he


    Versuch es mal mit Number($Start[1][1]), um sicher zu stellen, das es sich um einen numerischen Wert handelt.


    Hallo Micha_he,

    da fällt man doch vom Glauben ab... 8|
    Das funktioniert tatsächlich 8o
    Vielen vielen Dank!!!
    Wo steht denn sowas? Ich habe bestimmt Stunde die Hilfe bemüht und im Internet gesucht 8|
    Naja, der Trick ist eben, dass man weiß wo es steht :P

    @Fabi

    Hallo Fabi,

    leider funktioniert dein Vorschlag nicht, es kommt genau der selbe Felher wie bei meinem eigenen Script --> _FFStart ==> Invalid data type: (PORT) $iPort: 4243
    Aber auch dir vielen Dank für deine Mühen, das ist ja in Foren nicht selbstverständlich :)
    Das ist ja unglaublich, dass es bei einem MacBook keine eckigen Klammern gibt?! 8| Hier hast du ein paar auf Vorrat [[[[[[[[[[[[[[[[[[[[[[[[[[[[[[ ]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]] :rofl:
    (Ist nur ein Scherz, ich hatte nämlich vor, mir eins zuzulegen, aber wenn es da sowas nicht gibt, sitze ich beim programmieren ein bisschen auf dem Trockenen 8| )


    Viele Grüße und ein schönes Wochenende
    Crusoe :)

  • IniReadSection Ausgabe in String umwandeln

    • Crusoe
    • 12. November 2011 um 10:59

    Hallo liebe Community,

    ich habe folgendes vor:

    Der Firefox soll aus einem Befehl aus einem Script heraus gestartet werden (funktioniert).
    Nun soll eine *.ini Datei spezielle Werte in diesen Befehl einfügen (funktioniert zum Teil).

    [autoit]


    #include <FF.au3>
    #include <String.au3>
    #include <Array.au3>
    #include <File.au3>
    #include <Misc.au3>
    _Singleton(@ScriptName,0)

    [/autoit][autoit][/autoit][autoit]

    $Start = IniReadSection("Firefox.ini", "Firefox-Port")

    [/autoit][autoit][/autoit][autoit]

    ;Inhalt der *.ini Datei:
    ;[Firefox-Port]
    ;Profil 1=4243

    [/autoit][autoit][/autoit][autoit]

    MsgBox(0,"Test", "Profil: " & $Start[1][0] & " Port: " & $Start[1][1])

    [/autoit][autoit][/autoit][autoit]

    ;Text der Messagebox: "Profil: Profil 1 Port: 4243"

    [/autoit][autoit][/autoit][autoit]

    _FFStart("http://www.google.de/", $Start[1][0], 2+8, False, "127.0.0.1", $Start[1][1])

    [/autoit][autoit][/autoit][autoit]

    ;Ausgabe Debug: _FFStart ==> Invalid data type: (PORT) $iPort: 4243

    [/autoit]

    Der Hammer ist: Wenn ich anstatt "$Start[1][1]", "4243" (ohne "", die dürfen da nicht sein, in FF.au3 sind die auch nicht) eingebe, dann geht es.

    Wenn ich:

    [autoit]


    #include <FF.au3>
    #include <String.au3>
    #include <Array.au3>
    #include <File.au3>
    #include <Misc.au3>
    _Singleton(@ScriptName,0)

    [/autoit][autoit][/autoit][autoit]

    $Start = IniReadSection("Firefox.ini", "Firefox-Port")
    ;MsgBox(0,"Test", "Profil: " & $Start[1][0] & " Port: " & $Start[1][1])

    [/autoit][autoit][/autoit][autoit]

    $Port = 4243
    _FFStart("http://www.google.de/", $Start[1][0], 2+8, False, "127.0.0.1", $Port)

    [/autoit]

    benutze, geht es auch...
    Es soll aber zwingend über diese *.ini Datei laufen.
    Die vielen includes am Anfang sind alle wichtig, da dies hier nur der Anfang des Scriptes ist.

    Ich hoffe, dass jemand von euch das Problem erkennt. Ich habe irgendwie schwer Tomaten auf den Augen, glaube ich 8|

    "_ArrayToString" habe ich schon probiert, das kann aber das Array was durch "IniReadSection" erstellt wurde nicht auslesen. Vermutlich weil es ein 2-dimensionales Array ist. Die Beispiele dazu sind alle 1-dimensional... :(

    Vielen Dank schonmal :)

    Gruß
    Crusoe

  • Aktion ausführen beim beenden eines Skriptes (FF.au3, MozRepl)

    • Crusoe
    • 24. August 2011 um 11:39

    Hallo misterspeed,

    eine kaputte Uhr geht eben auch zwei Mal am Tag richtig, was für ein Glück für mich :D
    Ja das wäre ja auch blöd, wenn jedes Profil sich die AddOns teilen müsste.
    Das wäre ja wie wenn ein Windows PC mit mehreren Konten nicht in Lage wäre, seinen Benutzern seperat Programme und Einstellungen anzubieten.
    Die Portable Version hat natürlich die von dir beschriebenen Vorteile und es hätte schon seinen Reiz, wenn ich das alles auf einen USB Stick packen könnte und dann an jedem beliebigen PC (Rechte vorrausgesetzt) ausführen könnte...
    Aber das ist mir im Moment zu viel Arbeit, da müsste ich jetzt fast 30 Programme umschreiben.
    Aktuell habe ich die ja auf die drei Profile verteilt und jedes Profil arbeitet diese gleichzeitig sequenziell ab.
    Ich bin total begeistert... Seit zwei Tagen kein einziger Fehler :D


    Gruß
    Crusoe

  • Aktion ausführen beim beenden eines Skriptes (FF.au3, MozRepl)

    • Crusoe
    • 24. August 2011 um 04:56

    Hallo zusammen,

    habe es jetzt hinbekommen und wollte es veröffentlichen, falls jemand ein ähnliches Problem haben sollte...
    Danke an misterspeed für den Tipp mit den mehreren Instanzen, nur mit dem mobilen FF hat es nicht ganz geklappt, bzw. es war dann nicht mehr nötig.
    So habe ich es nun gelöst:

    [autoit]

    _FFStart("http://www.autohe.de/", "Gruppe1", 2+8, False, "127.0.0.1", 4243)

    [/autoit][autoit]

    _FFStart("http://www.autoshe.de/", "Gruppe2", 2+8, False, "127.0.0.1", 4244)

    [/autoit][autoit]

    _FFStart("http://www.autoit.de/", "Gruppe3", 2+8, False, "127.0.0.1", 4245)

    [/autoit]


    Jetzt können alle drei Firefüchse gleichzeitig laufen, pfuschen sich nicht gegenseitig dazwischen und ich kann mit dem Profil "default" unabhängig surfen, da dieses ja auf den standard MozRepl Port 4242 hört.
    Quasi habe ich jetzt vier Profile im Firefox und jedes hat das MozRepl AddOn bekommen, welches jeweils auf einem anderen Port lauscht und so völlig unabhängig gesteuert und mit "_FFQuit" geschlossen wird :thumbup:

    Ja ich weiß, für euch Experten kein Problem, aber für mich ist es eine kleine Revolution :P
    Also nochmal ein dickes Dankeschön an misterspeed und Stilgar :thumbup:


    Gruß
    Crusoe

Spenden

Jeder Euro hilft uns, Euch zu helfen.

Download

AutoIt Tutorial
AutoIt Buch
Onlinehilfe
AutoIt Entwickler
  1. Datenschutzerklärung
  2. Impressum
  3. Shoutbox-Archiv
Community-Software: WoltLab Suite™