Beiträge von BugFix

  • Tv Steuerung

    Übrigens ist es gerade bei mehrdimensionalen Array eine Hilfe, wenn man die Indizes "sprechend" enumeriert, d.h. ihnen Variablennamen zuordnet, die leicht auf den Inhalt schließen lassen.

  • TextToSpeech - mal wieder eine Zeitansage: SayTheTime

    Vor laaanger Zeit hatten wir mal intensiv mit TextToSpeech gespielt. Dabei war übrigens dieses Skript entstanden.

    Das war mir jetzt in die Hände gefallen und ich habe es mal überarbeitet. Neben der Ausgabe der Zeit im offiziellen Modus sind 3 regionale Varianten wählbar. Variante 'A' (meine Heimat) ist schon etwas schräg und sicherlich für den einen oder anderen schwer verdaulich. :rofl:

    Skript und Bsp. sagen eigentlich alles notwendige.

    SayTheTime.au3
    Bsp.

  • Auswahl verarbeiten

    Auch wenn es inhaltlich absolut identisch ist, gefällt mir diese kurze Variante besser:

  • AutoItX - das unbekannte Wesen

    Zitat von Professor Bernd

    dass die Standard-Installation von AutoIt3 auch AutoItX installiert und es somit jeder auf seinem PC nutzen kann, wenn er AutoIt3 installiert hat.

    Ja, so ist es.

    Aber dran denken: AutoItX3.dll enthält ausschließlich die nativen AutoIt-Funktionen. UDF aus der Installation oder eigene Funktionen kannst du damit nicht ansprechen.

    AutoItX3 ist übrigens ganz praktisch, wenn man statt z.B. Excel aus einem AutoIt-Skript heraus zu manipulieren, AutoIt in die VBA-Umgebung einbindet und inside AutoIt verwendet (s. hier).

  • Ausgabe in DOS-Fenster umleiten

    Du kannst doch ein Skript mit GUI auch als cui Kompilieren. Dann klappt das mit der Ausgabe in die Windows-Shell.

    Folgendes Skript als cui kompiliert und aus der Windows-Shell gestartet:

    GUI_cui-compiled.PNG

  • Ausgabe in DOS-Fenster umleiten

    Zitat von Domi78

    dass es nicht möglich ist, mit ConsoleWrite() die Ausgabe auf die Eingabeaufforderung umzuleiten, ohne das Programm als DOS-Programm zu kompilieren.

    Ich verstehe den Hintergrund nicht. Möchte ich beim Ausführen einer *.au3 eine Konsolenausgabe, landet diese im Konsolenfenster des Editors, in dem die *.au3 geöffnet ist - das passt.

    Mir fällt eigentlich keine Situation ein, in der ich aus der Entwicklungsumgebung eine Ausgabe in die Windows-Konsole senden wollte. Vielleicht kannst du ja mal ein entsprechendes Szenario erklären?

  • Visual Studio Code & AutoIt

    Zitat von PixelStorm

    ich weiss nicht ob ich deinen Post richtig verstanden habe, aber bei mir funktioniert die Ausgabe von Array Variablen auch.

    Hast du leider missverstanden.

    Es geht um das Setzen des Cursors in die Variable und das Einfügen einer Debugzeile für diese Variable.

    Bsp.

    C++
    ; Pipe ist die Cursorposition
For $i = 0 To UBound($aTest) -1
    $a|Test[$i] = $aTest[$i] *2
Next

    Wenn ich jetzt den Shortcut für DebugToConsole ausführe sieht das bei VSCode so aus:

    C++
    For $i = 0 To UBound($aTest) -1
    $aTest[$i] = $aTest[$i] *2
    ;### Debug CONSOLE ↓↓↓
    ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $aTest = ' & $aTest & @CRLF & '>Error code: ' & @error & @CRLF)
Next

    Das ist natürlich falsch. Ich will ja den Wert des Arrays am Index $i ausgeben.

    Für SciTE habe ich diese Funktion umgeschrieben und bekomme für DebugToConsole folgenden Output:

    C++
    For $i = 0 To UBound($aTest) -1
    $aTest[$i] = $aTest[$i] *2
ConsoleWrite("@@_Debug_line" & @TAB & @TAB & @ScriptLineNumber & "   var: $aTest[" & $i & "] --> " & $aTest[$i] & @LF)
Next

; ich habe 3 Debugvarianten:
; - nur Wert (wie oben)
; - Wert & @error (ConsoleWrite("@@_Debug_line" & @TAB & @TAB & @ScriptLineNumber & "   var: $aTest[" & $i & "] --> " & $aTest[$i] & @LF & "!@ " & @TAB & "#Error: " & @error & @LF))
; - Wert & @error & @extended (ConsoleWrite("@@_Debug_line" & @TAB & @TAB & @ScriptLineNumber & "   var: $aTest[" & $i & "] --> " & $aTest[$i] & @LF & "!@ " & @TAB & "#Error: " & @error & @TAB & "#Extended: " & @extended & @LF))

    Meine Debugversion erfasst auch den Schleifenzähler allein ( also Cursor in $|i und dann Debugaufruf). Da wirft VSC einen Fehler.

  • Eingabe in Inputboxen in Großbuchstaben wandeln

    Zitat von Frank_S

    Ist aber extrem aufwändig und ich überlege aus diesem Grund, AutoIt schnell wieder den Rücken zu kehren und mir eine logischere Programmiersprache zu suchen.

    Das soll aufwändig sein? :rofl:

    Mit folgendem AutoIt-Code wird eine GUI mit Standardschaltflächen angezeigt und auf den Close-Button reagiert:

    C++
    GUICreate()
GUISetState()
Do
Until GUIGetMsg() = -3

    Nur 4 Zeilen!!

    Nun mach dasselbe mal in C / C++. Würde so aussehen:

    Soviel zum Thema Aufwand.

    "logischere" ? - Was ist das denn für eine Wortschöpfung? Entweder logisch oder unlogisch. Und Programmiersprachen können per se niemals unlogisch sein - nicht mal Brainfuck. :P

  • Eingabe in Inputboxen in Großbuchstaben wandeln

    Es geht NUR mit GuiRegisterMsg($WM_COMMAND, 'WM_COMMAND')!

    Du kannst nicht auf die GUIMsg(Inputfeld) reagieren. Das hatte ich doch schon in meinem ersten Beitrag geschrieben. Hast du mein Bsp. überhaupt getestet?

    Ich habe deinen Code mal angepasst (und etwas schlanker gemacht):

  • Eingabe in Inputboxen in Großbuchstaben wandeln

    Du registrierst die Message, wertest die Eingabe aus und schreibst (bei Bedarf) die korrigierte Eingabe zurück:


    EDIT:

    Ich hatte schon viel zu kompliziert gedacht. StringUpper reagiert ja sowieso nur auf Buchstaben, eine vorherige Prüfung ist also sinnlos.

    C++
    Func WM_COMMAND($hWnd, $iMsg, $iwParam, $ilParam)
    Local $iIDFrom = BitAND($iwParam, 0xFFFF)           ; Low Word
    If $iIDFrom <> $cInput Then Return $GUI_RUNDEFMSG   ; Msg kommt nicht von zu kontrollierendem Input
    Local $sRead = GUICtrlRead($iIDFrom)                ; Inhalt Input lesen
    If StringLen($sRead) = 0 Then Return $GUI_RUNDEFMSG ; Input ist leer
    GUICtrlSetData($iIDFrom, StringUpper($sRead))       ; Text zurückschreiben in Inputfeld
    Return $GUI_RUNDEFMSG
EndFunc  ;==>WM_COMMAND

  • Visual Studio Code & AutoIt

    Ich habe mal nachgeschaut, inzwischen gibt es eine AutoIt-Erweiterung von Damien, die soweit gut funktioniert.

    Was mir nach wie vor nicht gefällt: Die Debug-Ausgabe funktioniert nicht mit Array-Variablen und die Variablen müssen mindestens 2 Zeichen lang sein (nach dem $) um erkannt zu werden.
    Vermutlich kann man zur Erkennung eine eigene Funktion schreiben (wie ich es für SciTE gemacht habe) - aber wie gesagt: JS ist echt nicht mein Ding.

  • Kreisausschnitt mittels _GDIPlus_ und PixelCheckSum

    Das führt zu einem falschen Ergebnis.

    Obwohl "6 / 2" ein Integerwert ist, wird dieser von der Hexfunktion nicht als solcher erkannt.

    Zitat

    Function Hex

    Numbers passed as non-integers (those with decimal separator or exponent) are processed as doubles.

    Das Ergebnis ist (auch aus Sicht der AutoItfunktion "IsInt") ein Integer, tatsächlich ergibt 6/2 aber nicht 3, sondern 3.0! Und das ist ein Double.

    Erst mit "Hex(Int($Zahl))" erhält man das erwartete Ergebnis.

    Und die Länge 1 ist völlig korrekt, Vornullen zählen nicht.

  • Visual Studio Code & AutoIt

    VSCode hat einen enormen Nachteil: Man kann nicht sauber in die Konsole debuggen!

    Bsp.-Code:

    C++
    ConsoleWrite('Let''s go!' & @LF)
For $i = 1 To 10 Step +1
  ConsoleWrite($i & @LF)
  Sleep(500)
Next
ConsoleWrite('Done!' & @LF)

    Output VSCode (falsch) - Ausgabe auch nicht während des Programmablaufs, sondern erst nach Beendigung:

    Let's go!
    1

    Output SciTE (richtig) - Ausgabe kontinuierlich bei jedem ConsoleWrite-Befehl:

    Let's go!

    1

    2

    3

    4

    5

    6

    7

    8

    9

    10

    Done!


    Um VSCode sinnvoll nutzen zu können, muss noch viel dran geschraubt werden (die Konsolenausgabe kann sicher auch realisiert werden). Ich hatte mal angefangen mein eigenes Package für AutoIt zu erstellen. Aber es war dann einfach zu viel, was mir fehlt (umfangreiche Events, wie in SciTE, auf die ich reagieren kann) - da habe ich es gelassen (und auch, weil ich mich mit JS nicht wirklich anfreunden kann :whistling:).

  • Item ID eines TreeView Items nach Suche per _GUICtrlTreeView_GetNext

    Die UDF sind da häufig sehr großzügig mit der Interpretation von ID und/oder Handle. 8o

    Was anfangs vermutlich als Komfortverhalten genutzt wurde (Funktion verlangt ein Handle - ID wird übergeben - Funktion holt sich Handle für diese ID und funktioniert ohne Fehlermeldung) sehe ich heute als Verleitung zu schlampiger Programmierung. ;)
    Wenn eine Funktion ein Handle braucht, sollte sie auch nichts anderes akzeptieren. Das würde auch viele funktionsinterne Abfragen und/oder Umwandlungsroutinen obsolet machen.

    Insofern ist es sinnvoll nicht nur die UDF einzubinden, sondern auch mal zu öffnen und sich die Funktionen detailliert anzuschauen.


    EDIT:

    Die Beispiele zur UDF sind leider total verwirrend.

    Funktionsbeschreibung:

    _GUICtrlTreeView_SelectItem ( $hWnd, $hItem [, $iFlag = 0] )

    $hItem - Handle to the item

    Im Bsp. dazu:

    Erstellung der Item mit nativer Funktion und speichern der ID:

    $aidItem[$x] = GUICtrlCreateTreeViewItem(StringFormat("[%02d] New Item", $x), $idTreeView)

    Übergen wird beim Aufruf die ID, obwohl die Beschreibung ein Handle verlangt!

    _GUICtrlTreeView_SelectItem($idTreeView, $aidItem[$iRand])

    Das zieht sich leider wie ein roter Faden durch einige Hilfebeispiele.

  • Item ID eines TreeView Items nach Suche per _GUICtrlTreeView_GetNext

    Nun, die Funktion _GUICtrlTreeView_AddChild ist, höflich formuliert, nicht unbedingt sinnvoll. Ich habe mir angewöhnt, TreeViewItem ausschliesslich mit ID = GUICtrlCreateTreeViewItem zu erstellen.

    Die ID speichere ich mit zugehörigem Handle ( hWnd = GUICtrlGetHandle(ID) ) in einem 2D-Array ( [[ID,hWnd], [ID,hWnd], ...] ), welches ich dann bei Bedarf durchsuche. So kannst du Handle und/oder ID jedes Item jederzeit nutzen.