Beiträge von Bitnugger

    Oder du benutzt die RunAs.exe... was die kann bzw. anders als die AutoIt-Funktion macht, erfährst du in der Eingabeaufforderung mit RunAs /?


    So mache ich es z.B. wenn ich die hosts editieren will:

    runas.exe /profile /env /savecred /user:administrator "c:\Program Files (x86)\TC UP\Plugins\Media\Notepad++\notepad++.exe c:\Windows\SYSTEM32\drivers\etc\hosts"

    Return FileExists($sDirPath) And StringInStr(FileGetAttrib($sDirPath), 'D')

    Du bist ein Bayer - Hosenträger und Gürtel, weil einem allein kann man ja nicht trauen! 8o


    Return StringInStr(FileGetAttrib($sDirPath), 'D')

    ..reicht doch völlig aus, oder bin ich noch nicht ganz wach?


    Code
    1. Global $sDirPath = 'f:\Audio\MP3\International\L\Lana Del Rey'
    2. ConsoleWrite("@@_Debug_line" & @TAB & @TAB & @ScriptLineNumber & " _DirectoryExists('"&$sDirPath&"') --> " & _DirectoryExists($sDirPath) & @LF & "!@ " & @TAB & "#Error: " & @error & @LF)
    3. Func _DirectoryExists($sDirPath)
    4. Local $sAttribs = FileGetAttrib($sDirPath)
    5. Return SetError($sAttribs = '' ? 1 : 0, 0, StringInStr($sAttribs, 'D') = True)
    6. EndFunc ;==>_DirectoryExists

    Ist es möglich, dass du dich irrst?

    Code
    1. Local $Var1
    2. Global $Var2
    3. ConsoleWrite(IsDeclared('Var1') & @CRLF)
    4. 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.

    - 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.

    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.

    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.

    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:

    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?

    Von haus aus kann ein Listview das nicht, aber mit Custom Draw bzw. Owner Draw geht das. In deinem Fall wäre Custom Draw die richtige Wahl. Dazu musst du die Message NM_CUSTOMDRAW auswerten und kannst dann z.B. das Icon mit _GUIImageList_Draw selbst an der gewünschten Position zeichnen. Im blauen Forum gibt es einige Bsp. dazu.

    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')

    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.

    Ich habe folgendes ausprobiert:


    os.execute('start "F:\\SciTE Helper\\SciTE_EnDisable_SaveBtn.exe"')

    Es erscheinen 2 CMD-Fenster und bleiben. SciTE wird geöffnet, die Btn-Exe wird NICHT gestartet.

    Im Prinzip schon richtig, aber wegen des Leerzeichen im Pfad funktioniert es nicht.


    Ändere den Pfad so um und es funktioniert:

    os.execute('start F:\\SciTE_Helper\\SciTE_EnDisable_SaveBtn.exe')


    PS: Mit shell.exec() geht es auch mit Leerzeichen...

    Man findet es nur, wenn man weiß wo's steht.

    Na ja, nicht wirklich. Dir fehlt es lediglich an Basiswissen, was SciTE und Lua angeht.

    Wikipedia: Lua (portugiesisch für Mond) ist eine imperative und erweiterbare Skriptsprache zum Einbinden in Programme, um diese leichter weiterentwickeln und warten zu können.


    In unserem Fall ist Lua halt in SciTE eingebettet und somit ergibt es sich doch quasi von selbst, dass ich in der Hilfe zu SciTE suchen muss, wenn es um Lua geht.


    Und dann steht da immer noch nicht, wie man es benutzt.

    Eigentlich doch...
    os.execute (command)

    This function is equivalent to the C function system. It passes command to be executed by an operating system shell. It returns a status code, which is system-dependent.


    Es sollte allerdings klar sein, dass man diesen Aufruf in einem Lua-Script ausführen muss.


    Um Lua-Skripte direkt in SciTE (mit F5) ausführen zu können, so wie ein AutoIt-Script, musst du folgende Zeilen in die SciTEUser.properties einfügen:

    Code
    1. # Lua-Skripte in SciTE ausführen - ja wie geil ist das denn?! ;-)
    2. command.go.$(file.patterns.lua)=dofile $(FilePath)
    3. command.go.subsystem.$(file.patterns.lua)=3


    Nun kannst du in SciTE (neu starten) eine neue Datei mit dem Namen Test.lua und folgenden Inhalt erstellen... speichern und dann mt F5 ausführen... und schon hast du dein erstes Lua-Erfolgserlebnis. ;-)

    Danke für die Erklärung mit os.execute! Ob du es glaubst oder nicht, ich habe gestern stundenlang erfolglos gesucht. Ich habe nur gefunden, dass es das gibt, aber wie und wo das gemacht wird, war nicht zu finden.

    Das findest du in der Hilfe zu SciTE4AutoIt3, die du mit Strg+F1 öffnen kannst.


    Die shell.dll stellt dir zusätzliche Funktionen zur Verfügung, so z.B. shell.exec(). os.* bzw. io.* und einige andere "Erweiterungen" werden bereits von SciTE geladen, doch um die shell-Funktionen (shell.*) nutzen zu können, musst du sie manuell einbinden, indem du an das Ende der SciTEStartup.lua die Zeile require "shell" hinzufügst.

    (Es will mir nicht behagen, dass 4 Dateien dafür nötig sind!)

    Es geht auch mit os.execute(), dann wird die shell.dll (shell.zip) nicht benötigt und es muss lediglich eine Zeile in der SciTEStartup.lua hinzugefügt werden, um die Exe zu starten.

    os.execute('start f:\\_Archive\\_Programmieren\\AutoIt3\\User\\BugFix\\SciTE_EnDisable_SaveBtn.exe')


    Von welchen 4 Dateien redest du?

    Jetzt muss ich nur noch herausfinden, wie ich an die IPadresse der geöffneten RDP-Session komme....