Autoit - PureBasic

    Hallo,

    ich habe so manche Programme mit Autoit programmiert und bin im Prinzip mit Autoit sehr zufrieden (abgesehen von Kleinigkeiten, wie z.B. $String, was nicht ganz so üblich ist). Was mich aber sehr stört, ist der fehlende Debugger. Zwar gibt es den Autiot-Debugger Version 0.45, aber wenn man zeitkritische Anwendungen schreibt, ist der Debugger bzw. das Programm durch den Debugger so langsam, dass man nur sehr schlecht Fehler suchen kann.
    Bei PureBasic gibt es einen deutlich besseren (schnellen) Debugger. Man kann mit ihm fast wie bei Visual Basic ziemlich gut das Programm testen. Aber die Software kostet Geld und ich habe den subjektiven Eindruck, dass Autoit einige, aber doch manchmal wichtige Funktionen, mehr hat.

    Meine Frage ist nun, wie testet ihr komplexe Programme? Gibt es ein besseres Tool als Autoit-Debugger oder wie löst ihr das Problem (der Debug-Befehl ist ja ziemlich furchtbar)?
    Oder sollte man ggf.zu PureBasic wechseln, weil die Entwicklerumgebung/Testumgebung besser ist? (Ich weiß eine ketzerische Frage hier im Forum).
    Hat jemand ebenfalls eine Vergleich zwischen den beiden Dialekte und kann was dazu sagen?

    Ihr seht , ich bin ziemlich verunsichert und würde mich über umfangreiche Feedbacks von euch sehr freuen.

    Grüße

    Mike

    Einmal editiert, zuletzt von Mike32 (11. Juni 2012 um 21:54)

    Zitat von Mike32

    Meine Frage ist nun, wie testet ihr komplexe Programme? Gibt es ein besseres Tool als Autoit-Debugger oder wie löst ihr das Problem (der Debug-Befehl ist ja ziemlich furchtbar)?


    Ich debugge gar nicht so viel. Das Programm wird möglichst modular geschrieben und die einzelnen Funktionen dann getestet. Wenn es dann mal hakt, kommen nach und nach Debug-Befehle an kritischen Stellen in den Code (z.B. Logdatei, ConsoleWrite oder OutputDebugString-DLLCall)

    Zitat von Mike32

    Oder sollte man ggf.zu PureBasic wechseln, weil die Entwicklerumgebung/Testumgebung besser ist? (Ich weiß eine ketzerische Frage hier im Forum).


    Das kannst du nicht vergleichen. AutoIt ist eine Skriptsprache, PureBasic wird kompiliert.

    Wenn du was besseres als AutoIt haben willst, ohne dafür Geld auszugeben,
    dann schau mal was Microsoft anbietet.
    Mir wäre PureBASIC zu exotisch. VisualBASIC ist nicht übel, wenns schon BASIC sein muss.

    Wer andern eine Bratwurst brät
    der hat ein Bratwurstbratgerät.

    Hi,

    Zitat

    Zwar gibt es den Autiot-Debugger Version 0.45, aber wenn man zeitkritische Anwendungen schreibt, ist der Debugger bzw. das Programm durch den Debugger so langsam, dass man nur sehr schlecht Fehler suchen kann.


    Zeitkritisch und AutoIt schliessen sich nicht nur beim Debuggen aus!
    Ich bin auch "Basic"-Anwender der ersten Stunde (Basic im ROM des IBM 8088 FTW^^, später PowerBasic), und genau aus diesem Grund auch bei AutoIt gelandet.
    Für 99 % aller Anwendungen ist AutoIt schnell genug und imho sehr komfortabel, den Debugger habe ich (progandy hat mit "ich debugge garnicht so viel" völlig Recht) noch nicht vermisst.

    Falls es wirklich mal "schnell" sein muss, dann bleibt immer noch die Möglichkeit, die benötigte Funktion in irgendeiner (Basic)Compilersprache zu schreiben, und als DLL in AutoIt zu verwenden. Oder Assembler/C++ einzubinden, wo wir allerdings beim Thema "komfortabel Debuggen" sind^^.

    Als "Gesamtpaket" für eine Basic-Sprache ist VB mit Sicherheit nicht zu schlagen, große Community und für so gut wie alle Anwendungen schon mal erstellte Programme sind der Vorteil.
    VB krankt aber am Gesamtkonzept aller MS-Produkte: nach 20 Jahren Entwicklung später sieht die Software viel schöner aus, ist aber genauso bescheuert und langsam zu bedienen wie vor Urzeiten...Oder hat die "Featuritis" für 99% aller Anwender Vorteile gebracht?

    PureBasic/FreeBasic und andere Dialekte füllen diverse Lücken wie z.B. plattformübergreifende Programmierung für Linux/Mac, spezielle Bibliotheken, Inline-ASM usw.
    Such dir aus, was dir am Besten gefällt und was du für die TÄGLICHE Arbeit wirklich benötigst.

    progandy

    Thx!
    Ja, so mache ich es auch. Es ist aber ziemlich nervig alles in Teile testen und dann wieder zusammenbauen, dazu kommen dann noch die Debug-Einfachheiten.
    Noch eine Frage, wo ist denn der Unterschied zwischen Scriptsprache und PureBasic. Auch Autoit wird doch kompiliert. - Und der Funktionsumfang sieht mir ziemlich ähnlich aus.

    ohforf
    Danke für den Hinweis. Ich habe früher VB6 programmiert. Aber aus Gründen der Zukunftssicherheit und der "Veralterung" von VB6 bin ich zu Autoit gewechselt. Das neue VB finde ich mit der neuen Syntax und der neuen Philosophie ziemlich ätzend (liegt aber sicherlich an mir). Auch ist es mir ziemlich kompliziert geworden.

    Grüße

    Mike

    Hi,

    Zitat

    Noch eine Frage, wo ist denn der Unterschied zwischen Scriptsprache und PureBasic. Auch Autoit wird doch kompiliert.

    Nein, AutoIt wird nicht kompiliert. Der Interpreter wird zusammen mit dem Quellcode in eine Datei gepackt (das *.EXE-File). Beim Starten dieser Datei wird der Interpreter gestartet und führt das Script aus. Daher die "Langsamkeit" in bestimmten Bereichen.
    Sämtlich Funktionen der WIN-API werden in AutoIt genauso aufgerufen wie in den Compilersprachen auch, daher gibt es dort KEINEN Geschwindigkeitsunterschied.

    Der Unterschied im Funktionsumfang beschränkt sich imho auf die Implementierung bzw. die "Wrapper" für API-Funktionen. Da geben sich sämtliche Sprachen nicht viel, aber die UDF´s machen den Kohl fett! Bei einer weit verbreiteten Sprache ist die Wahrscheinlichkeit wesentlich höher, dass ein anderer User die benötigte Funktion schon einmal geschrieben hat. Programmieren heutzutage ist das SCHNELLE finden von Funktionen, die jemand anderes geschrieben hat^^

    Andy

    vielen Dank für die ausführlichen Antworten. Nun wird mir einiges klar. :)
    Autoit ist für mich schon schnell genug, was ich meinte ist, dass das Debuggen zu langsam ist. Mein Programm überprüft "externe" Programme und steuert sie an. Da es dort manchmal Probleme gibt, will man debuggen, um festzustellen wo und warum.
    Ich programmiere zum Beispiel auch VBA. Dort kann man super im Einzelschritt bei voller Überwachung von Variablen, ... alles überwachen. Bei Autoit gibt es z.B. keinen Einzelschritt nur ein Debuggen/Trace an sich, wo die Ausgabe schnell angezeigt wird und das wars (hinzu kommt, dass der Code "zerstört" wird und man dann wieder suchen muss, welche Zeile was war).
    Das habe ich gemeint. Autoit finde ich nämlich super. Man sollte nur massiv am Editor/Debugging nachbessern. Von daher kam meine Frage, wie man am besten die Probleme löst.

    Noch zwei Fragen.
    Du meintest, das schnelle Finden von UDF ist sehr wichtig. Sehe ich auch so. Wie schätzt du diesbezüglich denn Autoit z.B. zu VB oder PureBasic ein?
    progandy meinte: "Das Programm wird möglichst modular geschrieben und die einzelnen Funktionen dann getestet." Meint er damit nicht einen(!) Code zu verwenden, sondern alle wichtigen Module einzeln abzuspeichern (und zu testen), dann diese mit #include einzubinden und dann mit einer "einfachen" Hauptroutine (ggf. mit Parameter) anzuspringen? Ich neige nämlich, da ich ebenfalls Basic-User der ersten Stunde bin, alles in einen Mammut-Code zu packen. :rolleyes:

    Thx

    Grüße

    Mike

    Zitat von Mike32

    alle wichtigen Module einzeln abzuspeichern (und zu testen), dann diese mit #include einzubinden und dann mit einer "einfachen" Hauptroutine (ggf. mit Parameter) anzuspringen?


    So meine ich das, aber die Aufteilung in includes mache ich auch nicht immer. Stattdessen teile ich dann die Datei mit #region etwas schöner auf.

    Hi,

    Zitat

    Mein Programm überprüft "externe" Programme und steuert sie an. Da es dort manchmal Probleme gibt, will man debuggen, um festzustellen wo und warum.


    Ok, dann bietet sich ja ein Trace (entweder jede Zeile oder je Funktion) an. Ich denke, das hast du ausprobiert....
    Was ich jetzt aber nicht verstehe ist dein Begriff von "langsam" im Bezug aufs debuggen. Wenn du, wie z.B. in VB, per Einzelschritt durch die Zeilen eierst, dann hast du zwar alle Variablen im Zugriff, aber bist doch extrem "langsam"?! Wie soll das schneller gehen?
    Das geht nur schneller, wenn du im Code Marken setzen kannst, ab denen dein Code debugged wird oder nicht.
    Daher Progandys Verfahren mit den Funktionen, die muss man nicht zwangsläufig alle per include einbinden, Hauptsache ist, dein Code ist übersichtlich und durch den Funktion-Trace hast du sehr schnell die Möglichkeit, den Fehler einzugrenzen.

    Geht es um Fehler im Programm (Division durch Null o.ä), dann sollte man diese schon im Code abfangen.
    Fehler in der Logik findet man so natürlich nicht, bspw. wenn im Code Daten eines Fensterinhalts (Controls) ausgewertet werden, aber das Fenster noch garnicht existiert. Da hilft dir aber zeilenweises Abklappern des Scripts auch nicht weiter....

    Tips:
    Spaghetti-Code (jaja, da kenn ich mich aus :rofl: ) so umschreiben, dass zusammenhängender Code in Funktionen zusammengefasst wird.
    Funktionen in weiteren Funktionen zusammenfassen, so findet man per einfachen ALT-D oder SHIFT-STTRG-D schon mal den Funktionsblock, den es zu untersuchen gilt....
    Verwendung von lokalen Variablen hilft auch weiter, globale Variablen, die von allen Funktionen verändert werden, sind naturgemäß nur sehr schwer zu "fangen".

    Zitat

    Mein Programm überprüft "externe" Programme und steuert sie an

    Interaktion mit externen Programmen ist immer etwas schwierig, aber da AutoIt von vielen Bottern benutzt wird, scheint es sich dafür anzubieten :thumbup:
    Gerade Bots können ein feines Beispiel für einen guten Programmierstil sein, wenn es nicht gerade darum geht in einem 10-Zeiler Pixelsearch() anzuwenden. Es geht ja primär darum, alle möglichen und unmöglichen Aktionen des zu steuernden Programms abzufangen und darauf zu reagieren....

    Andy

    Thx,

    tja, das mit dem Spaghetti-Code .... :whistling:
    Ich muss wohl etwas "umstrukturieren". Dann dürfte die Fehlersuche auch besser werden.
    Der Autoit-Debugger benötigt sehr viel Zeit z.B., um ca. 200 Wert aus einem File in Variablen einzulesen. In dieser Zeit, sagt das externe Programm "auf Wiedersehen". - Und um einzelne Funktionen zu testen, muss man oft ja bestimmte Parameter oder Rahembedingungen aufwändig zur Verfügung stellen, damit man erst die Funktion testen kann. Das ist das Problem dabei.
    Wegen VBA. Stimmt, aber man kann z.B. den Code bis zu einer bestimmten Stelle normal durchlaufen lassen, dann den Haltepunkt abwarten und dann im Single-Step einige Schritte langsam weitergehen und dabei dann alle Parameter beobachten und genau sehen, was exakt passiert. Dies ist an manchen schwierigen Stellen sehr wichtig. Ein Debug, der an einem "vorbeirauscht" ist dann wenig hilfreich. Auch eine Protokolldatei ist nicht optimal.
    Für mich ist es auch etwas problematisch, dass es kein goto gibt. Das mit den Gosub kann man ja mit einer Function umgehen, aber goto... . Ist schon manchmal wichtig, finde ich. Dies verschachtelten Schleifen, sind nicht immer optimal.

    Übrigens #region kannte ich noch nicht. Habe es auch nicht in der Hilfe gefunden. Wofür ist es überhaupt?

    Nochmals Danke!

    Grüße

    Mike

    Zitat von Mike32

    Übrigens #region kannte ich noch nicht. Habe es auch nicht in der Hilfe gefunden. Wofür ist es überhaupt?


    Code zwischen #region und #endregion gehört logisch zusammen und du kannst ihn in SciTe zusammenklappen. Beispiel:

    Spoiler anzeigen
    [autoit]

    ; ---------------------------------------------------------------------------------------
    #region GUI Event functions

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

    Func _ButtonClick()
    EndFunc

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

    Func ComboChange()
    EndFunc

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

    Func GUIClose()
    EndFunc

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

    #endregion GUI Event functions
    ; ---------------------------------------------------------------------------------------

    [/autoit]

    Zusammenklappbar auf:

    [autoit]

    ; ---------------------------------------------------------------------------------------
    #region GUI Event functions
    ; ---------------------------------------------------------------------------------------

    [/autoit]