Diskussion zu: FAQ SciTE Editor

    • Offizieller Beitrag

    probiere ich noch einen Workaround von BugFix:

    Das enthält aber einen Stolperstein, den du im selbsterstellten Skript beachten musst:

    Wenn du als Verhalten festgelegt hast: Doppelklick auf au3 im Explorer öffnet die Datei in SciTE, musst du das in deinem Skript abfragen (*.au3 wird als Parameter des Aufrufs übergeben) und durchreichen an die echte SciTE.exe.

  • Ich werde mal die ganze Diskussion nicht löschen (könnte sicher interessant zum Nachschlagen sein), sondern in einen Diskussions-Thread zur FAQ-SciTE verschieben.

    Das war eine prima Idee! Zum einen hatte ich (und andere bestimmt auch?) im FAQ-Thread immer im Hinterkopf, den nicht zu sehr aufzublähen. Zum aderen dachte ich oft, dass das alles verloren geht. Deshalb einen herzlichen Dank fürs Erhalten der doch interessanten Infos!

    BugFix Den Thread hier zu finden ist gar nicht leicht. Könntest du den im Thread "FAQ - SciTE Editor" verlinken, z. B. Im Posting #11?

    Jeder hat halt seine eigenen Routinen, wie er arbeitet. Das führt dann auch zu unterschiedlichen Fragestellungen. Deine Vorgehensweise scheint etwas seltener zu sein, sonst hätte wohl schon früher jemand das als Problem bekundet.

    Diesen wichtigen Punkt möchte ich gerne aufgreifen.

    Eigentlich ist es mit großer Freude anzusehen, wenn jemand etwas seltenere Fragen stellt. Im Geschäftsleben habe ich schmerzhaft lernen müssen, dass es besser ist, wenn Kunden kommen und sich beschweren, als wenn sie nichts sagen und einfach nicht mehr kommen. Denn die hat man für immer verloren. ... Zudem hat man dadurch die Möglichkeit, etwas zu verbessern.

    Offen gesagt, war ich auch kurz davor, einfach aufzugeben. Was mich davon abgehalten hat, ist eure gute Gemeinschaft, die ich als freundlich und geduldig empfinde! Und glaubt mir, da sind bestimmt einige andere, die mitlesen und genauso denken. Lob an euch! :thumbup:

    Wenn jemand sagt: "Das geht nicht!" Denke daran: Das sind seine Grenzen, nicht deine.

  • Das enthält aber einen Stolperstein, den du im selbsterstellten Skript beachten musst:

    Wenn du als Verhalten festgelegt hast: Doppelklick auf au3 im Explorer öffnet die Datei in SciTE, musst du das in deinem Skript abfragen (*.au3 wird als Parameter des Aufrufs übergeben) und durchreichen an die echte SciTE.exe.

    Das stimmt! Stoperstein berüchsichtigt und erledigt! Ein Script dafür habe ich erstellt, das genau das durchführt.

    Zudem habe ich das Problem "Blockieren von Ordner_1" lösen können! Es war einfach das Arbeitsverzeichnis! Wenn man beim Aufruf von SciTE_EnDisable_SaveBtn.exe ein Arbeitsverzeichnis (den Ordner von SciTE_EnDisable_SaveBtn.exe) angibt, ist das Problem verschwunden.

    Ich habe mir angewöhnt:

    - au3 zum Bearbeiten öffnen: ausschließlich im geöffneten SciTE über Datei Öffnen

    Warum ist es übrigens so kompliziert aus SciTE heraus (also mit Lua Skript) einen Toolbarbutton zu manipulieren?

    Vielen Dank für die Informationen! Beide habe ich mir aufmerksam durchgelesen.

    Wenn jemand sagt: "Das geht nicht!" Denke daran: Das sind seine Grenzen, nicht deine.

    • Offizieller Beitrag

    Den Thread hier zu finden ist gar nicht leicht. Könntest du den im Thread "FAQ - SciTE Editor" verlinken, z. B. Im Posting #11?

    He, He - das war das Erste, was ich nach dem Verschieben der Posts in diesen Thread getan habe. Beide Threads sind wechselseitig miteinander verlinkt:

    Zitat von FAQ - SciTE Editor / Startpost


    (Die Frage-Antwort-Posts werde ich der Übersichtlichkeit halber danach entfernen --> verschieben: Link )

    Zitat von dieser Thread / Startpost

    Da in der FAQ ( Link ) Diskussionen entstehen

    8o

  • Bitnugger

    Ich habe deinen Code von SciTE_EnDisable_SaveBtn modifiziert, kannst du mal drüber schauen?

    Änderungen:

    - Das Tray-Icon aktiviert und eine OnExit-Funktion eingebaut.

    - Globale Variablen als Local deklariert.

    - <WinAPISys.au3> wird nicht mehr benötigt. (oder? Zumindest gibts bisher keine Fehler.)

    - Den "/Init" Teil habe ich vorerst weggelassen (dazu habe ich noch ein paar Fragen).

    Unverändert:

    - _CheckAndSetState()

    - _SciTE_EnDisable_SaveBtn_Exit()

    Die OnExit-Funktion löst das Enablen des Save-Buttons in allen SciTE-Fenstern aus (_SciTE_EnDisable_SaveBtn_Exit()). Davon ausgenommen habe ich das Auslösen beim Abmelden und Herunterfahren. Zum einen weil dabei sowieso alle SciTE-Fenster geschlossen werden, zum anderen um Fehler zu vermeiden, wenn die Btn-Exe versucht, Buttons in SciTE-Fenstern zu enablen, die zu dem Zeitpunkt evtl. nicht mehr existieren.

    Wenn jemand sagt: "Das geht nicht!" Denke daran: Das sind seine Grenzen, nicht deine.

    3 Mal editiert, zuletzt von Professor Bernd (2. August 2019 um 23:07) aus folgendem Grund: "OnExit" geändert zu "_OnExit".

  • - Globale Variablen als Local deklariert.

    Im globalen Kontext gibt es keine lokalen Variablen - die gibt es nur innerhalb von Funktionen! Deshalb sind folgende Zeilen nur Augenwischerei und sind eher nur verwirrend, da diese Variablen trotz des Local golbale Variablen sind (denn wären sie local, würde der DllCall($g_hUSER32, ... in der Funktion _CheckAndSetState() gar nicht funktionieren):

    Local $g_hUSER32 = DllOpen('user32.dll')

    Local Const $g_iIndexSave = 3

    $g_iIndexSave könntest du in der Funktion _CheckAndSetState() als locale Konstante deklarieren, $g_hUSER32 muss aber eine globale Variable bleiben, da sie auch in der Funktion _SciTE_EnDisable_SaveBtn_Exit() angesprochen wird.

    OnExit() ... eigene Funktionen solltest du zur besseren Unterscheidung immer mit vorangestelltem _ beginnen.

    - Den "/Init" Teil habe ich vorerst weggelassen (dazu habe ich noch ein paar Fragen).

    Ok, dann brauchst du auch die folgenden Includes nicht:

    #include <WinAPISys.au3>

    #include <WinAPIProc.au3>

    #include <Process.au3>

    Ja... bis auf das Local im globalen Space sieht alles gut aus... wobei die Funktion OnExit() nicht wirklich nötig ist, da die Funktionen _CheckAndSetState()/_SciTE_EnDisable_SaveBtn_Exit() eigentlich recht gut wasserdicht ist.

  • Im globalen Kontext gibt es keine lokalen Variablen - die gibt es nur innerhalb von Funktionen! Deshalb sind folgende Zeilen nur Augenwischerei und sind eher nur verwirrend, da diese Variablen trotz des Local golbale Variablen sind (denn wären sie local, würde der DllCall($g_hUSER32, ... in der Funktion _CheckAndSetState() gar nicht funktionieren):

    Ist es möglich, dass du dich irrst? Soweit ich es verstehe, ist eine lokale Variable durchaus ausreichend (siehe Script-Beispiel zu DllOpen)

    Local Const $g_iIndexSave = 3


    ... könntest du in der Funktion _CheckAndSetState() als locale Konstante deklarieren

    Eine Konstante in eine Funktion zu setzen, in der sie alle 500 Millisekunden aufs neue deklariert wird, erscheint mir nicht sehr sinnvoll. Deshalb denke ich, sie ist außerhalb der Funktion gut aufgehoben.

    OnExit() ... eigene Funktionen solltest du zur besseren Unterscheidung immer mit vorangestelltem _ beginnen.

    Gute Idee! Werde ich im Code von Posting #46 ändern. Auch versuche ich die Sachen dort zu ändern, die wir hier besprechen. Wenn alles funkioniert, kann BugFix vielleicht den Code in die "FAQ - SciTE Editor" übernehmen.

    ... wobei die Funktion OnExit() nicht wirklich nötig ist, da die Funktionen _CheckAndSetState()/_SciTE_EnDisable_SaveBtn_Exit() eigentlich recht gut wasserdicht ist.

    Die _OnExit-Funktion dient der leichteren Handhabung. Einfach auf das SysTray-Icon und "Exit" zu klicken und die Funktion "_SciTE_EnDisable_SaveBtn_Exit()" wird automatisch aufgerufen. Man braucht sich nicht um einen extra Aufruf zu kümmern.

    Wenn jemand sagt: "Das geht nicht!" Denke daran: Das sind seine Grenzen, nicht deine.

  • Ist es möglich, dass du dich irrst? Soweit ich es verstehe, ist eine lokale Variable durchaus ausreichend (siehe Script-Beispiel zu DllOpen)

    Hi Bernd !

    Wenn eine Variable im globalen Kontext eines Skriptes deklariert wird, ist es für AutoIt egal ob das Schlüsselwort Global oder Local verwendet wird. Beides wird als Global betrachtet.

    Das ist, wenn man so will, eine syntaktische Unsauberkeit des Interpreters ;).

    Im Skriptbeispiel ist der Kontext z.B. global !

    EDIT : Professor Bernd

    Umgekehrt ist die Deklaration mittels Global innerhalb einer Funktion allerdings keine gute 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 (2. August 2019 um 20:09) aus folgendem Grund: Antwort erweitert

  • Ist es möglich, dass du dich irrst?

    Code
    Local $Var1
    Global $Var2
    ConsoleWrite(IsDeclared('Var1') & @CRLF)
    ConsoleWrite(IsDeclared('Var2') & @CRLF)

    Ausgabe:

    1

    1

    Function IsDeclared

    $DECLARED_GLOBAL (1) for Global variable or variable declared outside functions.

    Eine Konstante in eine Funktion zu setzen, in der sie alle 500 Millisekunden aufs neue deklariert wird, erscheint mir nicht sehr sinnvoll.

    Konstanten werden vom Interpreter immer nur einmalig deklariert und der zugewiesene Wert kann auch nicht mehr geändert werden, auch wenn dies in einer Funktion passiert. Ähnlich funktioniert es mit Static Variablen, wobei du diesen aber neue Werte zuweisen kannst.

  • - Konstanten in einer Funktion deklarieren -> Alles klar -> Erledigt.

    - "Umgekehrt ist die Deklaration mittels Global innerhalb einer Funktion allerdings keine gute Idee !! -> Einverstanden, was Konstanten angeht. -> Erledigt. Bei Variablen sehe ich bei erster Betrachtung kein Problem. Im Gegenteil, es kann doch genau dafür gedacht sein, um den Wert einer globalen Variablen mittels einer Funktion zu setzen.

    Wenn eine Variable im globalen Kontext eines Skriptes deklariert wird, ist es für AutoIt egal ob das Schlüsselwort Global oder Local verwendet wird.

    Was verstehst du unter globalem Kontext?

    Wenn jemand sagt: "Das geht nicht!" Denke daran: Das sind seine Grenzen, nicht deine.

  • Habe mich eingelesen und bin zu folgender Schlussfolgerung gekommen.

    - Global: Bei Deklaration außerhalb von Funktionen -> Benutzung und Gültigkeit im ganzen Script möglich.

    - Global: Bei Deklaration innerhalb von Funktionen -> Benutzung und Gültigkeit im ganzen Script möglich?  (noch nicht klar)

    - Local: Bei Deklaration außerhalb von Funktionen -> Mogelpackung, weil eigentlich auch Global? (noch nicht klar)

    - Local: Bei Deklaration innerhalb von Funktionen -> Benutzung und Gültigkeit nur in der Funktion.

    Ist davon irgendwas richtig?

    Wenn jemand sagt: "Das geht nicht!" Denke daran: Das sind seine Grenzen, nicht deine.

    Einmal editiert, zuletzt von Professor Bernd (2. August 2019 um 22:59) aus folgendem Grund: Ist nun klar, siehe nächstes Posting.

  • Umgekehrt ist die Deklaration mittels Global innerhalb einer Funktion allerdings keine gute Idee !!

    - . . . -> Einverstanden, was Konstanten angeht. -> Erledigt. Bei Variablen sehe ich bei erster Betrachtung kein Problem. Im Gegenteil, es kann doch genau dafür gedacht sein, um den Wert einer globalen Variablen mittels einer Funktion zu setzen.

    Du hattest von der Deklaration innerhalb einer Funktion die Rede, ich hingegen von der Zuweisung. (Ich habe es in den Zitaten unterstrichen.) Gestern war sehr stressig, da ist der Groschen nicht gleich gerutscht. Eine Nacht darüber geschlafen und schon ist's besser. Jetzt habe ichs verstanden -> Erledigt.

    Wenn jemand sagt: "Das geht nicht!" Denke daran: Das sind seine Grenzen, nicht deine.

  • Ich hab da auch noch einen zu SciTE...

    Bei einem Ausdruck wird immer der Hintergrund (hellgrau) mit ausgedruckt. Das macht den Druck schlechter lesbar.

    So kann man's ändern:

    - SciTE im AdminModus starten (RechtsKlick, ausführen als..), sonst kannst Du die Datei nicht speichern

    - unter "Optionen" den Menupunkt "Open Global Options File" anklicken

    - in dieser Datei den Abteilung "# Printing" suchen und

    - den Eintag "#print.colour.mode=1" auf "print.colour.mode=3" ändern. Also die Raute rausnehmen und den Wert ändern

    - SciTE neu starten (ohne Admin) und einen sauberen Hintergrund haben:)

    Wenn Du's eilig hast - geh langsam...

    Einmal editiert, zuletzt von De Rand Ere (21. August 2019 um 23:17)

  • Sollte das nicht, wie in Post #2 beschrieben, einfach per Editor in den lokalen Einstellungen möglich sein?
    Vorteil: Keine Admin-Rechte notwendig. Wird durch eine neue SciTE-Version nicht überschrieben.

    Ich probiere das morgen gleich aus ;)

    • Offizieller Beitrag

    De Rand Ere

    Sämtliche properties Einstellungen, die man personifiziert, gehören in die SciTEUser.properties. Das Warum hat ja water schon erklärt. In der Rangordnung der Property Dateien geniessen die SciTEUser.properties eine höhere Priorität und überschreiben somit die Einstellungen Globaler Properties,

  • Da es nun stramm auf Weihnachten zugeht, hier schonmal meine Wunschliste. :D

    1. Ist das Bulk-Rename von Variablen (siehe hier) mittlerweile integriert worden?

    2. Mit check.if.already.open=0 in z. B. SciteUser.properties kann man SciTE veranlassen, Dokumente in mehreren SciTE-Instanzen (Fenster) zu laden, statt in mehreren Tabs. Leider verhindert SciTE dann nicht mehr, dass ein und das selbe Dokument mehrfach geöffnet wird. Wie kann man beides erreichen?

    3. Und zum Schluss: Im Output-Fenster kann man mit ConsoleWrite Meldungen ausgeben. Diese kann man farblich verändern, z. B. "- " Ein Minus und ein Leerzeichen (ohne Anführungszeichen) = orange Ausgabe. Gibt es eine Liste, welche Farbe man wie einstellen kann?

    Tja, jetzt wo ich's geschrieben habe, habe ich es auch in der AutoIt-Hilfe gefunden. :rolleyes: Das Beispiel dort funktioniert jedoch nicht ganz. Z. B. wie kriegt man pink, oder grau? Und wie das Springen in die angegebene Zeile, wenn man doppelklickt?

    4. Wie kann man die Unit finden, in der eine bestimmte Funktion implementiert ist? Beispiel: "FileExists".


    Edit: Zur besseren Übersicht Nummerierungen hinzugefügt und den Punkt 4 aus meinem anderen Posting in die Liste hier aufgenommen.

    Wenn jemand sagt: "Das geht nicht!" Denke daran: Das sind seine Grenzen, nicht deine.

    2 Mal editiert, zuletzt von Professor Bernd (13. September 2019 um 19:34)

    • Offizieller Beitrag

    Ist das Bulk-Rename von Variablen (siehe hier) mittlerweile integriert worden?

    Nein, hatte ich noch nicht wieder auf der Agenda.

    Mit check.if.already.open=0 in z. B. SciteUser.properties kann man SciTE veranlassen, Dokumente in mehreren SciTE-Instanzen (Fenster) zu laden, statt in mehreren Tabs. Leider verhindert SciTE dann nicht mehr, dass ein und das selbe Dokument mehrfach geöffnet wird. Wie kann man beides erreichen?

    Das Problem hatte ich noch nie. Eine zweite Instanz öffnen hat für mich nur dann Sinn, wenn ich ein bereits geöffnetes Skript parallel in anderen Abschnitten betrachten möchte. Somit ist es zwingend erforderlich, dass das selbe Dokument geöffnet werden kann.

    Anderes Einsatzgebiet einer anderen Instanz habe ich noch nicht gefunden. - Wozu brauchst du das?

    Z. B. wie kriegt man pink, oder grau? Und wie das Springen in die angegebene Zeile, wenn man doppelklickt?

    s. hier: Farbspielereien bei der Konsolenausgabe