Beiträge von BugFix

Alles in einem Rutsch:

Local $s = _
"0 0 0 An explosion of lava ... by D. Egnor" & @CRLF & _
"60 60 60" & @CRLF & _
"64 60 60" & @CRLF & _
"72 60 60" & @CRLF & _
"76 56 56" & @CRLF & _
"100 48 48" & @CRLF & _
"108 48 48" & @CRLF & _
"112 44 44" & @CRLF & _
"212 12 12" & @CRLF & _
"224 8 8" & @CRLF & _
"232 8 8" & @CRLF & _
"236 4 4" & @CRLF & _
"244 4 4" & @CRLF & _
"252 12 0" & @CRLF & _
"252 20 0" & @CRLF & _
"252 28 0" & @CRLF & _
"160 0 0" & @CRLF & _
"156 4 4" & @CRLF & _
"152 4 4" & @CRLF & _
"148 8 8" & @CRLF & _
"140 12 12" & @CRLF & _
"104 32 32" & @CRLF & _
"100 36 36" & @CRLF & _
"100 36 36" & @CRLF & _
"96 40 40" & @CRLF & _
"88 44 44" & @CRLF & _
"60 60 60" & @CRLF & _
"60 60 60"

Local $sResult = StringRegExpReplace($s, '(?m)(\d+)\s+(\d+)\s+(\d+)(\D*)', '\1 \2 \3' & @CRLF)
ConsoleWrite($sResult & @CRLF)

Bitnugger Klingt im ersten Moment als würde es das gewünschte tun, aber:

Zitat von Attachments Processor - Features

• zieht die angefügte Dateien aus Emailnachrichten heraus, speichert sie auf einem Datenträger und ersetzt die herausgezogene Datei durch einen Link oder eine Beschreibung in Textform;

Niemand nutzt heute nur noch EINEN PC um auf seine eMails zuzugreifen. Wenn ich mit dieser Erweiterung den Anhang am Desktop-PC herunterlade, ist dieser nicht mehr in der Mail! Wenn ich dann von unterwegs mit dem Laptop denselben Anhang nochmals benötige, finde ich nur den Link zum lokalen Speicherplatz des Desktop-PC. Das ist ja mal an Idiotie nicht zu überbieten.

"Wenn du willst, dass es richtig gemacht wird, mach es selbst!" - Der Spruch ist immer wieder war.

Vielleicht schreibe ich mir tatsächlich selbst diese Erweiterung für Mozilla Thunderbird. JS ist zwar nichts, was ich sonderlich mag, aber wenn es der Problemlösung dient...

Eigentlich sollte man denken, dass eine Verwaltung heruntergeladener Anhänge in einem Mailprogramm etwas Selbstverständliche ist. (jedenfalls war ich so naiv)

Aber wenn meine erfolglose Suche korrekt war, gibt es exakt NULL Clients, die ein solches Feature besitzen.

Zur Begriffsklärung, was ich von einer solchen Verwaltung erwarte:

In der Mail selbst, oder einer zusätzlichen Spalte der Auflistung, wird ein LINK ZUM DOWNLOADORT hinterlegt. Warum? - Mehrfachdownloads vermeiden, nicht ewig grübeln "unter-welchem-Pfad-habe-ich-den-dämlichen-Anhang-bloß-gespeichert".

Das ist schon alles! - Und NIEMAND hat sowas bisher integriert.

Natürlich könnte ich eine externe Lösung z. B. via Sqlite basteln, aber es wäre wirklich sinnvoll, wenn es integriert wäre.

Sollte ich also nur zu blöd zum Suchen gewesen sein, wäre ich dankbar für jede Erleuchtung.

Zitat von ruby

Ist es denn prinzipiell Möglich mehrere Picker(diese rautenförmigen Dinger) in den Gradientenverlauf einzugeben und deren Farben zu ändern um dann den Verlauf als rgb zu errechnen?

Ich würde so vorgehen, da ein beidseitig verschiebbarer Slider in AutoIt nicht existiert:

- 1. Slider links beginnend oben + davor ein kleines quadratisches Label für aktuelle Farbe (Ersatz für die Raute)

- Picture Ctrl (für Gradient) darunter

- 2. Slider rechts beginnend unten + dahinter ein kleines quadratisches Label für aktuelle Farbe

- Dann die Raster-Ctrl für die Vorgabefarben (ich würde da Label nehmen)

Auswertung:

- Klick auf Label für aktuelle Farbe links, dann Klick auf Vorgabefarbe --> Label einfärben --> Gradient mit geänderter Anfangsfarbe setzen

- Klick auf Label für aktuelle Farbe rechts, dann Klick auf Vorgabefarbe --> Label einfärben --> Gradient mit geänderter Endfarbe setzen

- Bei Verschieben der Slider entsprechend den Farbwert anpassen (musst du dir eine Routine für schaffen) und Gradient neu zeichnen)

Hier mal, wie du den Gradienten mittels Funktion zeichnen kannst. An dem Rest probier dich erst mal selbst.

#include <GUIConstantsEx.au3>
#include <WinAPIGdi.au3>

Global $iW = 580, $iH = 20
Global $hGui = GUICreate('Gradient - Test', 600, 300)
Global $hGradient = GUICtrlGetHandle(GUICtrlCreatePic('', 10, 35, $iH, $iW))

_SetGradient($hGradient, 0x08FF00, 0xFFFF00, $iW, $iH)

GUISetState()

While True
    Switch GUIGetMsg()
        Case -3
            Exit
    EndSwitch
WEnd

Func _SetGradient($_hGradient, $_iColTop_Left, $_iColBottom_Right, $_width, $_heigth)
    Local Static $iWidth = $_width
    Local Static $iHeight = $_heigth
    Local $aVertex[2][3] = [[0, 0, $_iColTop_Left], [$iWidth, $iHeight, $_iColBottom_Right]]

    ; Create gradient
    Local $hDC = _WinAPI_GetDC($_hGradient)
    Local $hDestDC = _WinAPI_CreateCompatibleDC($hDC)
    Local $hBitmap = _WinAPI_CreateCompatibleBitmapEx($hDC, $iWidth, $iHeight, 0xFFFFFF)
    Local $hDestSv = _WinAPI_SelectObject($hDestDC, $hBitmap)

    _WinAPI_GradientFill($hDestDC, $aVertex, 0, 2, True)

    _WinAPI_ReleaseDC($_hGradient, $hDC)
    _WinAPI_SelectObject($hDestDC, $hDestSv)
    _WinAPI_DeleteDC($hDestDC)

    ; Set gradient to control
    _SendMessage($_hGradient, $STM_SETIMAGE, 0, $hBitmap)
    Local $hObj = _SendMessage($_hGradient, $STM_GETIMAGE)
    If $hObj <> $hBitmap Then
        _WinAPI_DeleteObject($hBitmap)
    EndIf
EndFunc

Ich hab mal einen Colormixer erstellt. Vielleicht findest du dort Inspiration.

Zitat von Bitnugger

Ich habe nichts geladen... das local core = require "alien.core" steht so in der alien.lua drin,

Ist mir schon klar. Die Zeile local core = require "alien.core" wird in der Verarbeitung von require zu local core = require "alien" eingedampft. Ob der require Befehl in der alien.lua so gewollt oder nur ein Schreibfehler war, ist unklar. Durch das rekursive Laden sollen wohl die Alien-Funktionen im eigenen Modul verfügbar sein (könnte ich mir vorstellen, ist aber nur geraten).

Zitat von Bitnugger

Der stammt nicht von mir, sondern steht in der alien.lua drin und weil der Aufruf funktioniert, kann er nicht falsch sein, oder?

Laut Regeln für die Verwendung von Require geht das nicht - und tut es auch nicht! Was du geladen hast, ist nicht die core.dll, sondern alien.

Die core.dll kann in SciTE nicht geladen werden.

Edit: Ich habe jetzt aber korrigiert, dass require mit Dateiendung erkannt wird.

Zitat von Bitnugger

Richtig wäre:

tPathes[1] = f:\\AutoIt\\AutoIt3_LuaScripts\alien\core.lua

Nein, das ist absolut falsch. Regeln für die Registrierung der Dateien:

REGISTRIERTER_ORDNER\BIBLIOTHEK\BIBLIOTHEK.lua oder

REGISTRIERTER_ORDNER\BIBLIOTHEK.lua

Identisch für Dll-Bibliotheken.

Zitat

Die Art der Registrierung ermöglicht, dass die Dateien direkt im benannten Pfad gespeichert sind oder in einem Unterordner, der denselben Namen wie die Datei trägt

Dein Aufruf: require "alien.core" war also schon falsch, weil es diese Bibliothek nicht gibt. Require kann nur den Namen der Bibliothek, aber keinen Pfad enthalten!

core.lua ist keine require-Datei. Die tatsächlich existierende Datei wäre sowieso die core.dll. Sie wird intern von Alien aufgerufen und ist im Alien-Ordner abgelegt. Erklärung s. hier

Mit meinem Skript stelle ich aus allen registrierten Pfaden mögliche Dateinamen der Form BIBLIOTHEK.lua zusammen. Dann prüfe ich, ob eine dieser Dateien tatsächlich existiert. Ist das der Fall, ist es eine Lua Datei und wird geöffnet, anderenfalls muss es eine Dll sein und nur eine Info wird in die Konsole ausgegeben.

Zitat von Bitnugger

Das funktioniert leider nicht...

Grrr.., das Pattren zum Match des Dateinamens hatte Punkte nicht berücksichtigt. Neue Version gleich im Startpost.

In AutoIt können wir mit <Alt + I> die Includedatei aus der Zeile, in der der Cursor steht, öffnen.

Das habe ich nun auch für Lua umgesetzt. Geöffnet werden natürlich nur Bibliotheken *.lua. Sind die Bibliotheken *.dll wird ein Hinweis ausgegeben.

Die shell.dll ist erforderlich!

Wir können hier denselben Hotkey nutzen, dann brauchen wir nicht umdenken:

# 23 Open Require
command.23.$(file.patterns.lua)=dofile $(Lua.User.Scripts.Path)/open_require.lua
command.name.23.$(file.patterns.lua)=Require Datei Öffnen
command.mode.23.$(file.patterns.lua)=subsystem:lua,savebefore:no
command.is.filter.23.$(file.patterns.lua)=1
command.shortcut.23.$(file.patterns.lua)=Alt+I

EDIT: v0.1 hatte mögliche Punkte im Bibliotheksnamen nicht berücksichtigt.

EDIT 15.08.2019:

Mit den Punkten innerhalb einer require Datei habe ich mich in die Irre treiben lassen. Jetzt ist mir die Bedeutung erst klar geworden:

Ein Punkt im require (z.B. require alien.core) bedeutet, Öffne die Datei core(dll od. lua, hier dll) im Verzeichnis alien.

Bei richtiger Definition von package.path & package.cpath kann ich Bibliotheken in Ordnern mit exakt demselben Namen, wie die Datei (ohne Erweiterung), speichern. Das ist bei der Alien-Bibliothek der Fall:

Ordner: alien

Dateien: alien.lua / core.dll / struct.dll

require "alien" bewirkt: Öffne alien.lua

require "alien.core" bewirkt: Öffne Ordner "alien" und dort die Datei "core"(.dll)

..,und weitere Änderung: Da Lua nicht zeilenbasiert ist (mehrere Befehle können hintereinander stehen: require "shell" require "bit"), werden diese Varianten jetzt auch erkannt. Befindet sich der Cursor im Bereich: Vor require bis hinter Bibliothekname wird diese Bibliothek geöffnet. Steht der Cursor irgendwo in der Zeile und eine/mehrere require Aufrufe sind vorhanden wird der erste Aufruf verwendet.

Dieses Verhalten berücksichtigt die v0.5 jetzt.

EDIT 16.08.2019:

Ich habe jetzt noch berücksichtigt, dass bei mehreren require in einer Zeile, diese auch noch mit unterschiedlichen Stringbegrenzern eingefasst sind. Wenn dann der Cursor ausserhalb des require steht soll das erste Vorkommen verwendet werden, was aber nicht zwingend das zuerst gefundene ist, da in zwei Schritten gesucht wird.

Aktuelle Version v0.6

-- TIME_STAMP   2019-08-16 20:44:06   v 0.6

local Require = {}

Require.sortTable = function(self, _t)
    local tSort, tRet = {}, {}
    for k, v in pairs(_t) do tSort[#tSort+1] = k end
    table.sort(tSort)
    for k = 1, #tSort do
        tRet[k] = {tSort[k], _t[tSort[k]]}
    end
    return tRet
end

Require.getFile = function(self)
    local pos = editor.CurrentPos
    local linenum = editor:LineFromPosition(pos)
    local line = editor:GetLine(linenum)
    local home = editor:PositionFromLine(linenum)
    local tReq, file, tIndex, index = {}, '', {}
    for s, t, e in line:gmatch("()require%s-%(-(%b'')()") do table.insert(tReq, {home+s-1, home+e-1, t:sub(2,-2)}) tIndex[s] = #tReq end
    for s, t, e in line:gmatch('()require%s-%(-(%b"")()') do table.insert(tReq, {home+s-1, home+e-1, t:sub(2,-2)}) tIndex[s] = #tReq end
    if #tReq > 0 then
        for i=1, #tReq do
            if pos >= tReq[i][1] and pos <= tReq[i][2] then file = tReq[i][3] break end
        end
        if file == '' then -- cursor outside the require command, use 1st match
            tIndex = self:sortTable(tIndex)
            file = tReq[tIndex[1][2]][3]
        end
        file = file:gsub('%.', '/')
        return file, linenum +1
    end
    return nil, linenum +1
end


Require.createPathes = function(self, _file)
    local pathes = package.path
    local tPathes, bBreak = {}, false
    while pathes:len() do
        local pos = pathes:find(';')
        local fullpath
        if pos then
            local path = pathes:sub(1,pos-1)
            pathes = pathes:sub(pos+1)
            fullpath = path
        else
            fullpath = pathes
            bBreak = true
        end
        if not (fullpath:sub(-8) == 'init.lua') then
            fullpath = fullpath:gsub('%?',_file)   -- print(fullpath)
            table.insert(tPathes, fullpath)
        end
        if bBreak then break end
    end
    return tPathes
end


Require.openFile = function(self)
    local s_require, linenum = self:getFile()
    if not s_require then
        print('@_NONE_REQUIRE__LINE\t\t'..tostring(linenum))
        return
    end
    local tPathes = self:createPathes(s_require)
    local shell = require "shell"
    local s_open
    for i = 1, #tPathes do
        if shell.fileexists(tPathes[i]) then
            s_open = tPathes[i]
            break
        end
    end
    if s_open then
        print('@_REQUIRE_OPENED__LINE\t\t'..tostring(linenum)..'  ['..s_open..']')
        scite.Open(s_open)
    else
        print('@_REQUIRE_IS_DLL_FILE__CAN\'T_OPEN__LINE\t\t'..tostring(linenum))
    end
end


Require:openFile()

Zitat

kann es sein, dass du hier ein require vergessen hast...

Kann durchaus sein. Ich bemerke das nicht, weil ich viele Skripte beim Startup lade, die bereits diese Bibliotheken einbinden.

EDIT: Also für os benötigen wir kein require, das ist eine der Standardbibliotheken. Und Alien wird explizit innerhalb von HRT eingebunden, somit dürfte eigentlich kein Fehler erscheinen.

EDIT2: Die shell habe ich im Startpost aktualisiert. Bei der Gelegenheit habe ich auch die zugehörige css-Datei etwas angepasst. Das Original hat ja kaum Ähnlichkeit mit der Webseite.

HiResTimer

Da Lua nativ keinen brauchbaren Timer besitzt, bietet HiResTimer.lua (unter Verwendung der Alien.dll) hier Abhilfe.

----------------------------------------------------------------------------------------------------
local oTimer = {

hrt = require("HiResTimer"),       -- requires "Alien"
time = nil,

init = function(self)
    self.time = self.hrt.clock()
end,

diff = function(self, _bSecond)
    if self.time == nil then return 0 end
    local timer = self.hrt.clock()
    if _bSecond then
        return timer - self.time
    else
        return (timer - self.time)*1000
    end
end,

new = function(self, obj)
    obj = obj or {}
    setmetatable(obj, self)
    self.__index = self
    return obj
end
}
----------------------------------------------------------------------------------------------------


------ sleep Funktion
local clock = os.clock
function sleep(n)  -- seconds
    local t0 = clock()
    while clock() - t0 <= n do end
end

local t = oTimer:new()
t:init()
sleep(3)
print('diff', t:diff())

Zitat von Bitnugger

shell... da hast du zwar den richtigen Link, aber die Dateien im Archiv sind nicht mehr aktuell. Wieso hast du hierfür kein eigenes Verzeichnis im Archiv angelegt?

Hatte ich gar nicht bemerkt, dass da eine neue Version existiert

Ich werde mal auch noch ein paar Bsp. posten.

Als erstes für vcl: ein rudimentärer Taschenrechner.

Dabei werdet ihr aber auch auf ein Problem von vcl in SciTE stossen. Der Aufruf führt stets zu einem Crash von SciTE. Soweit ich das nachlesen konnte, wäre es wohl erforderlich den Loop in einen anderen Prozeß auszulagern, weil es mit dem SciTE-Prozeß immer Komplikationen gibt.

Läßt sich mit meinem Bsp-Skript jederzeit nachvollziehen:

- erster Start: Skript funktioniert

- GUI schliessen

- zweiter Start: SciTE schmiert ab

Wenn ihr übrigens mal schnell einen Überblick über die Funktionen und Konstanten haben wollt, die in der Bibliothek enthalten sind, geht das so:

local vcl = require "vcl"

for k,v in pairs(vcl) do print(k,v) end

Noch etwas zu den Aufrufkonventionen (Einbinden der Bibliotheken)

require "vcl" ( ist identisch mit require("vcl") ) - hier wird die Bibliothek mit ihrem Namen im Globalen Space bereitgestellt

vcl = require "vcl" - auch hier wird die Bibliothek im Globalen Space bereitgestellt

local vcl = require "vcl" - die Bibliothek wird im Lokalen Space bereitgestellt

Warum ist das wichtig. Alle Funktionen und Variablen werden in Lua in Tables gespeichert. Sind diese Global, ist das also eine umfangreiche und somit langsame Suche. Bei lokaler Deklaration wird dann nur in dem Skript gesucht. Man sieht z.B. häufig, dass oft genutzte native Funktionen im Skriptkopf lokalisiert werden: local print = print

Da in den entsprechenden Threads einige Anhänge verloren gegangen sind, werde ich hier nochmals in SciTE nutzbare Bibliotheken für Lua posten.

• Alien Eine Art Schweizer Taschenmesser, man kann sich z.B. die WinAPI damit zugänglich machen
• Shell Datei-, Kommandozeilenoperationen, MsgBox in Lua
• LPEG Reguläre Ausdrücke (das Wiki ist russisch, bei Bedarf einfach vom Browser übersetzen lassen ) war der falsche LInk
• RE LPEG ist schon etwas speziell, für einfacheres Handling hier die re.lua, die auf LPEG basiert
• LFS LuaFileSystem --- Scheinbar hatte ich doch nicht mehr die SciTE-Variante dieser Dll. Diese hier ist leider nicht in SciTE ladbar.
• GUI in SciTE, siehe gui.html im Ordner doc
• VCL Umfangreiche Bibliothek für GUI in Lua
• HiResTimer Ein hochpräziser Timer, erfordert Alien

Einbinden der Bibliotheken

- Einen Ordner für eigene Luaskripte und Bibliotheken anlegen

- In der SciTEUser.properties dafür eine Property festlegen, z.B. Lua.User.Scripts.Path=Lw:\DEIN\PFAD

- In der SciTEStartup.lua muss jetzt dieser Pfad für Lua- und Dll-Dateien registriert werden.

local sUserLua = props["Lua.User.Scripts.Path"]
LUA_USER_PATH = sUserLua .. "\\?.dll;" .. sUserLua .. "\\?\\?.dll;"
package.cpath = LUA_USER_PATH .. package.cpath

LUA_USER_LUA = sUserLua .. "\\?.lua;" .. sUserLua .. "\\?\\?.lua;"
package.path = LUA_USER_LUA .. package.path

Die Art der Registrierung ermöglicht, dass die Dateien direkt im benannten Pfad gespeichert sind oder in einem Unterordner, der denselben Namen wie die Datei trägt (ist übersichtlicher, wenn jede Bibliothek in einem eigenen Ordner liegt, mit evtl. weiteren zugehörigen Dateien, Doc, Bsp., etc.).

Die angehängten Bibliotheken sind nach dem Entpacken jeweils in einem eigenen Ordner. Diese Ordner in den Lua.User.Scripts.Path kopieren.

Nach einem Neustart stehen die Bibliotheken zur Verfügung.

In ein Skript werden Bibliotheken mit variable = require("Bibliothek") eingebunden. "Bibliothek" ist der Dateiname ohne Endung.

"Normalerweise" kann der Name der Variablen, der die Bibliothek zugewiesen wird, beliebig sein. Wenn die Bibliothek ihre Funktionen aber nicht sauber exportiert (bei "gui" war das mal der Fall) ist es unbedingt erforderlich den Bibliotheksnamen auch als Variablennamen zu verwenden (gui = require("gui").

Um sich mal schnell einen Überblick über die Funktionen einer Bibliothek zu verschaffen, könnt ihr diesen Code verwenden (Funktionen in alphabetischer Reihenfolge).

local lib_func_list = function(_lib)
    local _lib = require(_lib)
    local keys = {}
    for k, v in pairs(_lib) do
        if type(v) == 'function' then keys[#keys+1] = k end
    end
    table.sort(keys)
    return keys
end

local keys = lib_func_list('re')
for i=1, #keys do print(keys[i]) end

Ich habe es jetzt so gelöst mit Markierung des Suchbegriffs, shell.dll muss installiert sein (Eintrag in SciTEUser.properties):

command.help.$(file.patterns.lua)=dostring \

local chrome = "C:/Program Files (x86)/Google/Chrome/Application/chrome.exe" \

local manual = "file:///C:/CODE/Lua/doc/lua/www.lua.org/manual/5.1/manual.html#pdf-" \

local sel = props["CurrentSelection"] \

if sel == "" then manual = "file:///C:/CODE/Lua/doc/lua/www.lua.org/manual/5.1/manual.html" end \

shell.exec('"'..chrome..'" "'..manual..sel..'"')

command.help.subsystem.$(file.patterns.lua)=3

Wird jetzt "F1" gedrückt, ohne dass eine Funktion markiert ist, wird das Manual selbst aufgerufen, mit markierter Funktion das Kapitel zum Funktionsaufruf.

Ich möchte das Lua-Referenz-Manual für den Hilfeaufruf in Lua-Skripten aus SciTE heraus nutzen.

Um nicht online abhängig zu sein, habe ich die Webseitenstruktur des Manuals lokal abgespeichert.

Mit "F1" kann ich das Manual nun aus Lua heraus aufrufen (in den SciTEUser.properties eingetragen).

command.help.$(file.patterns.lua)="file://C:/CODE/Lua/doc/lua/www.lua.org/manual/5.1/manual.html"

command.help.subsystem.$(file.patterns.lua)=2

Ich würde nun gerne als Parameter das Wort unter dem Cursor ($(CurrentWord)) bzw. die Auswahl (CurrentWord berücksichtigt keine Punkt Notation) mit übergeben, sodass der zugehörige Link gesucht und aufgerufen wird. Der Link setzt sich so zusammen:

https://www.lua.org/manual/5.1/manual.html#pdf-math.floor

Hauptseite fixer_Prefix Funktionsname

Ich könnte den Aufrufstring aus den Fragmenten zusammensetzen. Wenn es aber die Möglichkeit gäbe einen Parameter an den Aufruf zu hängen fände ich das eleganter.

Die Frage lautet nun: Geht das?

Inzwischen hat sich so einiges an Funktionen angesammelt. Ich werde diese mal nach und nach in ordentliche Form packen und als UDF in diesem Thread speichern. Die Auflistung in diesem Post und in den Folgeposts dann für jede Bibliothek ein Beitrag.

1. Dictionary Objekt - Erstellen und Verwalten eines Dictionarys in Objektform.

Zitat von Bitnugger

Ja, Send() ist nur eine Notlösung.

Oh man, den Wald vor lauter Bäumen nicht gesehen.

Die Tab-UDF tut's doch.

Func _SetCurrentTabNumber($iTabNumber) ; $iTabNumber (0 basierter Index)
    Local $hActive = WinGetHandle('[ACTIVE]')
    Local $hTab = ControlGetHandle($hActive, '', '[CLASS:SciTeTabCtrl; INSTANCE:1]')
    If $iTabNumber > _GUICtrlTab_GetItemCount($hTab) -1 Then $iTabNumber = _GUICtrlTab_GetItemCount($hTab) -1
    _GUICtrlTab_SetCurFocus($hTab, $iTabNumber)
EndFunc

Zitat von Mars

Ich finde diese Reihenfolgen vollkommen nachvollziehbar. Bei einer GUI will ich zu allererst einmal die Größe bestimmen (wo sie genau ist ist in 90% aller Fälle egal), bei einem Ctrl will ich zuerst den Ort bestimmen.

Grundsätzlich stimme ich dem zu. Welche Parameter sind optional und welche nicht, bestimmt schon die Reihenfolge. Schön ist es aber nicht.

Optimal wäre natürlich ein Parameteraufruf wie bei anderen Basic-Dialekten (benannter Aufruf: Parametername=Wert), da ist dann auch die Reihenfolge egal. Haben wir aber nicht, also müssen wir es nehmen, wie es ist.

Man könnte natürlich die Funktionen covern und mit diesem Aufrufstil gestalten. Für die Lesbarkeit von Skripten hat das einen gewissen Reiz, da der Parameter erst im Klarnamen angegeben wird und dann der entsprechende Wert folgt. Ist natürlich wenig sinnvoll eine bestehende Syntax dahingehend umzubiegen. Hat aber auch einen Lerneffekt: Wenn man das für sich selbst mit mehreren Funktionen ausführt, hat man deren Syntax hinterher ganz sicher erlernt.

Aber trotzdem mal ein Bsp. wie es aussehen könnte:

Func _GUICreate($1=Null,$2=Null,$3=Null,$4=Null,$5=Null,$6=Null,$7=Null,$8=Null,$9=Null,$10=Null,$11=Null,$12=Null,$13=Null,$14=Null,$15=Null,$16=Null)
    Local $aParam[8][2] = [[$1,$2],[$3,$4],[$5,$6],[$7,$8],[$9,$10],[$11,$12],[$13,$14],[$15,$16]]
    Local $title = 'title', $width = Default, $height = Default, $left = -1, $top = -1, $style = -1, $exStyle = -1, $parent = 0
    For $i = 0 To UBound($aParam) -1
        Switch $aParam[$i][0]
            Case Null
                ExitLoop
            Case 'title'
                $title = $aParam[$i][1]
            Case 'width'
                $width = $aParam[$i][1]
            Case 'height'
                $height = $aParam[$i][1]
            Case 'left'
                $left = $aParam[$i][1]
            Case 'top'
                $top = $aParam[$i][1]
            Case 'style'
                $style = $aParam[$i][1]
            Case 'exStyle'
                $exStyle = $aParam[$i][1]
            Case 'parent'
                $parent = $aParam[$i][1]
        EndSwitch
    Next
    Return GUICreate($title, $width, $height, $left, $top, $style, $exStyle, $parent)
EndFunc

$hGui = _GUICreate('left', 100, 'height', 150, 'title', 'Test named param')
GUISetState()

Do
Until GUIGetMsg() = -3