Debugger für AutoIt3 - sinnfrei oder sinnvoll?

  • Ein Debugger in einer IDE für eine Programmiersprache. :/ Vor etlichen Jahren hatte ich mit Delphi 7 (oder so) angefangen. Die IDE bestand standardmäßig aus "fliegenen Fenstern". Von einer IDE mit MDI-Fenster war alles noch weit entfernt und es gab keinen richtigen Debugger. Man konnte sich selbst was basteln, das in ein DOS-ähnliches Fenster ein paar Informationen schrieb. Selbst das uralte Visual Basic hatte alles schon an Ort und Stelle.


    Heute ist das bei den meisten Sprachen Standard in der IDE. Warum sollte man das bei AutoIt nicht auch einen Debugger anstreben?


    Wikipedia beschreibt einen Debugger als

    Zitat

    Ein Debugger ... ist ein Werkzeug zum Diagnostizieren und Auffinden von Fehlern in Computersystemen, dabei vor allem in Programmen, aber auch in der für die Ausführung benötigten Hardware.

    Nun ist schon des öfteren von BugFix als sinnfrei bezeichnet worden, für AutoIt einen Debugger zu erstellen, oder zu benutzen. Es gibt nur einen BugFix, aber mehrere User sind da anderer Meinung und würden sich über einen Debugger freuen.


    Im Moment weiß ich noch nicht so genau, wo dieser Thread hinführen soll. Es kann gerne diskutiert werden, ob ein Debugger für Autoit sinnvoll ist, ob er überhaupt möglich ist, und und und.


    Der Thread kann auch als Anregung dienen, einen Debugger zu realisieren/entwickeln. Ich würde gerne meine Unterstützung anbieten, um einen Debugger in meinem PSPad4AutoIt3 Projekt aufzunehmen. Mein Favorit ist DBUG (Another debugger for AutoIt). DBUG liegt als Au3-Script vor und lässt sich einfach in ein anderes Script einfügen, das debugt werden soll. DBUG zeigt es ein mir aus anderen IDEs bekanntes Verhalten, mit Stip-Into, Step-over, run to cursor, Haltepunkten werden angezeigt uvm. Zudem hat es schon ohne Anpassungen eine Teilfunktionalität in PSPad. Das könnte ein guter Ansatz sein.


    Da ich im Moment mit der Erstellung eines CallTipViewers für PSPad4AutoIt3 ausgelastet bin, kann ich noch keine Ressourcen für einen Debugger abgeben. Aber wenn sich andere Interessierte finden, dann wird das schon was. :)


    Bernd.

  • Nun ist schon des öfteren von BugFix als sinnfrei bezeichnet worden, für AutoIt einen Debugger zu erstellen, oder zu benutzen.

    :rofl:


    Ein funktionierender Debugger kann durchaus hilfreich sein (auch wenn ich ihn in meinen 14 Jahren mit AutoIt nie wirklich vermisst habe). Meine Ablehnung bezog sich ganz speziell auf den/die existierenden Produkte.

  • Das, was man von einem Debugger sonst so geliefert bekommt, ist in AutoIt aufgrund der Sprache von vornherein ausgeschlossen: z.B. Prüfen auf Typunverträglichkeit Diese Fehler kann man in AutoIt nicht aufdecken durch den allmächtigen Datentyp "variant".

    Das würde ich so nicht unterschreiben, auch in AutoIt ist ein Datentyp zum Debuggen von Vorteil. Ich erinnere mich da an ein eher ekelhaftes Problem, bei dem _GUICtrlListView_GetSelectedIndices mit _GUICtrlListView_GetItemText nicht funktionieren wollte, da der Rückgabewert ein String war.

    Trotz LVS_SINGLESEL hat er den String nicht als Zahl interpretiert, und da hilft es einfach zu wissen welcher Datentyp da reinkommt. Schadet doch nicht?


    Aber einen Debugger bräuchte ich in AutoIt auch nicht. Ich lese mittlerweile auch gar nicht mal mehr die Konsolenzeilen wenn Fehler aufpoppen, ich gehe in die Zeile und sehe den Fehler meistens direkt selber.
    Ansonsten bin ich ein großer Anhänger von dieser Debugvariante :D

  • Ein funktionierender Debugger kann durchaus hilfreich sein (auch wenn ich ihn in meinen 14 Jahren mit AutoIt nie wirklich vermisst habe).

    Ich programmiere jetzt so ca, 14 Jahre in AutoIt, aber einen Debugger habe ich nie gebraucht/vermisst. Die Consolenausgabe reicht mir

    Das geht mir, offen gesagt, ähnlich !

    Auch ich habe einen Debugger in den vergangenen Jahren nicht wirklich vermisst.

    Ich verwende ConsoleWrites und/oder das Schreiben in LOG-Dateien. Diese Operationen werden über ein globales Flag $DEVMODEON (Boolean) nach Bedarf aktiviert/deaktiviert. Das mag geringe negative Auswirkungen auf die Laufzeit haben, ist mir bei einer Skriptsprache aber egal.


    Die technische Frage, also ob ein Debugger überhaupt realisierbar ist und wenn ja, in welcher Tiefe, lasse ich mal weg. Wie BugFix bereits schrieb, würde ein Debugger bei AutoIt architekturbedingt eh nicht den Leistungsumfang erreichen (können), wie bei einer Compilersprache.


    Die für mich wesentlicheren Fragen lauten :

    • wieviele 'Standard-'User würden einen solchen Debugger überhaupt einsetzen
    • lohnt sich der Aufwand einen Debugger (light) zu erstellen, oder gibt es nicht ggf. andere Problembereiche, in denen diese Zeit besser verwendet wäre
    • wer soll das umsetzen und vor allem langfristig pflegen. Die Foren (DE/EN) sind voll von interessanten Projekten, die beim Stand von 60% -70% im Sande verlaufen sind. Dann ist die anfängliche Begeisterung aufgebraucht und es beginnt üblicherweise die Phase der Quälerei ;)

    Ich denke, ein aktuelles Tutorial "wie debugge ich richtig" (gibt es z.T. wohl bereits schon), ergänzt um einige elegante Ausgabefunktionen (schöne Formatierung usw.), würde den meisten Usern ebenso helfen. Wenn ich mir insbesondere Einsteigerfragen durchlese (DE/EN) dann stelle ich fest, dass viele noch nicht einmal ConsoleWrite und StringFormat kennen, sondern nur mit MsgBoxen arbeiten.


    Gruß Musashi

    86598-musashi-c64-png

    "Am Anfang wurde das Universum erschaffen. Das machte viele Leute sehr wütend und wurde allenthalben als Schritt in die falsche Richtung angesehen."

  • MsgBox hat gegenüber ConsoleWrite den Vorteil, dass das Script an der Stelle anhält.

    Hi BananaJoe !

    Ich wollte die MsgBox-Option auch keineswegs schlecht machen ;) - sie hat, an den richtigen Stellen, durchaus ihre Berechtigung. Mir ging es darum, dass erstaunlich viele User die Möglichkeiten der Konsolenausgabe / eines LOG-Files nicht kennen bzw. nicht nutzen. Bei z.B. der Prüfung von aktuellen Variablenwerten ist der massenhafte Stop des Skriptes ja häufig eher unerwünscht/nervig.


    Gruß Musashi

    86598-musashi-c64-png

    "Am Anfang wurde das Universum erschaffen. Das machte viele Leute sehr wütend und wurde allenthalben als Schritt in die falsche Richtung angesehen."

  • Meine Ablehnung bezog sich ganz speziell auf den/die existierenden Produkte.

    Das habe ich anders verstanden. Das folgende ist die Antwort auf dieses Posting von PSblnkd (Das Posting is recht ausführlich, deshalb zitiere ich es nicht hier.)

    Das ist für eine Interpretersprache nicht realisierbar. Es gibt Ansätze, da wird das Skript übersetzt in ein Laufzeitskript (z. B. alle Schleifendurchläufe werden als einzelne Befehlszeilen mit jeweiligen Werten in das Skript geschrieben).

    Kann ich mich nicht mit anfreunden. Es ist also kein Problem der IDE, sondern ein Problem der Spracharchitektur.

    Dann habe ich mich wohl geirrt. Für mich klang das eher als generelle Ablehnung gegen Debugger in AutoIt. ?(


    Ansonsten danke ich für alle Beiträge! :thumbup:


    Ich ziehe ein frühzeitiges Fazit: Die Debug-Möglichkeiten Console und MsgBox werden von euch als ausreichend angesehen. Der Bedarf eines dedizierten Debuggers ist sehr gering.


    Musashi hat eine super gute Zusammenfassung geschrieben. Der schließe ich mich an und denke, das Thema kommt in meiner ToDo-Liste ganz nach unten. :|


    Danke für eure Mitwirkung!


    Bernd.

  • Danke an Professor Bernd!

    DBUG (Another debugger for AutoIt ist noch so ein separater Debugger - so wie der von Steve Towner, der bei mir nicht läuft.

    Trotzdem werde ich mir den mal anschauen ...


    Warum bei AutoIt ein Debugger nicht sinnvoll sein kann - bzw. wie BugFix schreibt - bei der Skriptsprache AutoIt nicht gehen soll, will mir nicht einleuchten.

    VBA ist doch auch eine Skriptsprache - oder? - Und da gibt es die wunderbare IDE (Editor mit Syntax-Highlighting, integrierten Debugger mit verschiedenen Fenstern, Objekt-Browser (Verweise) u.v.a.m.), aber leider ohne Compiler, mit dem man aus dem Skript eine .exe machen kann, die dann auf allen (?) Windows-Rechnern läuft und das ohne jewede Bibliotheken oder Frameworks wie bei AutoIt. In RE: Hooking & DLL-Injection hatte ich einen ScreenShot von der IDE gepostet ...


    Für einfache Wert-Ausgaben von Variablen ist m.E. die Console zwar geeignet, aber - wie BananaJoe schon schrieb - mit einer MsgBox hält die Skriptabarbeitung an und das ist vielfach sehr nützlich! Beide Verfahren sind aber ungeeignet, wenn es sich um Objekt-Variablen handelt, deren innerer Aufbau oft sehr kompliziert ist. Siehe mein Problem mit einer Objekt-Rückgabe über COM, die bei AutoIt nicht richtig ankam ...


    @ BugFiX: Beim Schrittbetrieb (STEP) wird Zeile für Zeile interpretiert, d.h. es werden auch nur die davor liegenen Codezeilen mit einbezogen - die nachfolgenden noch nicht und bei Schleifen kann man dann sehr schön die Variablen-Veränderungen beobachten ...


    Warum sollte sich ein komfortabler Debugger nicht in SciTE integrieren lassen, wo es doch angeblich OpenSource ist?

    Momentan habe ich leider dazu keine Zeit ... weil mit Anderem beschäftigt -> RE: Hooking & DLL-Injection.

    Es würde mich sehr freuen, wenn demnächst SciTE mit integriertem Debugger zur Verfügung steht.


    Grüsse aus Berlin


    PSblnkd

  • Hi,


    ich hatte vor Äonen (imho 2009, also vor 11 (ELF!) Jahren^^) mal etwas zu diesem Thema verfasst:

    RE: Tutorial: Wie man Script-Fehler erfolgreich sucht/findet bzw. richtig debuggt



    Musashi hatte mich 2016 darauf hingewiesen, das der Link aus meiner Sig nicht mehr funktioniert.....hiermit (nach immerhin 3 Jahren^^) behoben. Danke für den Hinweis!8o

    //EDIT Ja leck! 13 Minuten zu spät:rofl:


    Btt:

    Ich benutze in "anderen" Script- und auch Compilersprachen zum Debugging (fast) ausschließlich Msgboxen. Neulich sollte ich ein mir bis dato unbekanntes Javascript debuggen, und hatte dazu den in Opera (meinem Browser) integrierten Debugger benutzt. Feine Sache das....

    Aber in AutoIt hätte ich die äquivalenten "Fehler" mit den hier benutzbaren Werkzeugen aus Scite ggf. schneller gefunden.


    Im Großen und Ganzen ist zu diesem Thema nur eins zu sagen: :rtfm:

    Ich zitiere mich aus dem o.g. Thread:

    Zitat
    Im Prinzip ist "Debugging" eine Erfahrungssache, sichtbar hier im Forum. 99% der hier mit "funktioniert nicht" geposteten Scripte sind durch simpelstes Debugging, wie im Startpost schon erwähnt, auch von Anfängern lös- und somit vermeidbar! Die "Cracks" machen definitiv nichts anderes, kaum jemand "fliegt die Lösung einfach so zu".

    Man muss es einfach machen!



    //EDIT Ich hatte für AssembleIt einen (32Bit-) Debugger geschrieben, so einen SCHEI** macht man nur ein Mal im Leben!

    Ich hatte mir schon mehrfach überlegt, diesen Debugger auf 64Bit-ASM auszubauen, aber mir fehlen einfach die geschätzten 20 Monate permanente Zeit dafür!

    Ich bin ja auch nur ein Hobby-Coder....vielleicht mal, wenn ich in Rente bin :Glaskugel:

  • Danke an Professor Bernd!

    Gern geschehen. :)


    DBUG (Another debugger for AutoIt ist noch so ein separater Debugger - so wie der von Steve Towner, der bei mir nicht läuft.

    Trotzdem werde ich mir den mal anschauen ...

    Nicht ganz. Während der AutoIt Debugger von Steve Towner ein eigenständiges Programm ist, in dem man ein Script öffnet, (anstatt z. B. in SciTE), integriert sich DBUG in dein Script. Wenn du dein Script startest, zeigt sich ein kleines Fensterchen und stellt die verschiedenen Step Anweisungen zur Verfügung.


    Ganz fasziniert bin ich davon, dass in SciTE Angaben zu Variablen als Tooltip erscheinen, wenn du mit der Maus drüber fährst. Fast wie in einem "richtigen" Debugger. Da muss man nicht mit zig MsgBoxen oder Consolenzeilen rumhantieren, die man dann später auch noch wieder löschen kann, sondern kriegt Infos zu allen verfügbaren Variablen. DBUG funktioniert sogar ansatzweise mit PSPad, aber ... nicht so richtig. Da wären Anpassungen notwendig, es ist halt für SciTE ausgelegt.


    Hier ein paar Screenshots. Wenn man mit der Maus über eine Array-Variable fährt, kann man im Tooltip viele Elemente eines Array auf eine Blick sehen. Wie viele MsgBoxes wären dafür wohl nötig? ;) Hinweis: Das schwarze Konsolenfenster ist zusätzlich, das kann man auch ausschalten.


       


    Bernd.

  • Ich hatte für AssembleIt einen (32Bit-) Debugger geschrieben, so einen SCHEI** macht man nur ein Mal im Leben!

    Das würde ich nicht sagen!

    Deinen Assembler-Debugger finde ich SEHR gut und in Assembler ist ein Debugger auch sehr hilfreich bzw. möchte ihn dort nicht missen wollen.

    Falls ich das nicht schonmal erwähnt hatte: Dafür (nochmal) ein großes DANKESCHÖN!

  • Professor Bernd (25.03.2020)

    Vielen Dank für Deine Ausführungen.

    (Zitat) "Ganz fasziniert bin ich davon, dass in SciTE Angaben zu Variablen als Tooltip erscheinen, wenn du mit der Maus drüber fährst."

    Wie und unter welchen Umständen soll das gehen? - Bei mir passiert gar nichts, wenn ich in SciTE mit der Mouse über eine Variable fahre ...

    oder erst mit integriertem "DBug" ?


    Ich habe mir jetzt die 1.10er Version vom ISN AutoIt Studio heruntergeladen - weil dort das Debug-Tool "DBug" integriert sein soll.

    Am 13.04.2020 hatte ich dazu in RE: ISN AutoIt Studio ein Statement geschrieben.

    Und auch im Forum vom ISN AutoIt Studio - https://www.isnetwork.at/forum/viewtopic.php?f=7&t=168 ...

    Christian hat jetzt geantwortet ... muss ich aber erst noch verarbeiten ... vielen Dank schon mal!


    Grüsse aus Berlin


    PSblnkd

  • Hat schon mal jemand das AutoIt-Tool "DBug" versucht?

    Wenn man im SciTE die Dbug.au3 läd und mit "Go" startet, kann man eine "schöne" GUI sehen.

    Nur leider leuchtet mir nicht ein, wie ich daraus in den Debug-Modus für eine z.B. "Test.au3" kommen kann.

    Wenn ich nach Beitext-Anweisung die Dbug.au3 in die Test.au3 includiere, und das Ganze dann wieder unter SciTE starte, kommt keine GUI mehr, sondern nur noch eine Fehlermeldung, dass die Datei Dbug_Test_tmp.au3 nicht erstellt werden konnte.

    Was soll man mit solcher lapidaren Fehlermeldung anfangen?


    Grüsse aus Berlin


    PSblnkd

  • Nun gibt es neuerdings eine andere Dbug.au3 -> _dbug.au3 mit 119KB statt

    34kB.

    Leider fehlt mir hier eine weitere Include-Datei: WinAPISysWin.au3. Eine

    Downloadquelle habe ich bislang nicht gefunden - nur, dass auch Andere auch

    danach suchen ...

    Möglicherweise liegt es an der AutoIt-Version. Ich arbeite immer noch mit

    3.3.4.0. Die neuste zu installieren ist vielleicht wegen WinXP nicht

    möglich - hatte ich mal in einem Forum-Beitrag gelesen.


    Grüsse aus Berlin


    PSblnkd

  • Leider fehlt mir hier eine weitere Include-Datei: WinAPISysWin.au3. Eine Downloadquelle habe ich bislang nicht gefunden - nur, dass auch Andere auch danach suchen ...

    Möglicherweise liegt es an der AutoIt-Version. Ich arbeite immer noch mit 3.3.4.0.

    WinAPISysWin.au3 gibt es erst ab AutoIt Version 3.3.14.3. Versuche mal WinAPI.au3 oder WinAPISys.au3 zu includen. Ob das mit der 3.3.4.0 überhaupt noch funktioniert : ???

    Gruß Musashi

    86598-musashi-c64-png

    "Am Anfang wurde das Universum erschaffen. Das machte viele Leute sehr wütend und wurde allenthalben als Schritt in die falsche Richtung angesehen."