• Zum Makro...
    Folgendes Programm starten: den iss Compiler
    Parameter: %projectdir%\Iss Setup Datei.iss <--- da hab ich mehrere Varianten versucht, also auch mit den echten Pfadbezeichnungen usw.

    Zum DBUG-Tool...
    Ich kann mich gerne versuchen, hab's auch schon probiert, aber ich raff überhaupt nicht, wieso das Ding, als normale include eingebunden, perfekt funzt (also bei mir zumindest), mit stimmigen Zeilen, Run To Cursor, Breaktpoints, etc. usw. und deine angepasste Variante nicht! Allerdings verstehe ich auch die Korrektur, die du an der $lnr vornimmst nicht wirklich. Ich kann zwar sehen, welche Auswirkungen das hat, wenn ich das auf den Originalcode rückändere, und verstehe auch, was du vorhattest, aber ich kapier nicht, WIESO das ÜBERHAUPT nötig ist! Sprich, wieso hast du quasi mit deiner Version andere Zeilennummern, als ich in der "fast" Originalversion... Grrrr.... Momentan hab ich nicht sooo viel Zeit zu suchen, aber ich bleib dran!

    Lieber Gruß und nix zu danken!
    Holger

  • Ich hab ne Idee, was das DBUG Problem anbelangt!

    Ich versuchs mal zu erklären und mache 2 Beispiele (hierbei gehe ich davon aus, daß ich ein Stück Code habe, das genau 10 Zeilen hat):

    a) ich füge die Zeile #include <dbug.au3> eigenhändig in den Code ein -> Editor hat 11 Zeilen
    b) DU fügst vor dem Start im Hintergrund in die temporäre Datei deine geänderte Codezeile ein, startest einmal, damit die Debugzeilen erzeugt werden und startest nochmal, damit das Debuggen losgehen kann -> Editor hat aber nur 10 Zeilen!

    -> du hast genau 1 Codezeile Differenz durch das Einfügen deines Includes.

    Das wird aber nirgendwo im Debugger berücksichtigt, weil die ganze UDF davon ausgeht, daß du auch genau den Code debuggst, den du im Editor vor der Nase hast. Stimmt aber nicht, es ist ja im Hintergbrund eine Zeile dazu gekommen!

    -> das Code Array ist um einen zu lang, sämtliche Marker und Zeilenansprünge sind um 1 verkehrt, jeder Markerlesevorgang liefert einen zuviel. Ich bin nicht alles durchgegangen, aber ich denke, damit rechnet er überall falsch und da ja Scintilla selbst die Markerpositionen zurückliefert, die teilweise angesprungen werden, aber der Code im Hintergrund dazu nicht mehr passt, läuft das auch nicht sauber.

    Ich schau mal, ob da irgendwo ein +1 schon ausreicht ;-))

    EDIT: Also ich hab grad nen Monster Knoten im Schädel 8| und krieg das mit der einen Zeile nicht gewechselt. Mache mich evtl. morgen nochmal dran... ;(
    EDIT 2: Das läßt mir keine Ruhe... ich glaube aber, da sich der genaze Kram teilweise rekursiv wieder aufruft, dürfte die Lösung nicht ganz trivial sein...

    3 Mal editiert, zuletzt von pandel (27. März 2013 um 18:58)

  • Ok das mit dem Makro werd ich mir ansehen..

    Und zum DBUG:
    Zum technischen: wie du richtig gesagt hast wird hier im hintergrund das include eingefügt, das debugscript generiert und gestartet. Una ja das mit der include Zeile die im "echten" Editor nicht vorhanden ist ist mir durchaus bewusst gewesen. Daher hab ich auch die Reihen korrigiert im vergleich zu deiner Version.
    ABER: Da ich mir dann nicht ganz so sicher war ob das alles so läuft wies soll (und anscheinend tut es das ja nicht xD) hab ich die Meldung reingegeben das dieses Feature noch experimentell ist!
    Aber ich bin leider jezt auch noch nicht so wirklich dazugekommen das ganze weiter zu verfolgen und daher würde mir deine Hilfe sehr gelegen kommen :)

    Wäre supper wenn wir das noch in Griff bekommen würden :)
    Im Endeffekt ist es ja "nur" diese eine Zeile die uns da das Leben schwer macht :P

  • Denke, ich hab den Griff gefunden! Na dann teste mal... ;-))

    Das einzige, was jetzt noch nicht geht, ist der Tooltip, wenn man mit der Maus über eine Variable fährt. Aber das liegt in _SCIGetCurWord() begraben. Warum der die Mausposition nicht holt, ist mir noch nicht ganz klar, aber vielleicht find ich das ja auch noch raus...

    EDIT: Tooltips für Variablen sollten jetzt auch gehen... Gute Nacht ;-)!

    [Anhang entfernt - siehe nächste Posts]

    3 Mal editiert, zuletzt von pandel (28. März 2013 um 15:08)

  • Schlaflos war ich schon, aber nicht wegen deiner Bitte! Ich bin eine fürchterliche Nachteule. Wird's dunkel, kann ich denken und werde kreativ, von daher der beste Zeitpunkt zum debuggen ;-))

    Nimm mal die angehängte hier. Ich hab noch ein bißchen am Scrolling getunt ($SCI_ENSUREVISIBLEENFORCEPOLICY). Dann ist es angenehmer beim Hin- und Herspringen, aber wem erzähl ich das ;-)). Und außerdem hab ich noch eine Prüfung eingebaut, ob jemand versucht, bei einer Kommentarzeile einen Breakpoint zu setzen - is blöd, weil da rennt das Ding einfach braun drüber weg... das geht jetzt nicht mehr (außer innerhalb von großen #cs...#ce Blöcken, aber da soll halt jeder selber aufpassen ;) )!

    Sag mal, was hälste davon, wenn wir dem Debugger zumindest noch ne deutsche Übersetzung spendieren? Dein Sprachsystem ist ja recht klar. Wenn Du mir nen Nummernkreis zusprichst (sagen wir bspw. str1000 - str1050), dann könnte ich bei Lust und Zeit die Strings mal anpacken. Das Teil ist ja jetzt eh soweit integriert, daß es einzeln nicht mehr nutzbar wäre, da kann man jetzt auch mal ordentlich umbauen, was meinste?

  • Sprachlos bin! :P
    Nochmals tausend dank für deine Bemühungen!!

    Und ja eine Übersetzung wäre wirklich nicht schlecht...
    Ich hätte mals gesagt du kannst ab der Nummer str820 anfangen. So viel Text ist da eh nicht zu Übersetzen.
    Am besten du schickt mir einfach die Strings und ich füge sie dan mit den nötigen Funktionen in die au3 ein (so das es auch keine Probleme mit dem ISN gibt)

  • Da gibt's gar nix sprachlos zu sein ;) Ich nutze es aktiv und finde es gut wenn es funktioniert. Du hast viel Arbeit damit gehabt bis jetzt und ein bißchen Hilfe kann da ja nicht schaden!

    Bzw. der Übersetzung:

    Du nutzt doch _Get_lang, das ist doch easy. Ich mach dir, wenn ich Zeit hab, einfach ne Fassung der dbug.au3 mit Umsetzungen auf _get_lang ab str820. Dann schick ich dir den Kram, so daß du den nur noch an die Language Dateien anfügen musst. Ok?

  • Hi ISI360,

    nur zur Info: es wird mit der Übersetzung noch ein wenig dauern, da ich momentan noch ein anderes Projekt an der Backe habe. Schreibe gerade an einem Editor mit Scintilla, ABER der Lexer mit Highlighting, Folding, etc. wird komplett in AutoIt geschrieben ;) Läuft auch schon echt gut, nur am Folding beiß ich mir gerade noch etwas die Zähne aus ;-)))

    Übrigens hat mir da die Debug Funktion beim Umsetzen des Highlightings schon sowas von geholfen, einfach Oberklasse :)!

    Gruß
    Holger

  • Danke für die Info!

    Kein Problem! Ich komme aktuell ja leider auch zu nichts :P :P

    Und wegen deinem Projekt:
    Im Englischen Forum hat ein User den klassischen Scintilla Editor nachgebaut.
    Er verwendet darin auch einiges an Code vom ISN.
    Vielleicht kannst du das für dein Projekt ja auch irgendwie brauchen:
    http://www.autoitscript.com/forum/topic/14…__hl__%2Bascite

    Und freut zu hören wenn es funktioniert das ganze :)

  • Tja, und kaum hatte ich's geschrieben, hat es mich auch nicht losgelassen... Is feddich!

    Ich habe die dbug.au3 so abgeändert, daß du im ISN selber gar nichts mehr ändern mußt. Die dbug.au3 findet die Ordner, die Konfig und die Sprachdateien ganz von alleine. Das einzige, was du also machen musst, ist die dbug.au3 zu ersetzen und die beiden ergänzenden Sprachdateien hier ausm Anhang nehmen und an deine originalen Sprachdateien dranhauen. Ich hab ab str821 losgelegt, weil gepennt ;) Also sach nix... Funzt aber sonst gut. Ich find diesen Debugger sooo geil ;) Wußtest Du, daß man die Debugger-internen Variablen selber debuggen kann ;-)? Starte mal ein x-beliebiges Projekt mit Debugger, gib im Kommandofenster einfach nur den Variablennamen $DBGConfigfile ein und drück Ctrl-Enter... Ach so, mir ist noch was aufgefallen: wenn man einen bedingten Ausdruck für einen Haltepunkt eingibt (Eingabefeld am oberen Rand rechts) darf man kein " benutzen, sondern nur '. Also $foo="bar" geht nicht, aber $foo='bar' super! Nur so als Tipp, falls mal wer fragt...

    Und bzgl. des Editor Projekts im englischen Forum:
    Das find ich recht gut, nur für meine belange etwas zu fett. Ich finde diese hier ganz schön, weil es die Basisfunktionen hat und damit ist erstmal gut. Ausbauen kann ich das ja immer noch. Wichtig ist mir halt der Lexer. Ich brauche es für eine Skriptsprache, die nicht von den Standardlexern unterstützt wird und da dachte ich, wo ich schon einmal dabei bin... ;-)) Das mit dem Folding kann ich mir leider auch sonst nirgendwo abschauen, weil es normalerweise ja intern in den Lexern geregelt wird. Das hab ich exemplarisch für AutoIT Skripte zwar gelesen und verstanden, aber die Umsetzung für meinen Lexer in AutoIt selber muss da noch etwas reifen...

  • Hallo ISI360,

    hab da noch ne Frage: wäre es möglich, daß du für das Erstellen des Release Ordners eine Option schaffst, mit der man gezielt vorhandene Dateien und Unterverzeichnisse im Projektordner ausschließen kann? Ich schiebe mein aktuelles Projekt bspw. in ein SVN Repo. Dein Release Mechanismus kopiert mir beim Kompilieren (nur EXE, ohne den Quellcode einzuschließen) nun sämtliche zusätzlich vorhandenen Ordner immer mit, aber ich brauche die im Release nicht alle; bspw. mein .svn Ordner, oder Ordner mit Hilfsdokus, etc.

    Lieber Gruß
    Holger

  • Hmm ich denke das könnte schwer werden. Da beim kopieren eine Windowsfunktion genutzt wird (die ich nicht ändern möchte) können hier keine Ausnahmen definiert werden! (Und selbst bei den au3 Dateien werden die immer mitkopiert nur dann halt falls die Checkbox mit dem Quellcode deaktiviert ist wieder gelöscht...geht leider nicht anders aber da die au3 dateien nicht groß sind lässt sich das noch verschmerzen)

    Ich würde es an deiner Stelle über ein Makro realisieren:
    Im Makro fügst du als erstes eine Aktion zum kompilieren deiner Hauptdatei hinzu und im Anschluss diverse Dateioperationen mit den Ordnern/Dateien die du benötigst!
    Du kannst in einem makro eh unendlich viele aktionen Aneinanderreihen! :)
    Hoffe es hilft dir etwas...

  • Hallo ISI360,

    alles fit bei Dir? Hoffe doch ;-))...

    Ich hab eine Frage: wenn man folgende Optionen benutzt

    #AutoIt3Wrapper_Res_Fileversion=1.0.0.1
    #AutoIt3Wrapper_Res_FileVersion_AutoIncrement=y

    und kompiliert, dann wird leider, sofern die Hauptdatei des Projekts geöffnet ist, die imkrementierte Versionsnummer nicht in den Code geholt. D. h. man muss die Nummer aus dem Konsolenfenster manuelle übertragen. Es wäre schön, wenn du danach entweder das Skript nochmal neu laden würdest, oder, was schneller aber aufwändiger wäre, die neue Versionsnummer aus der Konsole holst und dann im Quellcode abänderst. Ist eigentlich nur lästig ;)

    Lieber Gruß
    Holger

  • ja Danke alles bestens! :)

    Also wegen dem "Bitwise operations visualiser": Sieht brauchbar aus danke :)
    (PS: Fällt irgentwem ein Deutscher Begriff für den "Bitwise operations visualiser" ein? ^^)

    Und wegen den Versionsnummern: Sehe ich das richtig das da beim Kompilieren etwas in die Hauptdatei geschrieben/verändert wird und daher der Inhalt neu geladen werden soll? (Kann es aktuell leider nicht testen.... -.-)

  • Und wegen den Versionsnummern: Sehe ich das richtig das da beim Kompilieren etwas in die Hauptdatei geschrieben/verändert wird und daher der Inhalt neu geladen werden soll? (Kann es aktuell leider nicht testen.... -.-)


    Zu dem Namen habe ich leider keine gute Idee... die von chesstiger ist schon ganz ok. Das läßt sich irgendwie nur recht holprig übersetzen...

    Aber was die Versionierung anbelangt, ja der macht aus
    #AutoIt3Wrapper_Res_Fileversion=1.0.0.1
    nach dem Kompilieren
    #AutoIt3Wrapper_Res_Fileversion=1.0.0.2
    und schreibt das in die Hauptdatei.

    Ich war ja schon so bauernschlau und hatte den Teil in eine include ausgelagert, aber das checkt der Compiler nicht ;)

    EDIT: im Grunde könnte das doch vielleicht so ähnlich laufen wie bei Tools\Tidy Source, oder?

    Einmal editiert, zuletzt von pandel (23. April 2013 um 12:20)