Fehlermeldung 1.#INF u.a.

  • Beim Testen von speziellen Berechnungen und Ausgabe über eine temporäre MsgBox erhielt ich z.B. die kryptische Ausgabe "1.#INF".
    In der Hilfe konnte ich keine Erklärung dazu finden.
    Gibt es irgendwo eine Übersicht für solche "Kürzel"?

    Des weiteren suche ich nach einer Möglichkeit, bei der Event-Anweisung

    GUICtrlSetOnEvent($Button1Prop, "Button1OK")

    an das aufgerufene UP "Button1OK" bestimmte Variablen-Parameter zu übergeben.
    Das hätte Vorteile bei der Weiterverarbeitung.
    Globale Deklaration würde zwar gehen - halte ich aber nur im Notfall für richtig.
    Bei VB kann man an alle Funktionen Parameter übergeben - egal, von wo sie aufgerufen werden.

    MbG

    PSblnkd

  • Bei Guictrlsetonevent ist es nicht möglich parameter zu übergeben.
    Aber mit @GUI_CTRL kannst du abfragen welches Control gedrückt wurde und dann abhänig davon Variablen setzen
    Dann brauchst du die Globalen nicht...

    1.#INF glaube ich war eine Division durch 0. Kann das sein?

  • Schnitzel, Milla

    danke für Eure schnelle Antwort.
    Daß die Fehlermeldung 1.#INF auf eine Division / 0 hindeutet, hatte ich mir schon gedacht. Die Frage war aber, ob und wo eine Übersicht zu solchen kryptischen Ausgaben steht - mit Erklärung. Schließlich kann es da ja noch mehr geben oder? - Und dann steht man wieder da und weis nicht weiter...sollte unbedingt in der Hilfe ergänzt werden....

    Wünschenswert wäre auch in SciTE-IDE bzw. Debugger ein Variablen-Control-Fenster (so wie im MS-Studio) zu haben, da brauchte man nicht dauernd temporäre MsgBoxen zu setzen...mal als Tip an die Macher von SciTE.
    Wird der Debugger noch weiterentwickelt?

    Das Problem mit der Parameterübergabe bei GuiCtrlSetOnEvent habe umgangen, indem ich temporär - d.h. nur für die Aufrufs des Event-Handlers - den Event-Modus mit

    Opt("GUIOnEventMode", 0)

    eingestellt habe. Dann funktioniert auch das Abfragen mit @GUI_CTRL, aber was noch viel wichtiger ist - die in der aufrufenden Funktion definierten Variablen (z.B. die ID eines Eingabefeldes) sind dann noch gültig, weil die Abfage im der gleichen Funktion untergebracht werden kann und nicht noch ein weiteres UP aufgerufen werden muß. Am Ende der Funktion wird dann mit

    Opt("GUIOnEventMode", 1)

    der ursprüngliche Modus wieder hergestellt.
    Das Verfahren funktioniert einwandfrei - siehe "Ein CAD mit AutoIt" (GUI "Eigenschaften Graphic-Objekte").
    Vielleicht gibt's ja auch noch andere Möglichkeiten der Realisierung...

    MbG

    PSblnkd

  • Zitat

    Daß die Fehlermeldung 1.#INF auf eine Division / 0 hindeutet, hatte ich mir schon gedacht. Die Frage war aber, ob und wo eine Übersicht zu solchen kryptischen Ausgaben steht - mit Erklärung. Schließlich kann es da ja noch mehr geben oder? - Und dann steht man wieder da und weis nicht weiter...sollte unbedingt in der Hilfe ergänzt werden....


    Ja da haste recht das könnte man ergänzen, auch wenn es egtl keine Autoit-Meldung ist...

    Zitat

    Das Problem mit der Parameterübergabe bei GuiCtrlSetOnEvent habe umgangen, indem ich temporär - d.h. nur für die Aufrufs des Event-Handlers - den Event-Modus mit
    Opt("GUIOnEventMode", 0)


    Ich dachte du bist im OnEvent-Modus weil du ja in Post #1 was von GUICtrlSetOnEvent schreibst.
    Außerdem kriegste ne Fehlermeldung wenn du das Macro benutzt wenn der OnEvent-Modus aus ist...

    Einen vernünftigen Debugger wird es wohl nicht geben...

  • Schnitzel

    Ja, das Hauptprogramm läuft im OnEventModus 1.
    Doch dann ist eben nur mit dem Aufruf eines separaten Event-Handlers ohne Parameterübergabe was möglich.
    Deshalb habe ich das mit der temporären Umschaltung in den OnEventModus 0 umgangen.

    Wie gesagt - es funktioniert. Probier doch mal die 2.GUI "Eigenschaften Grafik-Objekte" in meinem "CAD mit AutoIt".
    Dort kannst Du Parameter verändern, die anschließend nach "OK" in das Parameter-Array zurückgeschrieben werden.
    Ein erneuter Aufruf der 2.GUI sollte das bestätigen.

    Warum soll's nicht eine vernünftige IDE mit Debugger geben? Arbeiten die Jungs von SciTE/Debugger nicht zusammen und wird da nicht mehr weiterentwickelt? - Mir fehlen z.B. die vielfältigen Möglichkeiten des Step-Betriebes

    - Einzelschritt
    - bis Cursor vorwärts, oder rückwärts
    - über eine ganze Routine (UP)

    nebst Fenster mit aktuellen Variablen-Log - vergleichsweise mit dem MS-Studio.

    MbG

    PSblnkd

    Einmal editiert, zuletzt von PSblnkd (5. Februar 2011 um 09:14)

  • Warum soll's nicht eine vernünftige IDE mit Debugger geben? Arbeiten die Jungs von SciTE/Debugger nicht zusammen und wir d da nicht mehr weiterentwickelt? - Mir fehlen z.B. die vielfältigen Möglichkeiten des Step-Betriebes

    - Einzelschritt
    - bis Cursor vorwärts, oder rückwärts
    - über eine ganze Routine (UP)

    nebst Fenster mit aktuellen Variablen-Log - vergleichsweise mit dem MS-Studio.


    Scite ist ein eigenständiges Tool, diverse Hilfsmittel wie Tidy, Koda sind darüber eingebunden. Die Debug-Möglichkeiten in Scite habe ich noch nicht benutzt, behelfe mich mit ConsoleWrite bzw. ArrayDisplay.
    Vielleicht genügt ja dieser Debugger deinen Ansprüchen, aber Achtung: nicht mit dem Original-Skript testen denn u.U. zerschiesst er dir dein Skript (äöüß usw.).
    Bei deinen Ansprüchen solltest du dir eh überlegen ob du nicht mit einem Produkt von der Stange (MS Visual Studio) besser bedient bist,

    mfg autoBert

  • autoBert

    SciTE ist eigentlich ganz toll, hat aber gar keine Debug-Funktion - Go oder Build (Compile) ist alles. Deshalb gibt es in meinem 1800-Zeilen-Code massenweise temporäre MsgBoxen, die bei Bedarf, d.h. bei irgendwelchen Problemen aktiviert werden können, somit die Abarbeitung anhalten und eine diesbezüglich wissenswerte Ausgabe produzieren.

    Bei mir gibt es eigentlich nur den einen Anspruch - nämlich CAD mit AutoIt zu realisieren.
    In anderen Programmiersprachen haben das Andere schon vielfach getan. In C++ gibt's das sogar als Opensource - aber sich da reinzudenken, ohne ausführliche Kommentierung, bzw. Programm-Beschreibung ist m.E. genauso aufwendig, als ob man das alles selbst neu macht.

    Ja, den Debugger kenne ich - ist irgendwie auf SciTE aufbaut - hat nur eine einfache Step-Funktion. Alles weitere, was ich oben anführte, fehlt (noch).
    Leider habe ich mit dem Tool keine guten Erfahrungen gemacht - entweder es funktioniert sehr eingeschränkt oder nicht richtig, manchmal auch gar nicht - und dann noch die Gefahr der Quellcode-Zerstörung (ist bei meinen Tests zwar nicht passiert, aber andere User wiesen bereits darauf hin).

    Auch in der Annahme, daß hier die Macher (oder deren "Zuträger") von SciTE/Debugger mitlesen, hatte ich den Beitrag gepostet.
    Es wäre sehr hilfreich, wenn es auf diesem Gebiet weitergeht...

    MbG

    PSblnkd

    Einmal editiert, zuletzt von PSblnkd (5. Februar 2011 um 09:12)

  • Etwas besseres als den genannten Debugger wirst du nicht finden. Die AutoIt-Entwickler haben kein Interesse daran und daher kann man einen Debugger nur damit erstellen, dass man den AutoIt-Quellcode verändert, so dass es auf die Befehle des "Debuggers" reagiert.

  • @progandy

    Deinen ersten Satz verstehe ich ja noch, obwohl das nicht meine Frage beantwortet.
    Den zweiten Satz - erster Teil "Die AutoIt-Entwickler haben kein Interesse daran" kann ich auch noch nachvollziehen, weil die Software(-Sprache) AutoIt zwar Bestandteil von SciTE/Debugger ist (?), aber nicht abhängig davon.
    Was jedoch den zweiten Teil angeht "... und daher kann man einen Debugger nur damit erstellen, dass man den AutoIt-Quellcode verändert, so dass es auf die Befehle des "Debuggers" reagiert." - das kann ich auch fünfmal lesen, ohne dahinter zu kommen, was Du mir eigentlich damit sagen willst.

    Ich wollte eigentlich keinen Debugger erstellen (programmieren), sondern nur einen für mich (und sicherlich auch andere) brauchbaren benutzen.
    Deshalb die konstruktive Kritik an die Macher vom SciTE/Debugger, verbunden mit dem Wunsch, das an der Baustelle weitergearbeitet wird.
    Ich wäre jedenfalls jedem dankbar, wenn mir beim "CAD mit AutoIt" solche zuteil sein würde.

    Alternative IDEs sind ja bisher immer in den Anfängen steckengebleiben - oder habe ich da was übersehen?

    MbG

    PSblnkd

  • Ich wollte eigentlich keinen Debugger erstellen (programmieren), sondern nur einen für mich (und sicherlich auch andere) brauchbaren benutzen.


    Der von autoBert genannte Debugger ist der einzige, der einigermaßen funktioniert. Und dieser verändert den Quellcode, sodass er die Befehle des Debuggers annimmt, da AutoIt keine Schnittstelle für einen echten Debugger bietet. Mit diesem Ansatz ist es nicht möglich, den Debugger viel besser zu machen als bisher und es besteht immer das Risiko, dass diese automatischen Veränderungen das Skript zerschießen.
    Und Scite4AutoIt wird von den AutoIt-Entwicklern erstellt und wie gesagt, diese haben kein Interesse an einem Debugger.

  • @progandy

    Danke für Deine Ausführungen, aber bei -

    "Und dieser verändert den Quellcode, sodass er die Befehle des Debuggers annimmt, da AutoIt keine Schnittstelle für einen echten Debugger bietet." -

    ergibt sich doch gleich die nächste Frage:
    Wieso muß ein Debugger den Quellcode verändern?
    Soweit ich die Arbeitsweise von Debuggern kenne (jedenfalls, was den STEP-Betrieb angeht) ist es doch so, daß ein Parser eine Codezeile nach der anderen Interpretiert/compiliert, sich die Einsprungsadresse der nächsten Zeile merkt, den Zeilencode ausführt und dann die Steuerung an das Betriebssystem zurückgibt. Beim nächsten STEP wird von der gemerkten Einsprungadresse wieder genauso verfahren. Eine Veränderung des Quellcodes ist dabei m.E. nicht notwendig.
    Anders natürlich bei meiner Hilfslösung mit temporären MsgBoxen. Die verändern tatsächlich den Quellcode, allerdings nicht die Wirkungsweise des eigentlichen Programms, wenn sie mit ";" deaktiviert sind - und einen Absturz gibt es deswegen schon gar nicht.

    Aber vielleicht kannst Du mich (uns) ja mal über die Notwenigkeit einer Schnittstelle für einen echten (was ist ein unechter?) Debugger aufklären.

    Und dann würde ich gern eine Begründung erfahren für die Aussage:

    "Und Scite4AutoIt wird von den AutoIt-Entwicklern erstellt und wie gesagt, diese haben kein Interesse an einem Debugger."

    Wenn SciTE4AutoIt von den AutoIt-Entwicklern erstellt wurde und Debuggerfunktionen im Rahmen einer IDE einfach dazu gehören, dann würde diese Aussage in sich einen Widerspruch bedeuten.
    Wieso haben die AutoIt-Entwickler kein Interesse an einer umfassend-komfortablen IDE?
    SciTE ist zwar zum Erstellen von Quellcodes, Syntax-Prüfen und exe-compilieren ein wirklich tolles Programm! Aber wieso soll man es damit bewenden lassen, wenn jederman weis, daß es in der Regel ohne Fehlersuche nicht geht. Und wieso können dann innerhalb von SciTE nicht brauchbar-komfortable Tools zur Verfügung stehen, die das Programmierer-Leben erleichtern?

    MbG

    PSblnkd