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

  • Hallo zusammen,


    in letzter Zeit häufen sich die "Mein Script funktioniert nicht! Warum?"-Threads hier im Forum (aber andere Foren habens da auch nicht besser^^).

    Teilweise stundenlang suchen die Scripter nach dem "Fehler" bevor sie dann entnervt das Script hier einstellen und meist schon nach einigen Minuten eine Lösungsmöglichkeit präsentiert bekommen.....

    Diese Lösung wird aber i.d.R. nicht einfach aus dem Hut gezaubert. Sicher gibt es Profis, die mit einem Blick erkennen, woran es hängt, aber in den allermeisten Fällen muss sich auch der Profi durch das Script hindurchwühlen um den Fehler einzugrenzen. Harte, meist überflüssige Arbeit, da die Scripter die Fehler oft selbst einfach finden könnten.


    Aber wie findet man nun diese Fehler "professionell"?

    Da die meisten wohl Scite als Editor verwenden, wollte ich die Verwendung der "Fehlersuchhilfen" innerhalb des Editors einmal kurz vorstellen. Ich gehe dabei von einer Vollinstallation von Scite aus.

    Unter dem Menüpunkt TOOLS finden sie sich, beispielsweise:Debug to MsgBox oder Debug to Console


    Ich behaupte jetzt, daß sich mit Hilfe dieser Funktionen 90% der Programmfehler/Probleme innerhalb kürzester Zeit finden und beheben lassen.

    Wie das denn? Nunja, in vielen Fällen handelt es sich bei den Problemen um fehlerhaften Umgang mit Variablen.

    Bsp: Ein Script erwartet in einer (Endlos-)Schleife einen bestimmten Variablen-Wert, der aber nie erreicht wird. Ergo läuft die Schleife immer weiter, das Script "hängt". Was für ein Glück gibts ein Forum, schnell das Script dort eingestellt und abgewartet! Irgendeiner wird den Fehler schon finden, während man selbst sich die Zeit im Chat vertreibt und fleissig den eigenen Hilfe-Thread "pusht". Allerdings könnte es auch früh morgens sein, niemand ist im Forum aktiv oder man hat selbst den Ehrgeiz den Fehler zu finden!


    Jetzt könnte Debug to Console ins Spiel kommen.

    Man setzt im Scite den Cursor auf die abzufragende Variable innerhalb der Schleife und drückt ALT+d.

    Scite fügt nun eine Zeile in das Script ein. Nach einem F5 um das Script zu starten wird nun jedes Mal, wenn das Script diese Zeile abarbeitet, der Variablenname und der Wert in die Console geschrieben. Alternativ bekommt man mit Debug to MsgBox diese Werte in.....einer Messagebox^^. Nebenbei erfährt man so, ob diese Schleife überhaupt aufgerufen wurde.

    Zur Not kann man sich die MsgBox auch mit dem timeout-Parameter einige Sekunden anzeigen lassen, um sie nicht immer von Hand zu bestätigen.

    Nach erfolgreicher Fehlersuche lassen sich die eingefügten Zeilen mit Debug Remove Lines wieder entfernen.


    Um abzufragen, ob eine Funktion überhaupt aufgerufen wurde, bietet sich in den Scite-Tools die Funktion Trace: Add Func Trace Lines an.

    Damit erfährt man durch eine Ausgabe in die Console, ob die Funktionen überhaupt aufgerufen wurden. Mit Hilfe der Informationen aus der Console und/oder den Msgboxen grenzt man nun immer weiter das Problem ein, irgendwann ist der Punkt erreicht, und man hat den Fehler lokalisiert.

    Aber wo kommt dieser "Fehler" her? Sehr wahrscheinlich ist ein fehlerhafter (oder falsch interpretierter) Rückgabewert eines AutoIt-Funktionsaufrufs oder eine "falsche" Variable schuld.


    Syntaxfehler werden glücklicherweise schon von Scite abgefangen. Falsch geschriebene Variablennamen finden sich, wenn man Opt('MustDeclareVars', 1)in sein Script einfügt.


    Im folgenden Beispiel erläutere ich die Vorgehensweise bei der Fehlersuche nach "falschen" Variablen- bzw. Funktionsrückgabewerten.


    Beispiel:

    Die Funktion MACHWAS() soll aufgerufen werden, wenn der Mauszeiger sich in einem bestimmten Bereich auf dem Bildschirm befindet, d.h. wenn die X-Koordinate der Mausposition größer als 100 ist. Dieser Bereich auf dem Bildschirm (die 100) wird aus einer Datei ausgelesen.

    Problem:

    Der Mauszeiger befindet sich an der "richtigen" Bildschirm-Position, aber die Funktion MACHWAS() wird nie aufgerufen! Das haben wir mit Trace: Add Func Trace Lines herausgefunden.

    Scriptausschnitt:

    $wert = filereadline("test.txt") ;Wert aus Datei auslesen (zahl in textdatei = 100)

    if mousegetpos() > $wert then machwas() ;wenn X-Koordinate der Mausposition>Wert dann machwas


    Dieses "Script" enthält mehrere Stolpersteine. :thumbup: Aber der Reihe nach....

    Generell sollte man nach jedem Funktionsaufruf mit dem @error den Fehlercode auswerten!

    Aus der Hilfe: Wenn eine Funktion das @error-Flag setzen kann, dann sollte man es immer überprüfen, bevor man einen Rückgabewert benutzt. Wenn @error nämlich einen Fehler anzeigt, dann ist der Rückgabewert generell undefiniert...

    Zuerst lassen wir uns mit einer MsgBox den @error anzeigen. Natürlich benutzt man normalerweise die Funktion Debug To MsgBox, aber ich verwende hier der Übersicht halber eine einfache MsgBox. Man kann so alles erforderliche anzeigen lassen.

    $wert = filereadline("test.txt") ;Wert aus Datei auslesen (zahl in textdatei = 100)

    msgbox(0,"filereadline","@error="&@error) ;@error ist 0 , lt Hilfe kein Fehler

    if mousegetpos() > $wert then machwas() ;wenn X-Koordinate der Mausposition>Wert dann machwas

    msgbox(0,"mousegetpos()","@error="&@error) ;@error ist 1, lt Hilfe kein Fehler, aber eigentlich sollte MACHWAS() aufgerufen werden!

    Beide Male ist kein Fehler innerhalb der Funktionen FileReadLine() bzw MouseGetPos() aufgetreten! Wieso diese Kontrolle nicht ins Script übernehmen?

    $wert = filereadline("test.txt") ;Wert aus Datei auslesen (zahl in textdatei = 100)

    if @error = -1 then msgbox(0,"Fehler in filereadline()","@error="&@error) ;wenn fehler, dann msgbox

    if mousegetpos() > $wert then machwas() ;wenn X-Koordinate der Mausposition>Wert dann machwas

    Ich lasse die Zeile "if @error=-1...." im weiteren Verlauf weg, um übersichtlich zu bleiben.

    Es ist kein Fehler beim Lesen der Datei aufgetreten. Die Funktion MACHWAS() wurde trotzdem nicht aufgerufen.

    Offensichtlich stimmt irgendetwas mit dem IF-Vergleich nicht. Wir schauen mit der Msgbox nach den Variablen.

    $wert = filereadline("test.txt") ;Wert aus Datei auslesen (zahl in textdatei = 100)

    msgbox(0,"wert=",$wert) ;als $wert wird 100 angezeigt, das stimmt!

    if mousegetpos() > $wert then machwas() ;wenn X-Koordinate der Mausposition>Wert dann machwas

    Fein, die Datei "test.txt" existiert und wird gelesen, die Messagebox zeigt 100, das klappt ja schon einmal.

    Also ist irgendetwas mit dem Rückgabewert von MouseGetPos() faul, also mal in Scite den Cursor auf den Funktionsnamen setzen, F1 drücken und in der HILFE nachlesen....

    Aha, in der Hilfe erfahren wir, MouseGetPos ohne Angabe einer Dimension gibt ein ARRAY zurück.

    Rückgabewerte: $array[0] = X-Koordinate (horizontal), $array[1] = Y-Koordinate (vertikal)

    Dieses Array (und auch sonst eigentlich alle bis zu zweidimensionalen Arrays) könnte man mit _arraydisplay() ausgeben, um nachzuprüfen, ob überhaupt die "richtigen" Werte, hier die Mauskoordinaten, ausgegeben werden.

    Damit man _arraydisplay() nutzen kann, muss eine #include-Datei ins Script eingebunden werden. In den Scite-Tools sorgt OrganizeIncludes für das Einbinden der passenden Include-Datei(en)!

    $wert = filereadline("test.txt") ;Wert aus Datei auslesen (zahl in textdatei = 100)

    msgbox(0,"wert=",$wert) ;wert ausgeben, es wird 100 ausgegeben, stimmt

    $array = mousegetpos() ;Koordinaten der Mausposition in array schreiben

    _arraydisplay($array) ; zeigt die X-koordinate und Y-Koordinate der Mausposition

    Nachdem die Msgbox bestätigt wurde, erscheint ein Fenster mit der Darstellung des Arrays mit den Mauskoordinaten X und Y. Diese Koordinaten erscheinen uns richtig.

    Wir wollten die X-Koordinate der Mausposition mit dem Wert in der Datei vergleichen, also gäbe es 2 Möglichkeiten das Script zu ändern: Laut der Hilfe ist die X-Koordinate der Mausposition sowohl in $array[0], als auch in mousegetpos(0) enhalten. Wir entscheiden uns für mousegetpos(0), übergeben diese aber einer weiteren Variablen $Maus_X, denn diese Variable ist wiederum (mit unserer geliebten Msgbox^^) überprüfbar! Um mal schnell ohne Deklaration am Scriptanfang eine temporäre Variable lokal zu verwenden, nutzt man den Befehl LOCAL.

    $wert = filereadline("test.txt") ;Wert aus Datei auslesen (zahl in textdatei = 100)

    msgbox(0,$wert) ;wert ausgeben, es wird 100 ausgegeben, stimmt

    Local $Maus_X = mousegetpos(0) ;X-Koordinaten der Mausposition in Variable schreiben

    msgbox(0,"maus_x=",$Maus_X) ;msgbox mit Maus_X =576 erscheint

    if $Maus_X > $wert then machwas() ;wenn Mausposition X>Wert dann machwas

    Hmmm, das funktioniert immer noch nicht, die Funktion MACHWAS() wird nicht aufgerufen! Die Mauskoordinate 576 ist doch größer als 100, die Messageboxen geben die Variablen doch aus, warum wird denn MACHWAS() trotzdem nicht ausgeführt?!

    Hilfe hilft...

    In der Hilfe zu FileReadLine() steht folgender Text: "Liest eine Zeile Text aus einer zuvor geöffneten Textdatei."

    Zeile Text, Zeile Text...na logo liest die Funktion eine Zeile Text! Die Msgbox zeigt, die Variable $wert hat doch den Wert 100!

    Grübel, grübel und studier.....

    AAAAAAHHHH, TEXT steht da, TEXT! Jetzt wirds langsam hell, TEXT heisst so viel wie STRING!

    Also gibt FileReadLine() einen STRING zurück, in der Variable $wert steht also ein String, in der IF-Abfrage mit der Mausposition wird aber eine Zahl(INTEGER) erwartet. Zwei unterschiedliche Datentypen vergleichen funktioniert nicht, also müssen wir aus dem STRING "100" die Zahl 100 machen:

    Die Funktion Number() hilft uns weiter und macht aus dem STRING "100" die Zahl 100.

    Ob die Datentypen nun übereinstimmen, kann man sich auch in der MsgBox anzeigen lassen! Die Funktion VarGetType() sollte man daher im Auge behalten und oft nutzen!

    $wert=filereadline("test.txt") ;Wert aus Datei auslesen (zahl in textdatei = 100)

    msgbox(0,"wert= "&$wert,vargettype(number($wert))) ;wert ausgeben, es wird 100 ausgegeben, stimmt

    Local $Maus_X=mousegetpos(0) ;X-Koordinaten der Mausposition in Variable schreiben

    msgbox(0,"maus_x= "&$Maus_X, vargettype($Maus_X)) ;msgbox mit Maus_X =576 erscheint

    if $Maus_X > number($wert) then machwas() ;wenn Mausposition X>Wert dann machwas

    TADAAAA, die Funktion MACHWAS() wird aufgerufen, sobald die X-Koordinate der Maus die 100 übersteigt, also könnte man nun die Messageboxen entfernen (ich kommentiere sie meist nur aus, man braucht sie ggf noch einmal^^), die @error-Abfrage einfügen und das Script kürzen indem man die Hilfsvariable $Maus_X eliminiert.:$wert=filereadline("test.txt") ;Wert aus Datei auslesen (zahl in textdatei = 100)

    if @error=-1 then msgbox(0,"Fehler in filereadline()","@error="&@error) ;wenn fehler, dann msgbox

    if mousegetpos(0) > number($wert) then machwas() ;wenn Mausposition X>Wert dann machwas


    Die von mir geschätzte Zeit für diese "Problemlösung" mit den vorgestellten Methoden ist ca. 5-10 Minuten für einen Anfänger! :rofl:


    Man kann natürlich den Datentyp (VarGetType()) oder die Errorabfrage auch in die Debug-MsgBox einfügen, dazu muß man die Datei "AutoItTools.lua" bearbeiten, ab Zeile 180 gehts dort zur Sache. Wer allerdings nicht weiß was er dort macht, sollte tunlichst die Finger davon lassen.


    Vielleicht habt ihr selbst eine Idee oder ein Tool, wie man das "Fehlerfinden" vereinfachen könnte?

    Immer her damit, damit die Fehlersuche demnächst etwas flotter vor sich geht!


    Also noch einmal zusammengefasst die Vorgehensweise bei der Fehlersuche:

    - Fehlerposition mit Debug to MsgBox , Debug to Console und/oder Trace: Add Func Trace Lines eingrenzen.

    - nach Funktionsaufrufen den @error nach Möglichkeit abfangen und auswerten

    - Variablen und deren Werte mit Debug to MsgBox und Debug to Console abfragen und prüfen

    - Datentypen der Variablen mit VarGetType() prüfen

    - Arrays mit _arraydisplay() anzeigen

    - die Hilfe nutzen und auch die Beispiele dort einmal ansehen bzw ausprobieren!


    ciao

    Andy

  • Hi Andy,


    suchst Du Hilfe oder möchtest Du Hilfestellung geben ?!?


    Bei letzterem gehört dieser Post in die FAQ.


    Du hast Recht, es ist ärgerlich und etwas enttäuschend, das AutoIt keinen richtigen Debugger zur Verfügung stellt, wäre für Jon und das Team ein Klacks, von daher ist es mir unverständlich, warum AutoIt keinen Script-Debugger oder wenigstens eine Schnittstelle bereitstellt.


    Das mit den Trace- und DebugTo... Funktionen ist schlecht implementiert, bei mehrzeiligen Funktionsaufrufen ( _) haut das alles nicht mehr hin, leider.


    Es gibt einen Debugger mit GUI, habe ich aber nie ausprobiert ...


    Ein vernünftiger Debugger oder wenigtens eine Schnittstelle dafür wären echt angebracht, denn manchmal weiß man nicht genau, ob es das eigene Script ist, welches einen Bug enthält, oder ob es ein Bug in AutoIt selbst ist, der einen nicht ruhig schlafen lässt ...



    Gruß
    Greenhorn

    »Wir beschließen etwas, stellen das dann in den Raum und warten einige Zeit ab, was passiert.
    Wenn es dann kein großes Geschrei gibt und keine Aufstände, weil die meisten gar nicht begreifen,
    was da beschlossen wurde, dann machen wir weiter - Schritt für Schritt, bis es kein Zurück mehr gibt.«
    (Jean-Claude Juncker)

  • fällt dem geneigten Leser auf:
    Die Unterschiede zwischen Andys Beitrag und vielen der **-Beiträge:
    -Andy hat in (geschätzten) 250 Zeilen weniger Rechtschreibfehler (Tendenz gegen eins..) als viele der ***-Beiträge in einem Wort /bzw. Buchstabenansammlung
    -Andy benutzt Groß- und Kleinschreibung
    -Andy benutzt Zeichensetzung
    -Andy gliedert seinen Text
    -Andy schreibt verständliche Texte in verständlicher Sprache


    Was könnten viele ***-Schreiber daraus lernen?




    Vielen Dank für diesen Beitrag, er sollte alle 3 Minuten gepusht werden, mit Lesepflicht vor dem Eröffnen eines neuen Threads.

  • Hallo,

    Zitat von Greenhorn

    suchst Du Hilfe oder möchtest Du Hilfestellung geben ?!?

    Da musste ich wirklich grinsen, denn daß bei so viel Text auch noch jemand zwischen den Zeilen liest, hätte ich nicht erwartet :thumbsup:
    Natürlich ist man etwas fassungslos, bei einer solch mächtigen Sprache wie AutoIt nur relativ einfache Debugging-Möglichkeiten zu finden. Im Programmierer-Jura vor ca. 200 Millionen Jahren (80er^^) hatten einfache Basic-Compiler ( nicht Interpreter! ) schon ausgefeilte Debugger. Trace und Tron und Ausgabe von Registerinhalten uswusf....
    Aber vielleicht haben wir ja den falschen Denkansatz? Bei einer "einfachen" Sprache, sollte man ggf auch "einfach" coden. Als damals meine Kumpels von den simplen Sprachen wie Basic, Pascal und Fortran auf eine "Hochsprache" wie C umstiegen und als allererstes bewiesen, daß man mit C wesentlich besseren unlesbaren Spaghetticode basteln konnte als je zuvor, bin ich nicht mit umgestiegen. Denn dort war man ohne "richtigen" Debugger völlig verloren, und das war mir den Aufwand nicht wert. C mit Abstrichen lesen schaffe ich noch teilweise, aber schreiben...never^^. Wenn Programmierer nach 3 Monaten ihren eigenen Code nicht mal ansatzweise erläutern können, nur weil "zufällig" die Kommentare gelöscht wurden, dann bekomme ich Angst! Außerdem bin ich kein Programmierer, sondern Handwerker :D Was mit Basic und Assembler nicht machbar ist, naja, das braucht man auch nicht dringend :rock:

    Zitat

    Es gibt einen Debugger mit GUI, habe ich aber nie ausprobiert ...

    Ich schon...du hast weniger Zeit verschwendet ;)

    Zitat von ortho-graf

    Was könnten viele ***-Schreiber daraus lernen?

    Können kann man schon, tuen tut man nicht 8o
    Ja, es ist wie überall, die es am nötigsten haben nutzen die Möglichkeiten am wenigsten. Sind aber auch immer die lautesten Schreier wenn etwas nicht funktioniert.

    Zitat

    hat weniger Rechtschreibfehler (Tendenz gegen eins..)

    Entschuldigung, aber der Editor für die Forenbeiträge hat keine Rechtschreibkorrektur :D Habe gegen Ende doch etwas Muffensausen bekommen, daß der Beitrag im Nulldevice landet statt auf dem Server. Das ist mir leider schon öfter passiert...

    Zitat von peethebee

    Ich habe das mal gepinnt

    Du kannst den Text auch um geschätzte 200 Zeilen kürzen und mit RTFM an den meisten Stellen ersetzen. Ich habe mich das nicht getraut :rolleyes:


    ciao
    Andy

  • Danke, Andy, für den konstruktiven Beitrag! :thumbsup:


    Oft sind es im Kern die "einfachen" Tipps und Hinweise, die einem das Leben auf Dauer bestimmt einfacher machen.
    Viele Programme haben solch einen Overhead an Funktionen, dass man "vor lauter Wald die Bäume nicht sieht" ... :huh:
    Da sind Deine (paar) Hinweise wirklich schon sehr hilfreich!
    Und Deine Vorgehens-Strategie ist auch verständlich und gut nachvollziehbar formuliert!


    Ein sinnvolles, hilfreiches "Tutorial", dass unbedingt an zentraler Stelle im Forum abgelegt werden sollte,
    als dass es in den Tiefen der Forum-Threads verschwinden wird.... ;(


    @ortho-graf
    Du sprichst mir aus der Seele :thumbup:


    wie würde andysbeitrag rüberkomen wen er denn textso geschribn hätte? häte mann dan auch würglich was davongehapt
    gut das es an höerer stele noch schbrachkompätente leute gipt die auch noch ausdrückn könn was sie eigntlic meinen un woher sie komen


    Ist schon immer wieder erstaunlich, wie ignorant viele der deutschen Sprache (in Schrift und Wort) gegenüber stehen.
    Wer einen Beitrag postet, der womöglich Stunden (oder gar Tage) später beantwortet werden wird,
    der könnte sich (wie schon so oft in diesem Forum von unterschiedlichen Leuten gefordert) ruhig 1 Minute mehr Zeit nehmen,
    um die meist kurzen Texte/Fragen wirklich lesbar in den Editor zu hacken ... X(
    Das erleichtert so Vieles und trägt mit Sicherheit zu einer schnelleren Lösung bei!


    Danke Euch beiden für diese "Klarstellungen" :thumbup:


    -Rasta-

  • ich würde mal vorschlagen diese hilfe von ANDY mit in die online-hilfe & offline-hilfe (zum download bereitgestellte hilfe) zur verfügung zu stellen.


    direkt unter die faq's ist doch dafür platz für: "Fehler selber finden". ;-)


    mal sehen was @peethebees dazu sagt / schreibt. ;-)

    ...... Lieben Gruß, ........
    ...........
    Alina ............

    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Ich habe die Deutsche Hilfe auf meinem PC und
    OrganizeIncludes ist beim Scripten mein bester
    Freund. Okay?

  • Leider treten einige Fehler nur auf bestimmten Systemen auf.


    Dann ist es aber meistens schon kompiliert und der Interpreter wirft etwas aus wie "Fehler in Zeile soundso".


    Die Zeilenangabe ist zumindest bei mir wegen der includes nicht hilfreich. Wie bekommt man also den Quelltext wie ihn der Compiler zusammenbaut
    damit man sich die Problemstelle ansehen kann?


    Den Tipp von hier: [ gelöst ] Quelltext in der Exe-Datei archivieren
    hab ich schon versucht, allerdings werden die includes da noch nicht aufgelöst.
    Der Quelltext sieht also genauso aus wie im Editor.


    Hat jemand eine Idee wie man dem Fehler auf die Spur kommt?

  • Zitat

    Dann ist es aber meistens schon kompiliert und der Interpreter wirft etwas aus wie "Fehler in Zeile soundso".

    soweit ich weiß, gibt der Interpreter bei einem compilierten Programm garkeine bzw -1 als fehlerhafte Zeile aus.


    /EDIT/ in der Version 3.3.4.0 werden mir nicht nachvollziehbare Zahlen angezeigt an Stelle der Zeilennummer.


    Das nützt dir somit auch nichts. Wenn du den Quellcode hast, dann kannst du auch (SciTe vorausgesetzt) mit CTRL+J direkt in die Funktionen der includierten Dateien hineinspringen, falls dort ein Fehler auftritt.


    Weiterhin kann ich nur immer wieder dringend raten, Fehler im Compilat erst garnicht erst entstehen zu lassen sondern (und das ist so gut wie bei ALLEN AutoIt-Funktionen so) den @error-code abzufragen. Bei Objekten gibts einen Errorhandler uswusf.
    Es gibt auch die Möglichkeit, im Code eine "sinnvolle" Ausgabe im Fehlerfall bei einem compilierten Script zu erzwingen. Beispielsweise: "Fehler im Modul XYZ" statt "Error in Line -1" , aber da kann man gleich auf @error testen.
    Nach der Funktion muss ich mal schauen...OnAutoItExitRegister()Damit könnte man die aktuell verwendete Funktion ausgeben, aber wie gesagt, genauso aufwendig wie die @error-Abfrage.

  • Wie bekommt man also den Quelltext wie ihn der Compiler zusammenbaut


    lad dir einfach hiermeinen Obfuscatorrunter, und stelle in Zeile 18ff. nur die Option $iEncryptIncludes auf True. Alles andere machst du False / kommentierst es aus.
    Danach musst du nur noch das #include <String.au3> am Anfang löschen (Das wird eingefügt, weil der Obfuscator eigentlich mit _StringEncrypt arbeitet.

  • Hm, Zugriff verweigert :(


    Naja muss den Versuch dann eh auf nächste Woche schieben.
    Werd dann nochmal rückmeldung geben


    Komisch, ist eigentlich nur ein Thread im "bösen" Forum. Ich häng die Datei mal hier an.

  • Komisch, ist eigentlich nur ein Thread im "bösen" Forum. Ich häng die Datei mal hier an.


    *lach*...
    Es kann sein, dass dort noch der Script-Bereich gesperrt ist, wenn man kein User ist ;)... Daran sollte das wohl liegen!


    LG

  • So als kurze Rückmeldung:
    Der Obfuscator hat bei mir leider nicht funktioniert. Hatte irgendwie probleme mit den includes.


    Der Fehler wurde durch einen wmi-Aufruf verursacht. Genauer gesagt scheinen sich die Namen in unterschiedlichen Windows Versionen mal zu ändern...
    Den genauen Code hab ich grad nciht da, kanns aber nachreichen falls gewünscht.

  • Hallo,


    ich bin nach wie vor auf der Suche nach einer Möglichkeit, meinen (teilweise länglichen) AutoIt-Code schmerzfrei zu debuggen. Weiter oben in diesem Thread wurde (vor einigen Jahren) eine händische Methode beschrieben, die auf jeden Fall für das Debugging kleiner und kleinster Programme geeignet ist, und die sicher heute noch Gültigkeit haben wird. Aber wie sieht es mit dem Debugging von großen Projekten aus? Ich lese ab und zu mal was von einem "AutoIt Debugger", der seit vielen Monaten in der Version 0.47.0 z.B. über heise.de erhältlich ist, dessen Homepage aber nicht besonders lebendig aussieht.


    - Hat damit schon jemand Erfahrungen gesammelt?
    - lohnt sich eine (zunächst aufwändig wirkende) Installation?
    - ist dieses Tool brauchbar? Mit welchen Einschränkungen?


    Danke.
    nnako

  • Hi,


    Debugging von "großen" Projekten (bei mir teilweise mehrere zehntausend Zeilen Code) funktioniert wie oben angegeben!
    Mittlerweile debugge ich zwangsweise auch Code von anderen in diversen Programmier/Scriptsprachen. Ohne deren explizite "Debugger".
    Die anderen Programmierer sind immer erstaunt, wie schnell jemand in "fremdem" Code Fehler findet.


    Was erwartest du? Ein Programm, welches du aufrufst und dass du parallel zu deinem Script laufen lässt, welches bei einem Berechnungsfehler ein Fenster öffnet "In Zeile 24761 wird ein nullbasiertes Array erst von vom Item 1 aus ausgelesen!" ?


    Debuggen/Fehler suchen läuft darauf hinaus den Fehler zu analysieren, dessen Ursache zu finden und diese zu beseitigen.
    Dazu muss man sich intensiv mit dem Code auseinandersetzen, diesen verstehen und die erwarteten Ergebnisse verifizieren.


    Aber zu deinen Fragen zum AutoIt-Debugger:
    Ich hatte diese Programme schon benutzt, allerdings waren die selbst massiv verbugged. Ich kann kein "Hilfsprogramm" brauchen, welches mich bei meiner Arbeit ausbremst. Debuggen ist eine Arbeit, für welche man hochkonzentriert sein muss. Da muss ein schnellstmöglich ein Ergebnis her, und nicht ein weiterer Grund sich aufzuregen....


    Meistens läuft es doch darauf hinaus, fehlerhafte Berechnungen finden zu müssen. Da ist die schrittweise Ausgabe von Variablen zur Überprüfung imho der schnellste/einfachste Weg!
    Ein Fehler, welcher schon vom Compiler/Interpreter geworfen wird ist doch der Traum! Da muss man sich um die Lokalisation keinerlei Gedanken mehr machen!


    Beschreibe deine Fehler, ggf. kann dir jemand konkrete Tips zum "debuggen" geben!

  • Die besten Mittel in Autoit Fehler zu finden sind ConsoleWrite, MsgBox und _arraydisplay. Da einfach mehrere Stellen raussuchen und immer weiter eingrenzen, bis man den Fehler findet. Wenn ich mir der Stelle einen Fehlers nicht sicher bin, nummerier ich einfach durch und lass mir den fraglichen String,... ausgeben. Dann kann ich genau gucken, ab welcher nummer der Fehler auftritt. Von dort kann ich dann ggf. weitergucken oder hab die Zeile schon gefunden. Dass das ganze schnell geht ist reine Übungssache.

  • Was erwartest du? Ein Programm, welches du aufrufst und dass du parallel zu deinem Script laufen lässt, welches bei einem Berechnungsfehler ein Fenster öffnet "In Zeile 24761 wird ein nullbasiertes Array erst von vom Item 1 aus ausgelesen!" ?

    Im Grunde gibt SciTE es ja auch ungefähr so aus.


    @Cheater Dieter hat so etwas in seinem Grovveload realisiert und hier in diesem Thread vorgestellt: Fehler im Script abfangen/Eigene Fehlermeldung


    Es kann sein, dass es mit der aktuellen AutoIt-Version nicht mehr funktioniert. Damals hat es aber perfekt funktioniert und die Fehlermeldung sowie "richtige" Fehlerzeile im Skript ausgegeben.
    Eine zeitlang hat mir das bei kompilierten Skripten sehr geholfen, die ich weitergegeben habe und von anderen Absturzberichte erhielt..
    (.. heute mache ich einfach keine Fehler mehr - stimmt natürlich nicht ;) . Ich möchte Andy und Kanashius nicht widersprechen, sondern wollte nur ergänzen, dass es da auch hier schon Versuche gab).

  • @autoiter,


    du zitierst mich mit einem BERECHNUNGSFEHLER und gibst Beispiele eines Überlauf/Syntax/Compilerfehler/Exception-Fehlers!
    Das eine hat mit dem anderen nichts zu tun!
    In anderen Programmiersprachen gibt es glücklicherweise das "On Error Goto" (ja, auch in C(++) !! ), welches bei einem Ausnahmefehler in entsprechende Routinen springt und dort abgewickelt werden kann. Das ist der von mir beschriebene "Traum", da der "Fehler" bereits lokalisiert ist und man einen Anfangspunkt fürs Debugging hat!


    Ein BERECHNUNGSFEHLER wird dort niemals detektiert!
    Den findet man nur durch systematisches Ausgeben von Zwischenergebnissen. Man fragt sich:" Der Inhalt von $var sollte hier 1234 sein, ist aber 678, der "Fehler" muss vorher liegen!"
    Und das nimmt einem kein Debugger der Welt ab...
    Natürlich erlauben "richtige" Debugger die Eingabe von "Überwachungsparametern", aber was bringt mir das?
    Ich muss sowieso Breakpoints setzen, von Hand "tracen", uswusf.
    Da kann ich in AutoIt auch DebugMsgboxen oder Consolenausgaben per Tastaturshortcut in den Code eingeben, den Fehler finden und per Shortcut alle wieder loswerden!


    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!
    Manche "Fehler" sind echt tricky, aber was solls, da kniet man sich halt rein und nimmt Zeile für Zeile und Befehl für Befehl auseinander....learning by doing!

  • Stimmt (mir klang das nach Subscript used on non-accessible variable). Das habe ich falsch erfasst. Tatsache, so ein Debugger wäre ein Traum :)



    Im Prinzip ist "Debugging" eine Erfahrrungssache, 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!
    Man muss es einfach machen!
    Manche "Fehler" sind echt tricky, aber was solls, da kniet man sich halt rein und nimmt Zeile für Zeile und Befehl für Befehl auseinander....learning by doing!

    Meine Fehler haben sich schon stark reduziert, weil ich mir mehr Mühe gebe, Fehler abzuprüfen. Ab und an Fehler unter Schmerzen suchen zu müssen, hat mich da auch stark motiviert. :D