Diskussion zum Thema : "AutoIt Interne Funktionen : Erwartetes Ergebnis -> Tatsächliches Ergebnis"

  • Der Kern meiner Frage bleibt aber : "Gehören solche kleinen Fallen in den Sammelthread ?"

    Ich denke, wenn du sie unter einem Punkt zusammenfasst, sind sie dort gut aufgehoben.


    Das Problem des User war aber auch, dass er seine Handles in einem Dictionary speichert, wodurch sie unbrauchbar wurden, weil sie im Dictionary als dezimale Zahlen gespeichert werden und bei späterer Verwendung dann nicht mehr als Handle erkannt werden - das gehört aber defintiv da rein. ;-)

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

  • 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. :P

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

  • Bei GUICtrl... sind left und top Pflichtangaben, width und height hingegen [optional] - daher stehen sie wohl auch am Beginn der Parameter. Bei GUICreate sind alle Angaben [optional].

    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.

    (zum Beitrag von Mars )

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

    Auch ich sehe es so, dass Pflichtparameter VOR Optionalparametern stehen sollten. Da bei GUICreate aber alle (Positions-)Parameter optional sind, hätte man die Reihenfolge der GUICtrl...-Funktionen nehmen können. Sollte so sein - ist es aber nicht -> also damit leben.

    Nichtsdestotrotz werde ich diesen Punkt als 'potenzielle Falle' in den Sammelthread nehmen.


    Gruß Musashi

  • WinGetPos liefert nicht wie erwartet die Position und Größe des minimierten Fensters, wenn nach GUICreate('') nur ein GUISetState(@SW_MINIMIZE) ausgeführt wird, sondern die Position und Größe, welche beim Erstellen des Fenster verwendet wurde - also entweder die angegeben Werte oder die Default-Werte.

    Hi Bitnugger !


    1. WinGetPos :

    WinGetPos scheint auch die in GUICreate angegebenen Werte für Width und Height zu ignorieren ?!


    2. (Kleinigkeit) in Func _Example_BAD() ;

    Local $aPos, $hGUI = GUICreate ... -> $aPos hier unnötig.


    Gruß Musashi

  • WinGetPos scheint auch die in GUICreate angegebenen Werte für Width und Height zu ignorieren ?!

    Nein, Du bekommst mit "WinGetPos" nur die wirkliche Windowsgröße (inkl. Border). Das, was Du bei GuiCreate angibst, ist die ClientSize.

    Siehe hier:

  • Nein, Du bekommst mit "WinGetPos" nur die wirkliche Windowsgröße (inkl. Border). Das, was Du bei GuiCreate angibst, ist die ClientSize.

    Ah, ok - Danke. Das war dann wohl ein Missverständnis meinerseits.


    An dem von Bitnugger beschriebenen Fehlverhalten ändert es ja nichts.


    Gruß Musashi

  • Das muss nicht zwingend ein Fehlverhalten sein. Denn direkt nach der Erstellung eines Fensters

    mittels GUICreate ohne weitere Befehle ist das Fenster unsichtbar(versteckt), es existiert quasi gar nicht. Demzufolge kann es auch nicht minimiert werden. Was übrig bleibt an Korodinaten und Positionen ist das was bei GUICreate angegeben wurde.

    und das sind zumindest bei mir genau die angezeigten Werte.


    Das ändert sich eben erst wenn das Fenster einmal angezeigt oder sonstwie aktiviert wird,

    danach kann es auch minimiert werden und ab dann werden auch die richtigen erwarteten Werte angezeigt.

  • Tuxedo

    Wird anstelle GUISetState WinSetState verwendet, um das "quasi nicht existierende" Fenster zu minimieren, funktioniert es... erkläre das mal bitte!

  • Das muss nicht zwingend ein Fehlverhalten sein. Denn direkt nach der Erstellung eines Fensters

    mittels GUICreate ohne weitere Befehle ist das Fenster unsichtbar(versteckt), es existiert quasi gar nicht. Demzufolge kann es auch nicht minimiert werden.

    Allgemein betrachtet, ist Deine Interpretation nicht gänzlich abwegig.


    Mit GUICreate wird aber ein Fenster erzeugt (mit handle), der Annahme "es existiert quasi gar nicht" kann ich daher nicht folgen. Wie Bitnugger gezeigt hat, lässt es sich mit GUISetState(@SW_MINIMIZE)

    aber nicht (sofort) minimieren. Erst ein vorheriges GUISetState() ohne Parameter (verwendet als Default dann ja @SW_SHOW) löst das Problem. Wenn man seinen Code ausführt, sieht man auch kurzfristig eine Fensteranzeige (im OK-Fall).


    Die Frage könnte also auch lauten : "arbeitet GUISetState() wie erwartet ?"

    Möglicherweise liege ich mit meiner Interpretation aber falsch, wahr 'ne lange Nacht gestern :P.


    Gruß Musashi

  • Bitnugger du hast dir die Antwort mit deinem letzten Beispiel schon fast selbst gegeben.

    Ich habe in meinem geänderten Beispiel erst hinterher gesehen, daß du schon den Status der Funktion mitausgeben lässt. Dabei wirst du feststellen, daß bei Verwendung der Funktion GuiSetState(@SW_MINIMIZE) als Status ein Fehler ausgegeben wird Status = 0, und ich vermute das ist deshalb der Fall weil das Fenster eben nicht sichtbar ist.

    Und das selbe Spiel mit @SW_SHOWMINIMIZED ergibt Status = 1 also kein Fehler.

    So gesehen arbeitet die Funktion GuiSetState eigentlich schon so wie vorgesehen.


    Aber langsam sollten wirs ja wissen, daß unsere Denkweise sich von denen der Autoit Entwickler teilweise massiv unterscheidet. Und andere Ansichten als die der Autoit-Götter in Weiss werden nicht geduldet, was vielleicht auch einer der Gründe sein könnte warum Ward alle seine Uploads auf autoitscript.com vernichtet hat. Glücklicherweise konnte ich etliche von seinen genialen Original-Downloads in Sicherheit bringen.

  • Dabei wirst du feststellen, daß bei Verwendung der Funktion GuiSetState(@SW_MINIMIZE) als Status ein Fehler ausgegeben wird Status = 0, und ich vermute das ist deshalb der Fall weil das Fenster eben nicht sichtbar ist.

    Für mich ist, trotz Matschbirne ;), das Verhalten von GUISetState insgesamt nicht konsequent :

    GuiSetState(@SW_MAXIMIZE) ==> Status=1 (Erfolg)

    GuiSetState(@SW_DISABLE) ==> Status=1 (Erfolg)

    GuiSetState(@SW_HIDE) ==> Status=1 (Erfolg)

    GuiSetState(@SW_LOCK) ==> Status=1 (Erfolg)

    GuiSetState(@SW_MINIMIZE) ==> Status=0 (Fehler)

    Ich kann das Fenster direkt nach GUICreate -> Verstecken, Deaktivieren, Sperren usw. , aber nicht Minimieren.


    Bei den Flags ;

    @SW_SHOWMAXIMIZED - Aktiviert das Fenster und zeigt es als maximiertes Fenster an

    @SW_SHOWMINIMIZED - Aktiviert das Fenster und zeigt es als minimiertes Fenster an

    ist die Sache klar.


    Bitnugger : Frage

    Ist daher nicht eher GuiSetState(@SW_MINIMIZE) die eigentliche 'Fehlerquelle', und nicht WinGetPos wie im Sammelthread derzeit angegeben ?

    Zitat

    WinGetPos liefert nicht wie erwartet die Position und Größe des minimierten Fensters, wenn nach GUICreate('') nur ein GUISetState(@SW_MINIMIZE) ausgeführt wird


    Gruß Musashi

  • Ist daher nicht eher GuiSetState(@SW_MINIMIZE) die eigentliche 'Fehlerquelle', und nicht WinGetPos wie im Sammelthread derzeit angegeben ?

    Natürlich ist GuiSetState(@SW_MINIMIZE) die Fehlerquelle, was zudem auch durch den Rückgabewert 0 bestätigt wird. Im Sammelthread habe ich mit meinem Satz aber an keiner Stelle eine Schuldzuweisung ausgesprochen... allerdings könnte man den Satz noch mit einem weil... erweitern.

  • Wenn man eine Datei die Funktionen enthält als .a3x kompiliert und diese in einem anderen Script per Include einfügt wird die Funktion nicht erkannt. Eine Lösung für dieses Problem ist, dass man die .a3x Datei umbenennt zu z.B. .a3y. Wenn man diese datei via Include einfügt funktioniert alles wie gewohnt.


    Code: a.au3
    1. #Region ;**** Directives created by AutoIt3Wrapper_GUI ****
    2. #AutoIt3Wrapper_Outfile_type=a3x
    3. #EndRegion ;**** Directives created by AutoIt3Wrapper_GUI ****
    4. Func MyFunc()
    5. MsgBox(1, 'Hallo', 'Hallo')
    6. EndFunc
    Code: b.au3
    1. #include 'a.a3x'
    2. MyFunc()


    Bin nicht sicher ob das bei jedem so ist, aber intuitiv ist dieses Verhalten nicht. Liegt vermutlich an Au3Check. Kann das jemand reproduzieren?


    lg

    M

  • Kann das jemand reproduzieren?

    Ja, ist bei mir ebenso (Win7-64 Pro, SP1 - AutoIt 3.3.14.0) .

    Offenbar sind wir nicht die Einzigen, siehe ;


    https://www.autoitscript.com/f…ndComment&comment=1325658


    EDIT :

    Auszug aus der aktuellen Hilfe :

    Schlüsselwort #include

    Bemerkungen

    Andere Skripte können in ein AutoIt-Script mittels des #include-Kommandos eingebunden werden. Dies kann entweder im .au3 oder .a3x Format sein.


    Mars : EDIT 2

    Fügt man in b.au3 folgendes ein :

    #AutoIt3Wrapper_Run_AU3Check=n

    dann geht es (hast Du ja bereits vermutet).


    Gruß Musashi