Der Stumpfsinn der Gewohnheit - oder - Weil man das immer so macht.

**BugFix**

Als ich gerade ein altes Skript von mir aktualisiert habe, ist mir aufgefallen, wie man doch ohne Nachzudenken "übliche Verfahrensweisen" ohne diese zu hinterfragen einfach übernimmt.

Wenn wir uns die UDF für nicht-native Control ansehen fällt auf, dass ausnahmslos alle UDF, die intern das parent or owner window benötigen, dieses als Parameter in der _Create-Funktion anfordern.

Da ich das in den UDF so gesehen habe, habe ich das auch für meine Skripte ohne zu hinterfragen übernommen.

Jedenfalls bis ich das o.a. Skript überarbeitet habe. Ellenlange Parameterangaben in Funktionen sind dem Handling nicht gerade zuträglich. Deshalb habe ich nach Optimierung gesucht und dieses war das Parent-Handle: Es ist sinnfrei dieses anzufordern!

Warum? - Es gibt nur 2 Situationen der Control-Erstellung:

1. GuiCreate() wurde aufgerufen und ich erstelle nachfolgend Controls

2. GuiSwitch() wurde aufgerufen und ich erstelle nachfolgend Controls

In beiden Fällen befinde ich mich im Kontext des Parent/Owner-Window. Somit kann ich es bei meiner Control-Erstellung in einer UDF doch auch einfach erfragen:

AutoIt

Local $idDummy = GUICtrlCreateLabel('',0, 0, 1, 1) ; dummy control creation to get the current gui handle
Local $hGui = _WinAPI_GetParent(GUICtrlGetHandle($idDummy))
GUICtrlDelete($idDummy)

Das sind 3 Zeilen mehr Code, die aber einen Parameter überflüssig machen. Das sollte es doch wert sein.

Das echte Dummy-Ctrl (GUICtrlCreateDummy) kann dafür nicht verwendet werden, da es ein Fake-Ctrl ist, das kein Handle besitzt. War mir nicht bewusst, wurde aber beim Testen klar.

Falls also die Übergabe des Parameters einen tieferen Sinn haben sollte, erschließt sich dieser mir nicht. Vielleicht haben alle Autoren nach den 3 Lebensleitlinien gehandelt:

Das haben wir schon immer so gemacht!
Das haben wir noch nie so gemacht!
Da könnte ja jeder kommen!

**Alina**

Moin BugFix.

Das mit den 3 Lebensleitlinien kenne ich doch irgendwo her.
Fehlt noch: "Das machen alle so".

"Neuland" ist für viele halt unbequem und deshlab vielleicht diese Aussagen.

**Andy**

BugFix ,

du bist einer der wenigen "Programmierer" (aka Menschen überhaupt) die ich kenne, die ihren Arbeitsablauf rekapitulieren, analysieren, nach Verbesserungen suchen und diese umzusetzen versuchen.

Ich versuche das jedenfalls auch immer...

Das von dir beschriebene "Problem" ist sowohl job- als auch generationenübergreifend, und tritt in der Programmiererei besonders extrem zutage.

Woher diese/unsere "lösungsorientierte" Eigenschaft/Fähigkeit kommt, kann ich mir auch nicht erklären, bin aber permanent auf der Suche nach Mitarbeitern, welche diese Anforderung erfüllen können.

Leider habe ich in den letzten ca. 50 Jahren nur sehr wenige dieser außergewöhnlichen Exemplare kennenlernen dürfen.

Ich habe aber das Gefühl, das diese Spezies langsam aber sicher ausstirbt.....oder ich liege falsch und eine mir unbekannte Macht führt diese Menschen auf direktem Weg in das Unternehmen und somit auch in das Leben ihrer Träume.

Velted

Moin,

als Rückkehrer nach einigen Jahren Pause, besteht der 'Stumpfsinn' für mich eher in der Tatsache, dass man nach wie vor 'Workarounds' braucht, um 'mittendrin' an das Handle des aktuellen GUI-Fensters zu kommen. Dabei könnte ich mir den Zugriff über kleine Anpassungen von eingebauten Mechanismen vorstellen:

@GUI_WinHandle - einfach den Zugriff außerhalb von Event-Funktionen gestatten.
GUISwitch() ohne Parameter oder mit Parameter WinHandle = 0 liefert das Handle des aktuellen GUI-Fensters.

Aber warum sollte das so einfach sein?

**Mars**

Zitat von Velted

Aber warum sollte das so einfach sein?

Das musst du nicht uns fragen, sondern die Jungs im EN-Forum

[rant] Wenn man die vielen Ideen (um AutoIt zu verbessern) aus dem Forum mal alle sammeln und auflisten würde, hätte man sicherlich locker 3 Seiten "Stichpunkte" (1Idee/Zeile). Mein aktueller Favorit ist ByRef im selben Scope, also z.B. Local $a = Byref $b, wenn ich $a ändere, ändert sich auch $b und umgekehrt. Das geht aktuell nur via ByRef im Funktionsaufruf. Benutzen könnte man das um verschachtelte Arrays effizient zu handhaben, LinkedLists (oder quasi "alle" Datenstrukturen die Pointer verwenden) zu basteln, etc. etc. Mal gucken was nächstes Jahr mein Favorit bei "missing features" ist^^ [/rant]

M

**Alina**

Zitat von Mars

Local $a = Byref $b, wenn ich $a ändere, ändert sich auch $b und umgekehrt

Also das würde mir auch gefallen und ich hätte dafür auch schon Verwendung.

**BugFix**

Zitat von Andy

du bist einer der wenigen "Programmierer" (aka Menschen überhaupt) die ich kenne, die ihren Arbeitsablauf rekapitulieren, analysieren, nach Verbesserungen suchen und diese umzusetzen versuchen.

Vielen Dank für die .

Ich kann nicht mal erklären, warum das so ist, aber irgendwie bin ich (mit wenigen Ausnahmen, z.B. QRCodeCreator) nie wirklich zufrieden mit dem Ergebnis. Dadurch gucke ich ab und an mal über alte Skripte drüber und prüfe, ob mit dem Wissen, das man ja immer weiter ansammelt, noch Verbesserungen drin sind. Ist vielleicht auch ein wenig meiner Arbeit geschuldet. Im Qualitätsmanagement gibt es eine Validierungspflicht für Software, d.h. alle 3 Jahre nehme ich mir für alle genutzte Software deren Einsatzbeschreibung vor (Was soll gemacht werden? Welcher Aufwand ist erforderlich? Wird das Ziel erreicht? Sind Verbesserungen möglich/erforderlich?). Das prüfe ich und wenn alles OK ist kommt ein Haken dran und 'Validierung unverändert gültig'. Werden Änderungen im Prozess notwendig, wird entsprechend neu validiert.

Das ist wirklich sinnvoll, denn im Abstand von 3 Jahren blickt man aus einem anderen Winkel auf die Prozesse und u.U. haben sich ja auch Randbedingungen geändert, die man berücksichtigen muss.

Zitat von Velted

besteht der 'Stumpfsinn' für mich eher in der Tatsache, dass man nach wie vor 'Workarounds' braucht

Das ist nicht von der Hand zu weisen. Da wir es aber nicht beeinflussen können, ist das ein Punkt, der mich nicht mehr zur Weißglut treibt.

In meinen eigenen Skripten packe ich diese Workarounds manchmal in "Pseudo-Makro"-Funktionen, ist aber ein rein optisches Kaschieren der dafür genutzten Funktion, programmiertechnisch nicht zwingend ein Mehrwert. Für o.a. Bsp. sieht das dann so aus:

AutoIt

Global $GUIHWND = _GuiHwnd   ; mein "Pseudo-Makro"

GUICreate('Test')
_NeedParentHwnd()
GUISetState()
; ...
; ...
; ...

Func _NeedParentHwnd()
    ConsoleWrite('Parent: ' & $GUIHWND() & @CRLF)
    ; ...
    ; ...
EndFunc

Func _GuiHwnd()
    Local $idDummy = GUICtrlCreateLabel('',0, 0, 1, 1)
    Local $hGui = _WinAPI_GetParent(GUICtrlGetHandle($idDummy))
    GUICtrlDelete($idDummy)
    Return $hGui
EndFunc

Alles anzeigen

Was Änderungswünsche im nativen AutoIt angeht - da könnten wir sicher ganze Bände mit füllen - aber: Es is, wie es is!