Beiträge von BugFix

Zitat von Bitnugger

Hehe... $Wait_For_Return_Info wird doch für _GetCurrentFile() und _GetProperty($_sProperty) benötigt... wobei der Parameter in der Funktion gar nicht ausgewertet wurde!

Weil er nicht ausgewertet wird, hatte ich das auskommentiert. Für die Funktionalität ist der Parameter nicht erforderlich (habe ihn bisher nicht vermisst).

Die codepage Sachen sind praktisch.

Das Aktivieren der Tabs mittels Send() ist sicher nicht die optimale Lösung. Im Extension Interface gibt es die Funktion ActivateBuffer(index). Ich habe aber bisher keine Möglichkeit gefunden diese Funktion aufzurufen.

Zitat von Bitnugger

Ein spezieller Fall ist übrigens _OutputToConsole()... denn wenn direkt davor ein ConsoleWrite() ausgeführt wurde und danach nicht ein wenig gewartet wird (das Sleep() in Zeile 76), erscheint die Ausgabe von _OutputToConsole() vor der Ausgabe von ConsoleWrite()!

Ja, das ist ein bekanntes Verhalten. Wenn man mit dem Interface arbeitet, sollte man ausschliesslich über das Interface in die Konsole schreiben. ConsoleWrite wird wohl irgendwie in die Output-Pane geleitet, wenn das Interface gerade nicht beschäftigt ist (vermute ich).

Zitat von Bitnugger

Der Fehler ist in der Funktion SendSciTE_Command

OK, das hatte ich so von Jos übernommen.

Hier die Version mit zusätzlicher Funktion um das richtige DirectorExtension-Hwnd zu bekommen:

; by BugFix
Func _GetHwndDirectorExtension()
    Local $hActive = WinGetHandle('[ACTIVE]')
    Local $PIDActive = WinGetProcess($hActive)
    Local $aExtension = WinList("DirectorExtension")
    Local $PIDExt
    For $i = 1 To $aExtension[0][0]
        $PIDExt = WinGetProcess($aExtension[$i][1])
        If $PIDExt = $PIDActive Then Return $aExtension[$i][1]
    Next
EndFunc

; by Jos
Func SendSciTE_Command($_sCmd)     ;, $Wait_For_Return_Info = 0)
    Local $WM_COPYDATA = 74
    Local $WM_GETTEXT = 0x000D
    Local $WM_GETTEXTLENGTH = 0x000E224
    Local Const $SCI_GETLINE = 2153
;~     Local $Scite_hwnd = WinGetHandle("DirectorExtension") ; Get SciTE DIrector Handle
    Local $Scite_hwnd = _GetHwndDirectorExtension() ; Get SciTE DIrector Handle
    Local $My_Hwnd = GUICreate("AutoIt3-SciTE interface") ; Create GUI to receive SciTE info
    Local $My_Dec_Hwnd = Dec(StringTrimLeft($My_Hwnd, 2)) ; Convert my Gui Handle to decimal
    $_sCmd = ":" & $My_Dec_Hwnd & ":" & $_sCmd              ; Add dec my gui handle to commandline to tell SciTE where to send the return info
    Local $CmdStruct = DllStructCreate('Char[' & StringLen($_sCmd) + 1 & ']')
    DllStructSetData($CmdStruct, 1, $_sCmd)
    Local $COPYDATA = DllStructCreate('Ptr;DWord;Ptr')
    DllStructSetData($COPYDATA, 1, 1)
    DllStructSetData($COPYDATA, 2, StringLen($_sCmd) + 1)
    DllStructSetData($COPYDATA, 3, DllStructGetPtr($CmdStruct))
    DllCall('User32.dll', 'None', 'SendMessage', 'HWnd', $Scite_hwnd, _
            'Int', $WM_COPYDATA, 'HWnd', $My_Hwnd, _
            'Ptr', DllStructGetPtr($COPYDATA))
    GUIDelete($My_Hwnd)
EndFunc   ;==>SendSciTE_Command

Mal als Zusammenfassung das vorläufige Ergebnis:

- Ursache des Problems ist die Änderung im Original SciTE

- Diese Änderung ist eine Anpassung an die Änderungen in der API von Lua 5.2 und Lua 5.3

- Das Problem war auch Thema im Scintilla-Forum. Eine Lösungsvariante wurde dort beschrieben

- Um dieses Problem für uns zu fixen, ist eine Änderung beim Kompilieren der SciTE.exe erforderlich. Ich gehe davon aus, dass Jos das in der nächsten Version angeht.

Gib bitte mal ein Skriptbsp. & Beschreibung (welche Instanz hat Fokus, in welcher Instanz läuft das Skript).

Ich habe es so probiert:

- 2 offene Instanzen

- in Instanz #2 ein Skript ausgeführt mit _MenuCmd($IDM_CLEAROUTPUT)

- Output in Instanz #2 wird gelöscht

Da dies in Ausführung einer Au3 passiert, wird natürlich nach Skriptende in die Konsole geschrieben:

+>08:57:59 AutoIt3.exe ended.rc:0
+>08:57:59 AutoIt3Wrapper Finished.
>Exit code: 0    Time: 0.6022

Zitat von Bitnugger

wenn man mehrere SciTE-Instanzen benutzt, denn dann hat die falsche Instanz den Fokus.

OK, das werde ich mir mal anschauen, gibt bestimmt eine Lösung.

Zitat von Bitnugger

Dann werde ich jetzt mal austüfteln, wie ich die Ausgabe aus dem Script heraus gelöscht bekomme...

Mittels: SciTE-Interface

_MenuCmd($IDM_CLEAROUTPUT)

Ich habe ein Bug-Ticket erstellt.

Viel Hoffnung mache ich mir aber nicht. Erfahrungsgemäß werden Bug-Tickets von Usern hoppla-hopp mit dem nassen Lappen vom Tisch gefegt.

Das ist natürlich katastrophal. Ich verwende noch SciTE in der Version 3.6.6.0. Da die Folgeversionen keine (für mich) sinnvollen Änderungen enthalten, habe ich nie upgedatet.

Sollte das Entfernen von luaL_register Absicht sein, kann das nur bedeuten, dass es Jos nicht gefällt, dass SciTE4AutoIt durch diese Schnittstelle für Jedermann kreativ erweiterbar ist. Das wäre dann ein absolutes Armutszeugnis.

Aber, wie schon angesprochen: Es gibt keinen Grund diese SciTE-Version zu nutzen.

Die von mir verwendeten Funktionen der shell.dll kann man auch auf Systemaufrufe umleiten - hat aber den Nachteil, dass dabei kurz das CMD-Fenster aufpoppt.

Gravierender ist das, wenn man die gui.dll oder lfs.dll nutzt. Da gibt es dann keinen direkten Ersatz.

EDIT:

Übrigens ist auch in 3.6.6.0 der ausgegraute Menüeintrag "Clean Shift+F7" enthalten. Ist mir noch nie aufgefallen, da ich eigentlich nie die Menübefehle per Maus klicke, sondern "Clear Output Pane" mit "Shift+ F5" direkt aufrufe.

Ich habe jetzt mal in der 3.6.6.0 alle properties nach dem Menübefehl "Clean" durchsucht - den gibt es gar nicht! Nirgendwo erfolgt eine Zuweisung als Befehl und Shortcut. Hardcodiert?

In meinem Menü ist zumindest tatsächlich noch enthalten "Clear Output Shift+F5".

Muss man nicht verstehen.

Kannst ja mal einen Blick in mein Array-Tut werfen (Links gehen wieder). Dort habe ich das mit behandelt.

Hallo Mars

2 Dinge, die ich ändern würde:

- Du verwendest den Namen AutoItObject.au3 - denselben Namen, wie die UDF von prog@ndy & Co. Ich habe das bei mir jetzt umbenannt (Skript und include in der Ex) zu AU_Object.au3, damit ich keine Crashs bekomme, da ich auch die andere UDF verwende.

- Das zweite ist nicht zwingend, wäre aber nett.

Dadurch, dass du ausschliesslich auf die Dll-Struct-Konvention zurückgreifst, können Strings (variabler Länge) als Variablen nur über Pointer mit Verweis auf eine Struct gespeichert werden (oder natürlich gleich mit einem char-Array).

Hier würde ich vielleicht ermöglichen den Datentyp "str" zu verwenden (reiner Komfort!), mit einer maximalen Länge von z.B. 256 (als Konstante festlegen). Eingebunden bei dir, würde das so aussehen:

Global Const $__AUOBJ_STRLEN_MAX = 256

Func Var($sVarDeclaration)
    If Not IsString($sVarDeclaration) Then
        If Not $sVarDeclaration Then Return SetError(1, 0, 0)
        If IsPtr($sVarDeclaration) Then Return _ObjGetVars($sVarDeclaration)
        Return SetError(1,  0,  0)
    EndIf
    $sVarDeclaration = __str_to_char($sVarDeclaration)  ; check for "str" and replace with "char varname[maxlen]"
    HTAppendString($__a_TempStorage, 'Vars', $sVarDeclaration & ';')
EndFunc

Func __str_to_char($sVarDecl)
    Local $aDecl = StringRegExp($sVarDecl, '(\S+)\s+([^;\s]+);?', 3)
    Local $sRet = ''
    For $i = 0 To UBound($aDecl) -1 Step 2
        If $aDecl[$i] = 'str' Then
            $aDecl[$i] = 'char'
            $aDecl[$i +1] &= '[' & $__AUOBJ_STRLEN_MAX & ']'
        EndIf
        $sRet &= StringFormat('%s %s;', $aDecl[$i], $aDecl[$i +1])
    Next
    Return StringTrimRight($sRet, 1)
EndFunc

;=======================================TEST
Local $s = 'int x;int y;str name'
ConsoleWrite(__str_to_char($s) & @CRLF)
;===========================================

Das wars auf den ersten Blick - ich teste mal weiter.

EDIT:

Hab mal ein bischen gespielt: Sehe ich das richtig, man kann auf die Properties (Var) nicht mit der Syntax Wert = obj.property zugreifen, sondern muss für jede Wertabfrage eine eigene Methode erstellen?

Class('Test')

    Var('int a')

    Func Test_Create($this)
        Local $thisVars = Var($this)
        $thisVars.a = 0
    EndFunc

    Method('Test_Set_a', 'int')
        Func Test_Set_a($this, $val)
            Local $thisVars = Var($this)
            $thisVars.a = $val
        EndFunc
    EndMethod()

    Method('Test_Get_a')
        Func Test_Get_a($this)
            Local $thisVars = Var($this)
            Return $thisVars.a
        EndFunc
    EndMethod('int')

EndClass()


$oTest = New('Test')
$oTest.Set_a(5)

;~ ConsoleWrite($oTest.a & @CRLF)  ; FAIL
ConsoleWrite($oTest.Get_a & @CRLF)

Wonach ich noch gesucht habe: Wie kann ich den Classennamen eines Objektes abfragen oder ist das nicht vorgesehen? Dann vielleicht Standard-Property __class immer definieren?

Vielleicht auch ganz nützlich: New() mit einem optionalen Parameter für einen Namen ausstatten. Bedingt dann natürlich, dass eine Variable (z.B. __name) automatisch immer mit erstellt wird.

Das waren jetzt Punkte, die ich aus der Gewohnheit als recht angenehm empfinde.

Wenn du mit deiner UDF, die dir gesteckten Aufgaben abarbeiten kannst, ist das natürlich auch OK. Wir können ja bei Bedarf auch selber Hand anlegen.

EDIT 2:

wg. DllCallback: ByRef finde ich da jetzt nicht sehr aufwändig, muss man halt den Wert vor und nach dem Call covern (OK, ist kein echtes ByRef, da der Wert der Variablen über die Strukt transferiert werden muss):

Local $iCallback = DllCallbackRegister('Test', 'uint', 'ptr')
ConsoleWrite('CallbackRegisterError: ' & @error & @CRLF)

Local $a1 = 5
Local $tCB = _SetCallbackVal($a1)

If $iCallback Then
    DllCallAddress('uint', DllCallbackGetPtr($iCallback), 'ptr', DllStructGetPtr($tCB))
    $a1 = _GetCallbackVal($tCB)
    ConsoleWrite('Nach dem Call: ' & $a1 & @CRLF)
    DllCallbackFree($iCallback)
EndIf

Func Test($ptr)
    Local $v = DllStructCreate('int a', $ptr)
    $v.a += 1
    ConsoleWrite('im Call: ' & $v.a & @CRLF)
EndFunc

Func _SetCallbackVal($val)
    Local $t = DllStructCreate('int a')
    $t.a = $val
    Return $t
EndFunc

Func _GetCallbackVal($t)
    Return $t.a
EndFunc

Ich hatte das Problem 2013 mal im EN-Forum gepostet, gab aber keine Lösung. https://www.autoitscript.com/forum/topic/14…arameter-byref/

Solche Konstruktion möchte ich realisieren.

Kann diese UDF Objekte ByRef behandeln? Das war ein Malus in der existierenden AutoItObject.au3.

Dann könnte ich endlich mal mein Gatter Projekt ans Laufen bringen. (auch wenn das in erster Linie eine Spielerei ist)

Zitat

Dafür braucht es keine zusätzlichen lua scripte

Schon klar, für jene, die diesen Weg nutzen ist das Skript ja auch nicht gedacht (ich verstehe auch nicht, warum man sich abwertend zu etwas äußert, für das man selbst keine Verwendung hat). Aber all jene, die im geöffneten SciTE ein neues Skript erstellen wollen mit der eingefügten Option, ist es eine Hilfe.

Zitat von Mars

ich habe nirgends eine Einstellung gefunden bei der etwas als Start- oder Endpunkt zum ausklappen festgelegt wird.

Das geht auch nicht über properties. Dazu benötigst du ein Skript, in dem du die folgenden Funktionen des SciTE-Lua-Interface benutzen kannst.

# Set the fold level of a line.

# This encodes an integer level along with flags indicating whether the

# line is a header and whether it is effectively white space.

set void SetFoldLevel=2222(int line, int level)

# Retrieve the fold level of a line.

get int GetFoldLevel=2223(int line,)

# Find the last child line of a header line.

get int GetLastChild=2224(int line, int level)

# Find the parent line of a child line.

get int GetFoldParent=2225(int line,)

Ich muss mal suchen nach meinem Versuch einen Lexer in Lua zu schreiben, da hatte ich das mal getestet. Dann könnte man einen Pseudo-Lexer schreiben, der sich auf minimale Funktionen beschränkt.

Mars

Folgende Editorfunktionen sind dazu in SciTE integriert:

editor.FoldExpanded[int line] = bool expanded [RW] Show the children of a header line

editor.FoldParent[int startLine] = int line [RO] Find the parent line of a child line

editor.FoldLevel[int line] = int level [RW] Set the fold level of a line. This encodes an integer level along with flags indicating whether the line is a header and whether it is effectively white space

FoldLevel setzt sich aus diesen Konstanten zusammen

enu FoldLevel=SC_FOLDLEVEL

val SC_FOLDLEVELBASE=0x400

val SC_FOLDLEVELWHITEFLAG=0x1000

val SC_FOLDLEVELHEADERFLAG=0x2000

val SC_FOLDLEVELBOXHEADERFLAG=0x4000

val SC_FOLDLEVELBOXFOOTERFLAG=0x8000

val SC_FOLDLEVELCONTRACTED=0x10000

val SC_FOLDLEVELUNINDENT=0x20000

val SC_FOLDLEVELNUMBERMASK=0x0FFF

Vermutlich auch erforderlich:

editor:SetFoldFlags(int flags) Set some style options for folding

Flags:

enu FoldFlag=SC_FOLDFLAG_

val SC_FOLDFLAG_LINEBEFORE_EXPANDED=0x0002

val SC_FOLDFLAG_LINEBEFORE_CONTRACTED=0x0004

val SC_FOLDFLAG_LINEAFTER_EXPANDED=0x0008

val SC_FOLDFLAG_LINEAFTER_CONTRACTED=0x0010

val SC_FOLDFLAG_LEVELNUMBERS=0x0040

Kannst ja mal experimentieren.

EDIT:

Zum Kombinieren der Flags wirst du eine BitOR-Funktion benötigen. Diese hatte ich mal in Lua geschrieben

local function BitOR(...)
    local param = {...}
    local function bitOr(a,b)
        local p, c = 1, 0
        while a + b > 0 do
            local ra, rb = a % 2, b % 2
            if ra + rb > 0 then c = c + p end
            a, b , p = (a - ra)/2, (b - rb)/2, p*2
        end
        return c
    end
    local ret = 0
    for _, val in pairs(param) do
        ret = bitOr(ret, val)
    end
    return ret
end

Zitat

Ein vorhandenes Template könnte man mit LUA automatisch einfügen, wenn eine leere Datei gespeichert wird.

Dann brauchte man, genau wie jetzt, ein zusätzliches Lua Skript.

Da wäre es doch überlegenswert, optional die Informationen, die im Template sind, auch hiermit einfügen zu lassen.

Ich persönlich habe noch keinen Bedarf gehabt das Template zu nutzen. Wenn ich eine UDF oder ein Programm erstellt habe, schreibe ich zum Abschluss sowieso detaillierte Erklärungen zum Skript. Sinnvoller wäre da (für mich), das Template einzufügen, wenn man fertig ist. Dann kann man automatisiert eine Funktions - und Parameterübersicht einfügen.

Ist halt alles Geschmackssache - alles ist möglich.

Zitat von A55

Ist es möglich, Teile eines AutoIt-Scriptes auszuführen, indem man die Zeilen markiert, die ausgeführt werden sollen?

In der Standardinstallation - Nein.

Aber, wenn du mein SciTE-AdOn "OwnHotkeys" installierst, kannst du das tun.

Dazu wird bei Ausführen des Hotkeys der markierte Code (inkl. der Includedateien des Skriptes) in eine temporäre au3-Datei geschrieben und sofort gestartet.

Zitat

Was spricht denn dagegen?

Dann müsste man neue Skripte immer über das Template erstellen, statt aus SciTE heraus - habe ich z. B. noch nie gemacht.

Aber natürlich kann man das als zusätzliche Option auch verwenden, damit man über das Kontextmenü des Explorers neue Skripte mit Opt erstellen kann.

Zitat von Bitnugger

Kannst du in dem TimeStamp-Skript noch eine Option einbauen, damit es auch mit Python-Scripts funktioniert?

SetTimeStamp.py=1

Erledigt.

Das Optionsskript habe ich jetzt erweitert.

Falls ihr das TimeStamp-Skript auch verwendet, könnt ihr nun wählen, ob die Option in Zeile 1 oder erst nach dem TimeStamp (und der folgenden Leerzeile) eingefügt wird. Finde ich optisch ansprechender.

Aktuelle Version: v 0.2

Nach langer Zeit etwas Neues (v 1.4):

- einen Fehler behoben (Event wurde genutzt statt Event Class - allerdings nur problematisch, wenn man den Fehler nochmal macht, dann wird nur eine Funktion ausgeführt)

- Umbau der Funktion, jetzt kpl. gesteuert über die Properties, auf beliebig viele Dateitypen erweiterbar. BITTE BEACHTEN: PROPERTIES MÜSSEN GEÄNDERT WERDEN.

(s. Startpost)

So, da hatte ich mir ja ein Ei gelegt - zu lange keine Lua-Skripte mehr geschrieben.

Ich habe sowohl im TimeStamp-Skript, als auch in diesem Skript vergessen, eine neue Event-Klasse anzulegen für das verwendete Ereignis und die Funktionsaufrufe direkt in das zentrale Ereignis eingesetzt. Und da kann natürlich nur ein Wert landen - immer der letzte.

Ich habe das jetzt hier korrigiert und auch die Property entsprechend Bitnugger 's Vorschlag erweitert.

EDIT: Ich hatte gerade bemerkt, dass mein Lua-Skript im Editor noch nicht gespeichert war. Somit kann es sein, dass die hochgeladene Version noch einen Fehler hat. Habe jetzt die letzte Version geladen.

Übrigens, wer die TimeStamp.lua nutzt - bitte gleich mal am Skriptanfang ändern

-- declare table to hold helper functions
local f = {}

f.TimeStamp = EventClass:new(Common)

-- BEFORE SAVE==============================================BEGIN
function f.TimeStamp:OnBeforeSave(fname)
    local tFile = {Dir = props['FileDir'], Name = props['FileName'], Ext = props['FileExt']:lower()}
    if tFile.Ext == nil or (tFile.Ext ~= 'au3' and tFile.Ext ~= 'lua') then return end
    local stamp = tonumber(props["SetTimeStamp."..tFile.Ext])
    if stamp == 1 then f.InsertTimestamp(tFile) end
end
-- BEFORE SAVE================================================END