Diskussion zu: FAQ SciTE Editor

  • Die Win 10 Shell kann mit Leerzeichen umgehen, wenn der Pfad mit Anführungszeichen umschlossen ist. Warum geht es mit dann mit LUA nicht?

    Das liegt nicht an Lua, sondern an der Funktion os.execute(), die ist halt nicht so intelligent. Lua selbst ist ergo nicht das Problem, da es mit shell.exec() ja auch mit Leerzeichen geht.

    aber die CMD-Fenster blitzen bei jedem SciTE-Start auf.

    Deshalb habe ich ja auch die shell.dll bzw. shell.exec() verwendet, denn da passiert das eben nicht. Vereinfacht ausgedrückt: os.execute() verhält sich wie eine Console/Eingabeaufforderung, shell.exec() wie ein Doppelklick auf dem Desktop.

    Warum benutzt du als Command "start"?

    Wenn du in der Eingabeaufforderung start /? eingibst, weißt du es... damit wird der Befehl in einem eigenen Fenster ausgeführt. Andernfalls ist die aufrufende Console/Eingabeaufforderung blockiert, solange der Befehl ausgeführt wird.

  • deshalb besser die shell verwenden. :P

    Kann jemand kurz die Schritte zusammenfassen, um die shell.dll zu verwenden?

    SciTEStartup.lua am Ende einfügen: shell.exec('F:\\SciTE_Helper\\SciTE_EnDisable_SaveBtn.exe') Richtig?

    shell.dll - Wo speichern und wo einbinden?

    Inzwischen sehe ich mir ShellExecute mal an. Da muss doch mehr als ein Command gehen, oder?

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

  • Wenn du in der Eingabeaufforderung start /? eingibst, weißt du es... damit wird der Befehl in einem eigenen Fenster ausgeführt. Andernfalls ist die aufrufende Console/Eingabeaufforderung blockiert, solange der Befehl ausgeführt wird.

    Das ist klar. Was ich meinte, die Console ist doch nicht die Windows-Shell, sondern der Explorer. Kann den os.exec kein anderes Command?

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

  • Kann jemand kurz die Schritte zusammenfassen, um die shell.dll zu verwenden?

    So habe ich das bei mir gemacht:

    SciTEUser.properties

    # Pfad für eigene Lua-Scripte - hier kommt auch die shell.dll rein (shell.zip hier entpacken)!

    lua.user.scripts.path=f:\\AutoIt\\AutoIt3_LuaScripts

    SciTEStartup.lua

    local sUserLua = props["lua.user.scripts.path"]

    ...

    require "shell"

    ...

    -- Diese Funktion unter der function LoadLuaFile einfügen...

    -- Calls LoadLuaFile() with directory from Lua-User-Script property 

    -- Also used from file "Ownhotkeys.lua" 

    -------------------------------------------------------------------------------- 

    function LoadUserLuaFile(file) 

    --~ LoadLuaFile(file, props["lua.user.scripts.path"] .. "\\") 

    LoadLuaFile(file, sUserLua .. "\\") 

    end -- LoadUserLuaFile() 

    --------------------------------------------------------------------------------

    ...

    -- Start up the events (Calls OnStartup()).

    EventClass:BeginEvents()

    ...

    -- Eigene Lua-Sccripts starten... z.B.:

    LoadUserLuaFile("InetSearch.lua") -- InetSearch.Engine() und InetSearch.Site() (by BugFix)

    ...

    shell.exec('F:\\SciTE_Helper\\SciTE_EnDisable_SaveBtn.exe')

  • DAS wird mir jetzt echt zu aufwendig für so eine popelige Funktionalität, die in anderen Editoren standard ist!

    Gerade als ich das abgesendet habe, hat Bitnugger die Anleitung gepostet. Deshalb will ich es noch einmal probieren.

    Vielen Dank!

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

  • Zwischendurch ein Fortschritt:

    Pfad mit Leerzeichen öffnen

    os.execute([["start C:\\Neuer" "Ordner\\Hallo" "Welt.exe"]])

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

  • Ein weiteres Problem ist, dass die SciTE_EnDisable_SaveBtn.exe den Ordner blockiert, aus dem das erste Script gestartet wird, nachdem sie läuft. Löschen, verschieben, umbenennen ist nicht möglich, solange die SciTE_EnDisable_SaveBtn.exe läuft. Weitere Ordner sind scheinbar nicht betroffen.

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

  • Ein weiteres Problem ist, dass die SciTE_EnDisable_SaveBtn.exe den Ordner blockiert, aus dem das erste Script gestartet wird, nachdem sie läuft.

    Dann versuche es mal mit dieser Version. Wie startest du die Exe?

    2 Mal editiert, zuletzt von Bitnugger (28. Juli 2019 um 03:13)

  • Dann versuche es mal mit dieser Version. Wie startest du die Exe?

    Leider keine Änderung. Funktioniert es denn bei dir? Lässt sich der 1. Ordner umbenennen, solange die Btn-exe läuft?

    Ich starte die Exe mit "start ... Btn.exe"

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

  • Also mit os.execute('start ...').

    Ich mache es mit shell.exec().

    Sorry, ja mit os.execute('start ...'). Die Shell.dll habe ich nicht hinbekommen.

    Ich versuche mal eine bessere Erklärung. Dabei nenne ich die "SciTE_EnDisable_SaveBtn.exe" einfach "Btn.exe".

    Die Btn.exe läuft nicht

    -> im Ordner 1 liegt ein au3.Script, das ich nun doppelklicke

    -> SciTE startet, die Btn.exe wird mitgestartet

    -> ich beende SciTE (Nun ist weder die au3 noch irgendwas anderes im Ordner 1 geöffnet.)

    -> ich versuche den Ordner umzubenennen, was aber nicht geht. (Win-Meldung: Blockiert.)

    Die Btn.exe läuft weiter

    -> Wenn ich im Ordner 2, 3, oder 4 usw. ein au3 öffne, ist alles in Ordnung.

    -> nach dem Schließen der au3 lässt sich jeder andere Ordner umbenennen.

    Es ist immer nur der Ordner betroffen, in dem ich die erste au3 mit SciTE öffne. Danach sind andere Ordner nicht betroffen, in denen ich eine au3 mit SciTE öffne und wieder schließe.

    Ich hoffe, es ist ein wenig verständlicher.

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

  • Ich hoffe, es ist ein wenig verständlicher.

    Ja, so kann ich es nachvollziehen.

    Dies lieg allerdings nicht an SciTE_EnDisable_SaveBtn.exe/os.execute()/shell.exec(), sondern daran, wie die SciTE.exe gestartet wird.

    Wird die SciTE.exe mit Doppelklick im Explorer gestartet und eine in der Datei SciTE.session vorhandene Datei geladen, kann das Verzeichnis, in dem sich diese Datei befindet, auch dann umbenannt werden, wenn die Datei in SciTE noch geöffnet ist, wobei auch die SciTE_EnDisable_SaveBtn.exe im Hintergrund laufen kann.

    Das Problem tritt nur dann auf, wenn du eine *.au3 mit Doppelklick oder via Kontextmenü im Editor öffnen willst. In dem Fall wird die SciTE.exe dann wohl von einer Console/Shell aus gestartet. Dann kann das Verzeichnis der ersten geöffneten Datei nur umbenannt/gelöscht werden, nachdem die SciTE.exe und auch die SciTE_EnDisable_SaveBtn.exe beendet wurden, weil erst dann die Console/Shell wieder geschlossen wird, mit der die SciTE.exe gestartet wurde.

    Das letzte Script mit dem /Init kannst du also wieder durch das alte ersetzen.

    Falls du es aber doch behalten willst, hier eine korrigierte Version:

  • Zitat von BugFix

    Starte die Exe mit dem Autostart und lass sie werkeln. CPU-Bedarf: nicht messbar.

    Habe ich gerade getestet, Ordner werden nicht blockiert. (Nachtrag: Ups, hatte das "nicht" vergessen!)

    Zitat von Bitnugger

    Falls du es aber doch behalten willst, hier eine korrigierte Version

    Der Effekt bleibt gleich, der "Ordner 1" wird blockiert. Ich vermute mal, das "korrigierte Version" bezog sich nicht darauf?

    Ich denke, an dieser Stelle sollten wir abbrechen. Der Aufwand übersteigt den Nutzen bei weitem. Auch wenns Spaß gemacht hat, daran herumzubasteln, will ich eure Zeit nicht länger dafür in Anspruch nehmen.

    Vielen Dank euch beiden! Vor allem Bitnugger, dass du soviel Mühe und Arbeit da reingesteckt hast!

    Bernd.

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

    Einmal editiert, zuletzt von Professor Bernd (28. Juli 2019 um 16:50)

  • Der Effekt bleibt gleich, der "Ordner 1" wird blockiert.

    Das wann und warum dieser Ordner blockiert wird und das es auch nichts mit der SciTE_EnDisable_SaveBtn.exe zu tun hat, habe ich ja im vorherigen Post beschrieben.

    Bei der ersten Version mit /Init konnte es sporadisch passieren, dass die SciTE_EnDisable_SaveBtn.exe am Ende doch noch mehrfach ausgeführt wird, was in der korrigierten Version nicht mehr möglich ist.

    Die Version mit /Init ändert zwar nichts an deinem Problem, sie hat aber den Vorteil, dass sie via Console (Lua/Cmd) aufgerufen werden kann und dies dann nicht blockiert.

  • Die Version mit /Init ändert zwar nichts an deinem Problem, sie hat aber den Vorteil, dass sie via Console (Lua/Cmd) aufgerufen werden kann und dies dann nicht blockiert.

    Was meinst du damit genau? Habs gerade nochmal getestet: Auch wenn ich in der SciTEStartup.lua os.execute('start ... /Init') benutze, wird "Ordner 1" blockiert.

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

  • Was meinst du damit genau?

    Wenn du die Version ohne /Init in einer Eingabeaufforderung startest, kannst du erst wieder einen Befehl eingeben, wenn die Exe beendet wurde, bei der Version mit /Init aber sofort.

    Habs gerade nochmal getestet: Auch wenn ich in der SciTEStartup.lua os.execute('start ... /Init') benutze, wird "Ordner 1" blockiert.

    Ja, aber nur wenn die SciTE.exe von einer Console/Shell aus gestartet wurde, was der Fall ist, wenn du einen Doppelklick auf eine *.au3 machst oder du bei einer *.au3 via Kontextmenü Edit Script auswählst.


    Wenn du SciTE aber mit einem Doppelklick im Explorer oder via Verknüpfung auf dem Desktop startest, kannst du das Verzeichnis auch umbenennen, wenn die Datei in SciTE noch geöffnet ist.

    Einmal editiert, zuletzt von Bitnugger (28. Juli 2019 um 23:29)

  • Ist schon alles nicht so einfach. Wie schon im anderen Thread geschrieben, probiere ich noch einen Workaround von BugFix:

    Oder wenn du wirklich möchtest, dass diese Datei ausschliesslich gestartet wird, wenn SciTE läuft, ersetze die SciTE.exe durch ein Startprogramm, dass SciTE.exe und das Skript aufruft.

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

    • Offizieller Beitrag

    Professor Bernd

    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.

    Ich habe mir angewöhnt:

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

    Das mach ich schon aus dem Grund, weil ansonsten die letzte Session gelöscht wird und nur die geöffnete Datei in SciTE offen ist. Ich bearbeite i.A. aber >5 Dateien in SciTE zeitgleich (u.A. Testumgebungen für Scriptlets und Lua). - Kann natürlich sein, dass ich das Verhalten per Option ändern kann. Aber das ist mir so in Fleisch und Blut übergegangen, dass es kein Problem ist.

    - au3 zum "mal schnell reinschauen": Explorer-Öffnen mit: NPP

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

    Lua unterstützt das Betriebssystem, auf dem es läuft, nur begrenzt (ist ja auch Open Plattform Software). Ich kann vollwertigen Zugriff also nur über die WinApi erlangen. Dafür gibt es die Bibliothek Alien, mit der sich Dateistrukturen und Funktionsaufrufe der Windows *.dll abbilden lassen.

    Wenn man das in AutoIt geschriebene Skript mal auf die verwendeten WinApi Funktionen herunterbricht, ergibt sich folgendes Vorgehen.

    Der schwierige Teil ist, dass die TBBUTTON-Struktur, die die Schaltflächeninformationen empfängt, in demselben Prozess zugewiesen werden muss, in dem sich die Symbolleiste befindet. Dazu muss ich:

    • die Prozess-ID der Symbolleiste abrufen / GetWindowThreadProcessId()
    • ein Handle für diesen Prozess erhalten / OpenProcess()
    • die Struktur innerhalb dieses Prozesses zuweisen / VirtualAllocEx()
    • die TB_GETBUTTON-Nachricht(en) an die Symbolleiste senden und den von VirtualAllocEx() zurückgegebenen Pointer angeben
    • die Strukturdaten wieder in Ihren eigenen Prozess kopieren, damit sie nach Bedarf verarbeitet werden können / ReadProcessMemory()
    • den zugewiesenen Speicher freigeben / VirtualFreeEx()

    In AutoIt passiert das für uns unsichtbar in der GuiToolbar.au3, die wiederum SendMessage.au3, Memory.au3 und Security.au3 verwendet.

    Es ist also nicht unbedingt kompliziert - eher arbeitsintensiv :P


    P.S.

    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.