Den Namen der aktiven (oder aufrufenden) Function ermitteln

  • Trotz RTFM und Google nix gefunden:

    Ich möchte, für eine formatierte Debug-Ausgabe, den Namen der gerade aktiven Function ermitteln.

    Wie könnte das gehen?

    Alternativ:

    Ist es innerhalb einer Function möglich, zu ermitteln, von welcher "höheren Function" sie aufgerufen wurde?

    Was das soll?

    - Ich habe in meinem Programmcode die mir stets lästigen Debug-Ausgaben per ConsoleWrite() durch eine eigene Lösung ersetzt, die erstens simpler einzuitippen ist (z. B. kein " & @CRLF" mehr erforderlich) und die darüber hinaus den Programmablauf automatisch schick strukturiert dokumentiert.

    Es wäre auch kein Problem, die Ausgabe in eine Logdatei umzuleiten, statt in die Console.

    Das klappt soweit alles prima, nur muss ich beim Betreten/Verlassen einer jeden Func deren Namen an meine Log-Routine übergeben, was ich bisher "zu Fuß" erledige.

    Es wäre bequemer und zudem für die Suche im Quelltext vorteilhafter, wenn ich dort jedes Mal eine stets identische Codezeile reinpacken könnte, die den Namen selbst ermittelt.

    Ich code, also bin ich!

    • Offizieller Beitrag

    Es wäre bequemer und zudem für die Suche im Quelltext vorteilhafter, wenn ich dort jedes Mal eine stets identische Codezeile reinpacken könnte, die den Namen selbst ermittelt.

    Einfach eine Funktion schreiben, die bei Aufruf per Hotkey die Funktion in der vorangehenden Zeile abfragt und deine Debugzeile mit Funktionsnamen einfügt. Geht am Einfachsten mit Lua, aber auch mit AutoIt über das SciTE-Interface.

  • Moment, nix Hotkey.

    Mein Programm tut dies, tut das, tut jenes ... und das soll mitgeloggt werden.

    Jedes Mal, wenn eine Function betreten/verlassen wird, soll die Info über dieses Ereignis in die Logdatei einfließen.

    Unabhängig davon, ob der User das angestupst hat, oder nicht.

    Die Frage ist also : Wie kann eine Function ihren eigenen Namen ermitteln?

    Die alternative Frage : Wie kann eine aufgerufene Function den Namen der sie aufrufenden "Über-Function" ermitteln?

    Gegenwärtig sieht der Inhalt meiner Console so aus (gut!):

    Das gefällt mir schon prima,aber am Anfang und Ende einer jeden Function (mit Ausnahme der extrem häufig aufgerufenen), habe ich jeweils eine "Output-Zeile" stehen, die mir meinen Ersatz für ConsoleWrite() aufruft:

    Code
    Func _User_Eingabefelder_leeren()           ;# Alle Functions, die vom User himself (und nur vom User!) aufgerufen werden, beginnen im Namen mit "_USER_"
      output("_User_Eingabefelder_leeren", 1)
      _Eingabefelder_leeren()                   ;# Ruft die eigentliche Function auf (die auch programmintern zum Einsatz kommt). 
      output("_User_Eingabefelder_leeren", -1)
    EndFunc  ;==> _User_Eingabefelder_leeren()

    Obige Function ist natürlich betont minimalistisch. Aber sie verdeutlich das Prinzip.

    Jeweils direkt hinter "Func " kommt eine Zeile mit output().

    (Der zweite Parameter sorgt übrigens für die Einrückung aller folgenden Outputs um eine Position nach rechts.)

    Und vor jedem "EndFunc" kommt wieder so eine Outputzeile.

    (Der zweite Parameter "-1" macht die vorherige Einrückung wieder rückgängig.)

    Will ich zwischendurch eine Debugmeldung ausgeben, dann schreibe ich statt:

    ConsoleWrite("Laberlaber" & @CRLF)

    einfach nur:

    output("Laberlaber")

    (Hier kann ich den zweiten Parameter weg lassen, die Zeile wird automatisch korrekt eingerückt.)

    Ich erhalte also, mit weniger Schreibarbeit als bei ConsoleWrite(), einen schick formatierten Log in der Konsole (oder bei Bedarf auch in einer Datei).

    Aber ich muss halt, innerhalb einer jeder einzelnen Function, in zweien dieser Output-Zeilen den Namen der Function per Hand eintippern.

    Wäre schöner, wenn diese Zwei Zeilen jeweils ungefähr so aussehen könnten:

    output(@FunctionName, 1)

    output(@FunctionName, -1)

    Ich code, also bin ich!

  • Hi,

    schon mal in Scite reingeschaut?! Extras, Trace: Add Func Tracelines ...und was es sonst noch an Debuggingwerkzeugen dort gibt....

  • schon mal in Scite reingeschaut?! Extras, Trace: Add Func Tracelines ...und was es sonst noch an Debuggingwerkzeugen dort gibt....

    Zur Sicherheit :

    Die AutoIt (Full) Installation enthält nur eine eingeschränkte Version des SciTE-Editors !

    Ich bin mir nicht sicher, ob die von Andy angesprochenen Menüpunkte dort bereits enthalten sind.

    Sollten sie fehlen, so kann man zusätzlich die für AutoIt erweiterte 'Komplettversion' des Editors (SciTE4AutoIt3.exe) installieren (generell eine gute Idee !)

    siehe : https://www.autoitscript.com/cgi-bin/getfil…iTE4AutoIt3.exe

    Gruß Musashi

    86598-musashi-c64-png

    "Am Anfang wurde das Universum erschaffen. Das machte viele Leute sehr wütend und wurde allenthalben als Schritt in die falsche Richtung angesehen."

  • Musashi hat's erkannt:

    Die "Komplettversion" von SciTE läuft auf meiner Kiste nicht, darum arbeite ich bloß mit derabgespeckten Version, die zusammen mit AutoIt installiert wird.

    Ja, ich muss wohl langsam mal auf Win7 umsteigen ... :-/

    Trotzdem wäre es mein Wunsch, dass mein Programm auch unter Win XP läuft.

    Die Frage aus dem Startposting bleibt also bestehen, unabhängig von den massig erweiterten Features des SciTE-Editors.

    Ich code, also bin ich!

  • Ich möchte, für eine formatierte Debug-Ausgabe, den Namen der gerade aktiven Function ermitteln.

    Wie könnte das gehen?

    Lege doch einfach eine globale Variable an, in der du den Namen der jeweils aktiven Funktion speicherst, sobald du sie betrittst.

    Ist es innerhalb einer Function möglich, zu ermitteln, von welcher "höheren Function" sie aufgerufen wurde?

    Wenn du den Funktionsnamen der übergeordneten Funktion nicht als Parameter übergibst, hast du wohl keine Möglichkeit, ihn zu ermitteln.

    Du kannst aber ein globales Array anlegen, in dem du die Namen der Funktionen ablegst. Beim Betreten einer Funktion fügst du dann den aktuellen Namen hinzu und beim Verlassen entfernst du ihn und alle darauf folgenden wieder aus dem Array.

    So in etwa...

  • Beitrag wegen möglicher Redundanzen gelöscht

    2 Mal editiert, zuletzt von Tuxedo (23. November 2018 um 22:42) aus folgendem Grund: Laut TE ist mein Beitrag fürihn nutzlos, also hab ich ihn entfernt

  • Ich habs jetzt nur überflogen, aber

    Das merkt man, Tuxedo! :Face:

    Genau das, was ich bislang praktisch genau so mache und nun durch eine bessere Alternative ersetzt haben möchte, schlägst Du mir vor.


    Bittnuggers Vorschlag ist eine kompliziertere Variante, die hier einen kleinen Vorteil und da einen kleinen Nachteil mit sich bringt.

    Noch einmal:

    Der folgende Code bildet das Grundgerüst, wie jede Function meines Programm aufgebaut ist:

    C
    Func _User_Eingabefelder_leeren()
      output("_User_Eingabefelder_leeren", 1)
    
      ; Hier Code
      ; Hier Code
      ; Hier Code
    
      output("_User_Eingabefelder_leeren", -1)
    EndFunc ;==> _User_Eingabefelder_leeren()

    - Das ist simpel (sogar regelrecht primitiv) und funzt bestens.

    Was mich daran aber stört:

    Ich habe im obigen Code VIER MAL den Namen der Function stehen! Pure Redundanz!

    Ohne den auskommentierten Bereich hinter EndFunc steht der Name noch immer drei Mal im Code.

    Und es ist fehlerträchtig, weil ich für jede meiner ca. 40 Functions die jeweils zwei Zeilen mit "output()" von Hand anpassen muss.

    Es wäre viel schicker, wenn all die vielen Output-Zeilen jeweils identisch sein könnten, quer durch das ganze Programm.

    Was dazu geschehen müsste: Irgendein Zauber-Befehl müsste den Namen der Funktion, aus der heraus er aufgerufen wurde, ganz von allein ermitteln.

    Das würde gehen, wenn beim Erzeugen einer Function sozusagen ein Handle zurückgegeben werden würde, über das man an deren Namen heran käme.

    Mir ist aber kein solcher Weg bekannt.

    Ich code, also bin ich!

    Einmal editiert, zuletzt von Code-Jack (23. November 2018 um 22:30)

  • Ich würde das Pferd mal von hinten aufzäumen. In der Funktion ist dir nicht bekannt, wie der aktuelle Scope benannt ist. Beim Aufruf aber schon. Also würde ich schon den UDF-Aufruf über eine Zwischenfunktion erledigen, innerhalb derer ich diverse Debug-Daten ausgeben kann. Statt eines myFunc(1, $b) schreibe ich dann in meinem Beispiel c(myFunc, 1, $b).

    Die Zwischenfunktion muss leider so umständlich geschrieben werden, da AutoIt keine VarArgs-Definitionen unterstützt. Außerdem können so keine ByRef-Parameter oder Standardwerte für Parameter genutzt werden. Aber immerhin etwas.

  • Hallo Code-Jack !

    Ich habe aus Interesse etwas gegoogled, aber das Zauberwort '@FunctionName' auch nicht gefunden :P

    Hier ein weiterer Lösungsansatz (ev. Schwachsinn, aber das kannst Du ja beurteilen) :

    Nicht unähnlich der Idee von chesstiger , nur dass Du keine interne Zwischenfunktion verwendest, sondern den Quellcode mittels eines eigenen Tools bearbeitest.

    1.

    Zu Beginn deines Quellcodes definierst Du, wie von Bitnugger vorgeschlagen, eine globale Variable, z.B. : Global $sFunctionName = ''

    2.

    Du schreibst Dir mit AutoIt ein Hilfsprogramm, welches den jeweiligen Quellcode in ein Array einliest.

    Anschließend durchläufst Du das Array und suchst nach Zeilen die mit Func beginnen.

    Du filterst den Teil zwischen Func und der Klammer ( heraus ==> also den Funktionsnamen.

    (mögliches Leerzeichen vor der Klammer usw. ggf. entfernen)

    3.

    Nun fügst Du direkt hinter die aktuelle Zeile mit dem Schlüsselwort Func eine neue Zeile in das Array ein, z.B. :

    $sFunctionName = xxx ; GENERATED BY CODE-JACK

    wobei xxx der zuvor herausgefilterte Funktionsname ist.

    Hierbei z.B. den Sonderfall berücksichtigen, dass Funktionsparameter mehrzeilig angegeben werden können, mittels _

    Func _Example($sParam1, _

    $sParam2)

    Beispiel :

    Code
    Global $sFunctionName
    
    Func _User_Eingabefelder_leeren() 
    $sFunctionName = "Func _User_Eingabefelder_leeren"  ; GENERATED BY CODE-JACK
    
    output($sFunctionName, 1)
    ...
    output($sFunctionName, -1)
    EndFunc  ;==> _User_Eingabefelder_leeren()

    Anschließend speicherst Du das Array zurück in eine Datei (ggf. Kopie des Originals anlegen).

    Damit Du diesen Vorgang wiederholt ausführen kannst solltest Du prüfen, ob hinter der Func-Zeile bereits ein $sFunctionName existiert, damit keine Mehrfacheinträge entstehen. Zudem werden sicher noch weitere Prüfungen erforderlich sein.

    Die Erstellung eines solchen Tools ist natürlich einmalig recht aufwändig. Wahrscheinlich kann man so etwas besser über LUA machen, aber so arbeitest Du mit einem Werkzeug, welches du kennst und bei Bedarf selbst erweitern kannst.

    Wie gesagt, nur so eine Idee ;)

    Gruß Musashi

    86598-musashi-c64-png

    "Am Anfang wurde das Universum erschaffen. Das machte viele Leute sehr wütend und wurde allenthalben als Schritt in die falsche Richtung angesehen."

    Einmal editiert, zuletzt von Musashi (24. November 2018 um 09:34)

  • Hallo Code-Jack !

    Zu meinem Ansatz aus Beitrag #11 habe ich Dir mal ein quick&dirty Skript erstellt. Nicht die eleganteste Ausführung, aber als Beispiel wohl ausreichend ;)

    Teil 1 : der 'Parser'

    Teil 2 : ein Miniskript, welches durch den 'Parser' erweitert wird.

    Beide Dateien in ein Verzeichnis packen.

    Das Ergebnis wird in @ScriptDir & '\ParsefileSource-New.au3' abgelegt.

    Gruß Musashi

  • Sorry, aber ... neee.

    Keine einzige der in diesem Thread vorgestellten Lösungen gefällt mir.

    Da bleibe ich lieber bei meinem bisherigen Weg. Der ist zwar leicht unelegant, aber was soll man machen? AutoIt bietet halt nicht die nötige Funktion, um es besser machen zu können.

    Vielleicht kommt ja mal ein passendes AutoIt-Update ... (die Hoffnung stirbt zuletzt).

    Trotzdem habe ich aus allen Antworten etwas mitgenommen und bedanke mich bei Allen, die zu helfen versucht haben!

    Zum Abschluss hier noch ein direkt lauffähiges Beispiel, nach meinem Prinzip:

    Gegenüber meinen vorherigen Schnippseln habe ich die Ausgabe simplifiziert, ohne die vielen ...

    ;---------------\

    Blah

    Blahblah

    ;---------------/

    Solche Klammer-Konstrukte verwende ich im Quellcodes sonst recht häufig, als Ergänzung zu #Region. Aber ich habe inzwischen mit der formatierten Konselen-Ausgabe viel experimentiert und diese komische Einklammerung zumindest dort für verzichtbar befunden.

    Mein Datenbank-Programm schmeißt sogar regelrecht meterlange Logs aus und für mein Empfinden sind die glasklar zu lesen.

    Diese Art, Meldungen auszugeben, hilft mir sehr dabei, mein Programm aufgeräumt zu halten und zudem eine konsistente Benennung der Functions zu realisieren.

    Wenn man die Globale Variable $iLogprint auf 1 setzt, dann beschränkt sich die Ausgabe auf die reinen Ein-/Austritte der Functions. So erhält man ruckzuck einen kompakten Überblick über die Struktur der ganzen Aufrufe.

    Weil man die Ausgabe auch auf einen Schlag komplett ausschalten kann (per $iLogprint = 0), können die ganzen Ausgabebefehle einfach im Code stehen bleiben.

    Bei ConsoleWrite() hingegegen, würde man diese Zeilen wohl auskommentieren, wenn sie nicht mehr benötigt werden. Erstens um Zeit zusparen, zweitens um überflüssige Ausgaben zu unterdrücken.

    Aber bei meinem strukturierten output() ist das Auskommentieren IHMO nicht nötig, denn da gibt es keine zu späterem Zeitpunkt "überflüssigen", bloß verwirrenden Ausgaben, da alles in eine klare Struktur eingebettet ist.

    Und wie gesagt: Man kann die Ausgabe der Meldungen global abschalten (oder auch einschränken).

    Später baue ich noch etwas mehr Luxus ein. Zeitmessung und so. Aber im Moment bin ich zufrieden.

    Thema erledigt.

    Ich code, also bin ich!

  • Wenn du es gern komfortabler hättest... Ich habe mal Musashis Idee aufgegriffen und die Tracing-Funktion durch modifizieren des Skriptes in mein SynSug (Syntaktischer Zucker für AutoIt) integriert. Daher kannst du jetzt ohne zusätzlichen Aufwand Tracing nutzen, indem du nach der Installation in SciTE kurz Strg+Umschalt+F5 drückst. Einfacher geht's eigentlich kaum. Geht etwas am Sinn des Projektes vorbei, aber da war halt schon ein Integrationsskript für SciTE und ein Parser vorhanden, daher war der Rest ziemlich schnell programmiert. Alles grundsätzliche zu SynSug im Thread, der neue Code mit Tracing im git-Repo.

    Thread: SynSug - Syntaktischer Zucker für AutoIt (Update v1.1.0 Dictionaries)

    Das folgende Testskript erzeugt dann den nachstehenden Output:

    Code
    !TRACE> Entered function ROLLDICES().
    !TRACE-> Entered function ROLLDICE().
    !TRACE-> Leaved function ROLLDICE() after 0.0492307782073214 ms.
    !TRACE-> Entered function ROLLDICE().
    !TRACE-> Leaved function ROLLDICE() after 0.0185982939894325 ms.
    !TRACE-> Entered function ROLLDICE().
    !TRACE-> Leaved function ROLLDICE() after 0.0178689491271018 ms.
    !TRACE> Leaved function ROLLDICES() after 0.257458736402733 ms.

    Man kann sich jetzt über Tools > Syntactic Sugar (Debug to File) auch anschauen, was mein Parser daraus baut. Der relevante Ausschnitt:

  • Also das mit der Zeitmessung habe ich aufgegriffen und inzwischen integriert. Vielen Dank für diesen Input!

    Aber irgendwelche Routinen automatisch an meinem Code herummanipulieren zu lassen, geht für mich gar nicht!

    Mich nervt schon extrem diese Autoformatierung in SciTE! Die macht mir weit mehr Arbeit, als dass sie mir irgendeinen Nutzen bringt.

    Ich möchte meinen Code Byte für Byte eigenhändig eintippern und daran nicht die Spur "korrigiert" haben, da bin ich total konservativ.

    Und ich würde mich SEHR über den entscheidenden Tipp freuen, wie ich der Lite-Version von SciTE diese lästige Auto-Einrückung komplett abgewöhnen kann!

    Ich code, also bin ich!

  • Und ich würde mich SEHR über den entscheidenden Tipp freuen, wie ich der Lite-Version von SciTE diese lästige Auto-Einrückung komplett abgewöhnen kann!

    Suche mal in den Globalen Einstellungen (SciTEGlobal.properties) nach "indent.automatic=1" oder "indent."... oder "# Indentation"... wenn du globale Einstellungen ändern willst, kopierst du sie in die Benutzer-Einstellungen (SciTEUser.properties) und weist ihnen dort den gewünschten Wert zu - z.B.: "indent.automatic=0".

    Bei mir sind diese Dateien hier zu finden:

    c:\Program Files (x86)\AutoIt3\SciTE\SciTEGlobal.properties

    c:\Users\<UserName>\AppData\Local\AutoIt v3\SciTE\SciTEUser.properties

    Du wunderst dich, dass solche Einstellungen nicht im SciTE-Menu zu finden sind? Ganz einfach: Weil sie sehr selten bis niemals geändert werden... du bist also in gewisser Weise eine Anomalie... :rofl:

    Einmal editiert, zuletzt von Bitnugger (25. November 2018 um 13:36)

  • Hallo Code-Jack !

    Da Du noch mit Windows-XP arbeitest, habe ich mögliche Unterschiede bzgl. der .properties-Dateien gechecked - siehe 2.

    1. Ab Windows 7 und der Komplettversion von SciTE :

    Hier kann man, wie von Bitnugger beschrieben, vorgehen, also :

    Globale Einstellungen von SciTE befinden sich in :

    C:\Program Files (x86)\AutoIt3\SciTE\SciTEGlobal.properties

    Ammerkung :

    Falls man unter einem anderen Basisverzeichnis installiert hat, z.B. C:\AutoIt , dann in

    C:\AutoIt\AutoIt3\SciTE\SciTEGlobal.properties

    Die User-Einstellungen von SciTE befinden sich in :

    C:\Users\<UserName>\AppData\Local\AutoIt v3\SciTE\SciTEUser.properties

    Öffnet man diese Datei (z.B. mit Notepad++) kann man im Bereich

    # Indentation

    ...

    indent.automatic=1

    ...

    indent.automatic=0 setzen. Sollte diese Einstellung nicht vorhanden sein, was per Default wohl der Fall ist, kann man sie einfügen.

    In der Vollversion von SciTE lassen sich diese Dateien aber auch direkt über das Menü editieren !

    -> SciTE starten

    -> auf Options / Open User Options File gehen

    -> nun ist SciTEUser.properties geöffnet

    oder

    -> auf Options / Open Global Options File gehen

    -> nun ist SciTEGlobal.properties geöffnet

    (siehe Grafik SciTEFull.png)

    2. Windows XP :

    Hier läuft es offensichtlich aber etwas anders :!:

    Glücklicherweise habe ich noch ein altes Notebook auf dem Windows-XP-Home(SP3) installiert ist, und das nie zuvor ein AutoIt gesehen hat :P.

    Ich habe eine aktuelle 'Full'-Installation (3.3.14.5) ausgeführt, also die Version mit 'SciTE-Lite'.

    Zuerst fällt auf, dass weder eine SciTEGlobal.properties noch eine SciTEUser.properties vorhanden ist !

    Du kannst aber auch bei 'SciTE-Lite' über das interne Menü gehen.

    (siehe Grafik SciTELite.png)

    Beide Dateien sind leer, und werden erst angelegt, wenn Du ein SAVE machst. Danach findest Du die (immer noch leeren) Dateien in :

    C:\Dokumente und Einstellungen\<Username>\SciTEGlobal.properties

    und

    C:\Dokumente und Einstellungen\<Username>\SciTEUser.properties

    Nun kannst Du dort per Notepad++ (oder bereits vorher in SciTE selbst)

    # Indentation

    indent.automatic=0

    eintragen.

    Gruß Musashi

    86598-musashi-c64-png

    "Am Anfang wurde das Universum erschaffen. Das machte viele Leute sehr wütend und wurde allenthalben als Schritt in die falsche Richtung angesehen."

  • Große Klasse, Musashi!

    Da hast Du Dir ja richtig Arbeit gemacht, um es garantiert idiotensicher zu erklären!

    Die Lösung funktioniert. DANKE DANKE DANKE!

    Was mich wundert, ist wieso Ihr alle damit lebt, wie SciTE sich verhält?

    Ich stoße mich ja dauernd daran:

    1. Am Ende einer horizontal bestens positionierten Zeile drücke ich Enter. Dabei rückt DIESE Zeile ein Stück nach links! :(
    2. Der Cursor steht ganz links und ich drücke Enter, um eine Leerzeile einzufügen. Wieder verrückt die (bestens ausgerichtete) Zeile, in der der Cursor steht (stand).
    3. ... und weitere Späße dieser Art.

    Und besonders ulkig: Es passiert nicht immer, nur fast immer.

    Ich verbrachte bisher fast mehr Zeit damit, diese kruden Auto-Einrückungen wieder von Hand zu korrigieren, als mit dem eigentlichen Eintippern meines Codes. Da mache ich doch lieber gleich alles von Hand!

    Ich programmierte bisher:

    1. Auf dem ATARI, in GFA-Basic (lang ist's her!).
    2. auf dem Psion Serie 3 und später dem Psion Serie 5, jeweils in OPL.
    3. Auf dem PC etwas in Delphi.
    4. Später auf dem PC jede Menge in VB.Net.
    5. Zwischendurch auch etwas in Arduino C.
    6. Reichlich in BASCOM, dem Basic-Dialekt für Atmel AVR-Controller.

    ... ganz frisch bin ich also nicht dabei. Aber noch niemals habe ich einen Codeeditor erlebt, der so ein sonderbares Eigenleben austobt.

    Alle mir sonst bekannten Codeeditoren haben sich für mein Empfinden weitgehend vernünftig verhalten und den Code ziemlich gut eingerückt, so dass höchstens "EndIf", oder Schleifenenden, wie z. B. "Next" von Hand wieder passend hingerückt werden mussten.

    Die Logik vom SciTE erschließt sich mir nicht.

    Vielleicht verhält sich die Vollversion anders?

    Ich code, also bin ich!

  • Was mich wundert, ist wieso Ihr alle damit lebt, wie SciTE sich verhält?

    Ich lebe damit, weil es mir gefällt und ich damit umgehen kann.

    Am Ende einer horizontal bestens positionierten Zeile drücke ich Enter. Dabei rückt DIESE Zeile ein Stück nach links!

    Kann ich nicht reproduzieren.


    Der Cursor steht ganz links und ich drücke Enter, um eine Leerzeile einzufügen. Wieder verrückt die (bestens ausgerichtete) Zeile, in der der Cursor steht (stand).

    Dann stelle den Cursor an das Ende der Zeile und drücke Enter.

    Und besonders ulkig: Es passiert nicht immer, nur fast immer.

    Das Auto-Indent arbeitet nach festgelegten Regeln... entweder greift eine oder mehrere dieser Regeln, oder eben nicht, aber keinesfalls fast immer!

    Ich glaube aber, ich verstehe deine Problematik... eine Hilfe könnte sein, wenn du bei aktiviertem Auto-Indent darauf achtest, dass du keine offenen "Verschachtelungen" hast... z.B. ein If ohne das zugehörige EndIf.

    Ich arbeite in SciTE sehr viel mit Abbrevs... damit diese "Verschachtelungen" automatisch komplett eingefügt werden... hier ein paar Beispiele:

    ifthen [Leertaste drücken] ...erzeugt folgenden Code

    If Then

    EndIf

    ifelseif [Leertaste drücken] ...erzeugt folgenden Code

    If Then

    ElseIf False Then

    Else

    EndIf

    for0ubnext [Leertaste drücken] ...erzeugt folgenden Code (User-Abbrev)

    For $i = 0 To UBound() -1 Step 1

    Next


    Zudem macht es wenig Sinn, die Zeilen selbst positionieren zu wollen, wenn Auto-Indent aktiviert ist.

  • Große Klasse, Musashi!

    Da hast Du Dir ja richtig Arbeit gemacht, um es garantiert idiotensicher zu erklären!

    Die Lösung funktioniert. DANKE DANKE DANKE!

    Freut mich, dass alles geklappt hat :).

    Mit den .properties Dateien hatte ich mich bisher auch nicht groß auseinandergesetzt, von daher hat es mich selbst mal interessiert ( Bitnugger 's Beitrag war sozusagen der Auslöser). Da vermutlich noch einige Leute mit XP arbeiten, hilft dieser Teil ggf. auch anderen Lesern weiter.

    Was mich wundert, ist wieso Ihr alle damit lebt, wie SciTE sich verhält ?

    ...

    Vielleicht verhält sich die Vollversion anders ?

    Ich arbeite nur mit der 'Vollversion', kann also nicht beurteilen, ob die Lite-Version dbzgl. 'schlechter' ist. Gelegentliche Merkwürdigkeiten bei Einrückungen usw. gibt es dort auch, aber nichts, was mich extrem stören würde. Ist wahrscheinlich auch eine Frage der persönlichen Wahrnehmung ;).

    Gruß Musashi

    86598-musashi-c64-png

    "Am Anfang wurde das Universum erschaffen. Das machte viele Leute sehr wütend und wurde allenthalben als Schritt in die falsche Richtung angesehen."