AutoIt-Script-Zeilennummern anzeigen in kompillierten exe Dateien

  • Hallo,


    wenn eine exe Datei kompiliert ist, wird mit dem Befehl „@ScriptLineNumber“ immer die Zeilennummer „-1“ ausgegeben. Soweit auch aus der Hilfe entnehmbar.


    Welche praktischen Workaround kennt oder nutzt Ihr, um die Script-Zeilennummern bei einer Fehlermeldung, die bei Ausführung der kompilierten exe an irgendeiner Stelle erscheint, für das Skript nachvollziehbar anzeigen zu lassen?


    Die aufwändigste Lösung, die mir einfällt, ist es, vor jeder Befehlszeile eine Variable $Zeilennummer = ... einzufügen. Aber selbst dann würde bei einer Fehlermeldung durch die kompilierte exe Datei diese Zeilennummer nicht ausgegeben werden. Oder gibt es Möglichkeit, diese bei einer Fehlermeldung anzeigen zu lassen?
    ... z.B. eine Funktion, die immer dann ausgeführt wird, wenn in der exe Datei eine Fehlermeldung angezeigt wird?


    Wie schafft man den Spagat, bei einer Fehlermeldung in einer kompilierten exe Datei, die zugehörige Zeile im Skript zu finden?

    Wie könnte man eine Log-Datei erstellen, die beim Ausführen einer exe Datei jede Befehlszeile speichert? Geht wahrscheinlich nicht auf Grund der exe Struktur.


    Nicht immer ist es so einfach, dass man aus dem Kontext auf die Stelle schließen kann, wie im folgenden Beispiel:


    ShellExecute("r:\123")

    Fehlermeldung der kompilierten exe-Datei:

    [Window Title]
    r:\123
    [Content]
    "r:\123" konnte nicht gefunden werden. Stellen Sie sicher, dass Sie den Namen richtig eingegeben haben und wiederholen Sie den Vorgang.
    [OK]

    Am besten wäre es natürlich, wenn es fehlerfrei läuft. Aber wenn auf dem PC was erstellt wird, was als exe auf dem Laptop in einen Fehler läuft, ist die Suche schon kompliziert. Noch komplizierter wird es, wenn ein Freund die exe auf seinem Rechner nutzt und es kommt dort eine Fehlermeldung, die keinen Bezug auf die Scriptzeile erkennen lässt.

    Eure Erfahrungen sind gefragt.

    Danke :)

    Einmal editiert, zuletzt von AutoMit (26. November 2016 um 14:38)

  • Du musst zwischen AutoIt-Fehlermeldungen und Shell-Meldungen unterscheiden können!

    AutoIt schmeißt die Zeilennummer immer mit bei einer Fehlermeldung raus, eine Shell-Meldung ist kein Fehler von der Seite AutoIts.
    Wenns crasht suchst du halt die Zeilennummer, wenns ne Shell-Meldung ist dann ist es ja kein Crash sondern deine Eingaben sind falsch.

  • Das mit der Fehlermeldung in der kompilierten exe-Datei ist nur ein Beispiel.


    Deswegen heißt das Thema auch „Zeilennummern in kompillierten exe Dateien“. Ich habe es etwas angepasst in „AutoIt-Script-Zeilennummern anzeigen in kompillierten exe Dateien“.


    Ich möchte - wenn eine AutoIt-exe-Datei ausgeführt wird - sehen, welche Skriptzeile gerade ausgeführt wird. Am einfachsten über die zugehörige Zeilennummer im Script.


    Und dafür suche ich eine Lösung.

  • Hallo @hevilp,
    es geht also nicht um eine Fehlermeldung, sondern du möchtest etwa in der Konsole mitverfolgen, welche Skriptzeile gerade ausgeführt wird. Das geht nicht.
    Wenn es doch um eine Fehlermeldung eines kompilierten Skripts geht, dann gibt es hier irgendwo ein Beispiel. Ich glaube von @AspirinJunkie.

    Grüße autoiter

  • Euren "Scherz" lasse ich mal kommentarfrei ...

    du möchtest etwa in der Konsole mitverfolgen, welche Skriptzeile gerade ausgeführt wird. Das geht nicht.

    zum Thema. Fehler schleichen sich schnell mal in ein Script / Programm ein. Wenn Programmierer in zig tausend Zeilen Code einen Fehler suchen, dann wird die Fehlermeldung oder ein Absturz oder ..., die die exe Datei erzeugt, häufig einen Hinweis auf jene Stelle liefern, an der im Quellcode zu suchen ist.


    *** Ist es in AutoIt möglich, eine eigene einfache Fehlerroutine zu schreiben? Also dass man z.B. die AutoIt-Fehler-Messagebox der exe-Datei durch eine eigene Funktion und / oder Messagebox ersetzt, die z.B. eigene definierte Variablen anzeigt? Das wäre schon hilfreich, weil man dann Variablen belegen und ausgeben könnte, auch wenn das Script als exe ausgeführt wird und in einen Fehler läuft. ***

    Es muss doch irgendeine Möglichkeit geben, nachvollziehen zu können, an welcher Stelle im Script die exe Datei gerade was abarbeitet.

    Und wenn es über eine Logdatei ist, .... irgendwas sollte es doch geben, damit man nachvollziehen kann, was die exe Datei gerade macht. Das man das in das Script vorher einprogrammieren muss, ist klar.

    Meine Bitte an Euch ist, mir zu sagen, welche Möglichkeiten Ihr kennt oder welche Ideen Ihr habt, um sowas im Script umzusetzen.

    4 Mal editiert, zuletzt von AutoMit (26. November 2016 um 19:18)

  • Nun. Log-Dateien werden geschrieben und zeigen dem Programmierer, wo sich das Programm befindet.
    Deshalb ist es bei Fehlermeldungen für Programmierer auch wichtig, eine genaue beschreibung zu bekommen. Nur dann kann man nach dem Fehler suchen.
    Wenn man nicht genau weiß, woran es liegt nutzt man Debugger. Das hilft aber nur, wenn man den Fehler nachvollziehen kann.
    Also einfach den User genau beschreiben lassen, was er gemacht hat, dass es zu dem Fehler kam.
    Einen anderen Weg solche Fehler zu finden gibt es nicht wirklich.

    Man muss sich als Programmierer mit dem Programm auskennen und darauf hoffen, dass die nutzer die fehler genau beschreiben können.
    (Ausgenommen virtuelle Maschienen, die können umfangreichere Infos zu Fehlern geben, da sie den Prozess die ganze Zeit "beobachten" /siehe z.B. Java).

  • Das kommt drauf an. Entwerder schreibst du die Fehler mit ConsoleWriteError ( "data" ) in den Errorstream (der wird zum Beispiel in CMD ausgegeben, wenn du das Programm mit cmd startest (start x.exe). Sieht man aber nur, wennn man sich die Fehlr auch ausgeben lässt. Einfach beim Ausführen mit doppelklick sieht man davon nichts.
    Ansonsten kann man die Daten auch in eine Datei schreiben. Sollte man dann auch hinterherräumen, damit nicht sinnlos große mengen speicherplatz verwendet werden.
    ConsoleWrite("") Kann auch für Logs verwendet werden. Ist dann auch in cmd sichtbar. ConsoleWriteError ist nur für Probleme/Fehler gedacht.

    Das ganze bedeutet halt arbeit.
    Nach jedem Befehl (der Probleme machen könnte) @error zu checken und die jeweilige Ausgabe machen
    Vor Arrayzugriffen, etc. checken, dass das Array auch passend ist,...

  • So mache ich es bei 'wuschigen' Sachen... da sehe ich sofort in welcher Funktion der Fehler aufgetreten ist... und mithilfe von @error und @extended dann auch genau die Stelle, wo es brennt.

    SetError()


    SetError.png