Control-Positionierung/Skalierung bei resizable GUIs

  • Ich hab grad versucht, den Regex-Tester aus der Hilfe resizable zu machen.

    Daß Controls in AutoIt nicht mit den gebräuchlichsten Resizing-Parametern als Default-Werten erzeugt werden und man die immer erst anpassen muss, ist schade. (Buttons z.B. behalten ihre Größe in der Regel, während Imputs, Combos, Listen, etc. üblicherweise mit der Gui resizen)

    Daß z.B. die (visuell) in "Groups" positionierten Controls z.T. aus diesen "herauswandern" beim Resizen, ist ärgerlich.

    Wenn ich $WM_SIZE benutze, funktioniert das z.B. nicht beim Maximieren.

    Wie funktioniert denn das bei Programmen, die in anderen Sprachen geschrieben wurden? Dort werden Controls doch anscheinend nicht nur am Fenster, sondern auch aneinander ausgerichtet, so daß die Margins zwischen ihnen gleich bleiben.

    DotNet arbeitet z.B. mit Margin und Padding, so wie das auch in Html funktioniert. (https://msdn.microsoft.com/de-de/library/…(v=vs.110).aspx)

    Gibt es in den WinApi's keine Funktionen, um die Positionierung auf die gleiche weise für AutoIt-GUIs festzulegen?

  • Zunächst... Es gibt zig verschiedene GUI-Toolkits, mit denen du ein Fenster erzeugen und zeichnen kannst. Dabei ist das alles historisch gewachsen und dadurch auch etwas verworren. Die neueren arbeiten mit dynamischen Layouts, die älteren (wie bei AutoIt zu sehen) mit pixelgenauen Layouts. In der Unix/Linux-Welt sind da bekannte Vertreter Qt, wxWidgets oder GTK+. Auch Microsoft hat im Laufe der Zeit einige Toolkits entwickelt. DotNet verwendet bspw. WinForms. Dann gibt es noch WPF (Windows Presentation Foundation) für VC++. Und zu guter letzt existiert noch das wohl älteste Framework in diesem Bereich, nämlich Win32, auch einfach bekannt als WinAPI.

    Die WinAPI ist aber fest an Pixellayouts gebunden. Es besteht theoretisch die Möglichkeit, ein anderes Framework aus AutoIt aufzurufen. Allerdings ist mir keine UDF in dem Bereich bekannt.

  • fakeraol , wenn es dir um die Controls geht sieh dir den folgenden Befehl in der Hilfe mal genauer an.

    GUICtrlSetResizing

    GUICtrlSetResizing ( controlID, resizing )
    Definiert die Methode zur Größenänderung, die von einem Control verwendet wird.

    Damit dürftest du genau das beeinflussen können was du wolltest,

    musst aber jedes Control einzeln bearbeiten.

    Edit: Habe noch übersehen, daß das Standardverhalten für alle Controls per

    Opt("GUIResizeMode", 0) ; 0=keine Größenänderung, konfigurierte Größenänderung (<1024)

    Festegelegt werden kann.

    Und davon abweichendes Verhalten kann dann über GuiCtrlSetResizing() für jedes Control einzeln bewstimmt werden.

    Einmal editiert, zuletzt von Tuxedo (30. Dezember 2017 um 06:32)

  • chesstiger

    W32 kann Elemente nur am Fenster ausrichten, nicht an anderen Elementen? Bzw. Elemente als Kinder anderer Elemente definieren, so daß sie sich an denen ausrichten?

    Tuxedo

    Mit der Option GUIResizeMode kann ich auch wieder nur das Verhalten ALLER Elemente gleich festlegen, nicht aber für Buttons $GUI_DOCKSIZE als Default setzen, und für Imput, Combo, List z.B. $GUI_DOCKBORDERS.

    Daß der Abstand eines, in einem Group-Control plazierten Input zu dessen Rändern sich beim Resizen verändert, kannst Du rein mit GUICtrlSetResizing nicht korrigieren. Dazu braucht es immer zusätzlichen Aufwand, z.B. mittels $WM_SIZE (was aber beim Maximieren eines Fensters nicht funktioniert, da ControlGetPos dann falsche Werte liefert).

    • Offizieller Beitrag

    Fenster größenveränderlich zu machen ist nicht einfach. Vor allem, wenn es sehr viele GUI-Elemente gibt.

    Mein Ansatz ist meist, dass ich eine Mindestgröße vorgebe und mit dieser Mindestgröße erstelle ich die GUI. Mit Hilfe von $GUI_DOCKHCENTER kann man die Elemente dann schonmal ganz gut ausrichten.

    Daß der Abstand eines, in einem Group-Control plazierten Input zu dessen Rändern sich beim Resizen verändert, kannst Du rein mit GUICtrlSetResizing nicht korrigieren. Dazu braucht es immer zusätzlichen Aufwand,

    Ich weiß nicht, ob ich das Problem richtig verstehe, aber so würde es schonmal ganz gut aussehen:

  • Hallo fakeraol

    Wenn ich $WM_SIZE benutze, funktioniert das z.B. nicht beim Maximieren.

    Ich denke mit $WM_SIZE kannst du die besten Ergebnisse erzielen. Hier einfach alles händisch machen. Das Maximieren kannst du entweder unterbinden oder wie Oscar gezeigt hat auf eine bestimmte Größe festlegen oder du wertest einfach das Event Maximieren aus und setzt dann auch alles händisch. (Mit händisch meine ich, alle relativen Positionen für alle Controls selbst festlegen). Das ist schon Fleißarbeit.

    Grüße autoiter

  • Yjuq (vormals @Make-Grafik) hatte dieses Problem schon vor langer Zeit erkannt und wollte dafür eine UDF schreiben, welche die Vorteile von Java bezüglich der Verwaltung, Erstellung und des Handlings von GUIs auch in AutoIt ermöglichen soll... ich hatte ihm meine Hilfe angeboten... die aber kaum von Bedeutung ist, da ich keine Ahnung von Java habe und meine Kentnisse in C(++) und FreeBasic (erste Wahl als Werkzeug, um die Kernkomponenten umzusetzen) auch sehr begrenzt sind.

    Yjuq, arbeitest du noch an diesem Projekt, oder hast du es verworfen? Falls du noch daran arbeitest und ich dir helfen kann, dann lasse es mich wissen - bin auch wieder via Discord erreichbar.

  • Wäre ein installiertes Java dann nicht auch Voraussetzung, damit diese Scripte dann laufen?

    Wenn ich das bis hier hin richtig verstanden habe, müssen alle WinApi-Programme ihre Oberflächen mit zusätzlichen Routinen repositionieren, weil es keine positionellen Abhängigkeiten von anderen Controls gibt unter Win32?

    Wäre es denn (technisch) möglich, ein anderes GUI-Toolkit per UDF für die AutoIt-GUI zu verwenden? Evtl. Tips, was sich da hinsichtlich Verbreitung auf Windows-Rechnern und Umsetzbarkeit anbieten würde? DotNet evtl.?

    Einmal editiert, zuletzt von fakeraol (1. Januar 2018 um 16:41)

  • Wäre ein installiertes Java dann nicht auch Voraussetzung, damit diese Scripte dann laufen?

    Nein, denn die UDF soll ja das Erstellten der GUIs und Controls in AutoIt erledigen.

    Wenn ich das bis hier hin richtig verstanden habe, müssen alle WinApi-Programme ihre Oberflächen mit zusätzlichen Routinen repositionieren, weil es keine positionellen Abhängigkeiten von anderen Controls gibt unter Win32?

    Ich denke das ist korrekt. In AutoIt kannst du zwar mit GUICtrlSetResizing das Verhalten bei der Repositionierung eines Controls beeinflussen, was aber insgesamt keine befriedigende Lösung darstellt. Java bietet dafür Container-Klassen an, mit denen sich Bedienelemente (Controls) strukturieren und gruppieren lassen.

    Wäre es denn (technisch) möglich, ein anderes GUI-Toolkit per UDF für die AutoIt-GUI zu verwenden?

    Ja, sicher doch... genau das war mit dieser UDF ja geplant... indem sie die Möglichkeiten von Swing bereitstellt.

    Evtl. Tips, was sich da hinsichtlich Verbreitung auf Windows-Rechnern und Umsetzbarkeit anbieten würde? DotNet evtl.?

    Es gibt viele... die Verbreitung spielt weniger eine Rolle... entscheidend sind vor allem die Umsetzbarkeit und der erzielbare Mehrwert.

    Denkbar wären sicher folgende...

    Plattformübergreifend: GTK+, Qt, wxWidgets, Tk, FLTK, Swing (in Java)

    Der Vollständigkeit halber die komplette Liste...

    Windows: Microsoft Foundation Classes (MFC), Visual Component Library (VCL, in Delphi), Win32 (WinAPI), Windows Presentation Foundation (WPF), Windows Forms (.NET)

    Alle haben Pros und Kontras... die Auswahl der möglichen Kandidaten begrenzt sich letztendlich aber entsprechend den Fähigkeiten des Coders .

    Liste von GUI-Bibliotheken

  • Da AutoIt ja Windows-orientiert ist, macht Plattformunabhängigkreit überhaupt Sinn?

    Zum einen wäre wichtig, welche Toolkits diese Container-Verschachtelung/Strukturierung/Gruppierung unterstützen, die uns in AutoIt fehlt (umzusetzen ohne übermäßigen Aufwand).

    Zum anderen ist Verbreitung schon interessant (am besten auf jedem Windows-System vorhanden), damit man nicht erst die zugehörigen DLLs besorgen muß (evtl.Versions-Probleme?), denn aus Copyright-Gründen können wir die wohl schlecht selbst hier anbieten. Auch würden mitzuliefernde DLLs (FileInstall) die Programm-Datei aufblähen.

    Also erst mal aussortieren, was nicht in Frage kommt, und dann hier die Doku zu dem Toolkit verlinken, das dann letztlich umgesetzt werden soll. Dann machen sicher auch mehr Leute mit bei der Umsetzung, wenn sie die Resourcen nicht selber zusammensuchen müssen. :)

  • Plattformunabhängigkeit schadet auf jeden Fall nicht.

    Dabei ist noch zu beachten, dass sich nicht für alle genannten Bibliotheken mit einfachen Mitteln AutoIt-Bindings erstellen lassen. Als Beispiel sei hier Qt genannt: Qt wurde in C++ geschrieben und baut sehr stark auf dessen Objektorientierung auf. Das ist in AutoIt nicht wirklich angenehm zu händeln und lässt sich auch schlecht abbilden. Im Idealfall nimmt man daher eine C-Bibliothek wie Gtk+, denke ich. Trotz GObject geht das definitiv besser.

    Wobei es eigentlich kein Problem darstellt, ein paar DLLs mitzuliefern. Erstens nehmen die nicht wirklich viel Speicherplatz ein und zweites stehen die meisten Toolkits unter Lizenzen wie der LGPL, was eine Weitergabe recht leicht macht.

  • Es war nicht geplant, eines der Toolkits in AutoIt einzubinden, sondern ein eigenes zu schreiben, zu dessen Umsetzung hauptsächlich Swing als wegweisende Vorlage dienen sollte, Wesentliche Elemente bzw. Kernpunkte dabei wären sicherlich die Container und Custom Controls. Der erste große Akt wäre dann die Umsetzung der Custom Controls...

  • Zitat

    arbeitest du noch an diesem Projekt, oder hast du es verworfen? Falls du noch daran arbeitest und ich dir helfen kann, dann lasse es mich wissen - bin auch wieder via Discord erreichbar.

    Ich hab es auf Eis gelegt momentan. Der Grund ist, das es dafür keine wirkliche Nachfrage oder gar Interesse gab. Wozu also die Mühe machen? Habe im englischen Forum damals mal einige Prototypen veröffentlicht wo kaum was an Feedback zurück kam. Da hat es sich nicht wirklich mehr gelohnt für die Handvoll an Interessierte da weiter dran zu arbeiten. Zudem bin ich an einige Probleme gestoßen. Zwar könnte ich die mittlerweile lösen aber für wen mache ich das dann? Wo keine Nachfrage, da kein Angebot.

    Momentan sitze ich aber auch wieder an ein neuen Projekt. Es geht um ein Game welches ich momentan mit einem Kollegen am implementieren bin. Davon wünsche ich mir, eine Firma eröffnen zu können und selbstständig zu werden. Das hat dann doch mehr Priorität momentan, selbst wenn das nichts wird (Sprich: Im Markt Fuß fasst) macht es sich gut bei Bewerbungen.

    Mal ganz davon abgesehen dass du 50% an Falschinformationen hier vermittelst über das Projekt. Bin aber relativ zu faul um das gerade zu korrigieren. ^^