Bildschirmauflösung und Positionierung von Controls

**Marco Steinebach**

Hallo zusammen,
Folgende Frage: es gibt ja unglaublich viele Möglichkeiten der Bildschirmauflösung. Wenn ich ein Formular erstelle, was, um himmelswillen, gibt man normalerweise für
ClientWidth und
ClientHeight
an?
Wie sieht's mit dem Window-State aus?
Und wohin positioniere ich welche Objekte?
Nicht über die vermeintlich blöde Frage wundern. Ich bin blind, arbeite mit einem Screen-Reader der den Bildschirminhalt in Sprache umsetzt. Deshalb spielt für mich, erstmal, die Positionierung der Controls auf dem Bildschirm eine untergeordnete Rolle.
Wenn ich aber nun eine klassische Anwendung erstelle, nehmen wir mal ein Form mit 5 Eingabefeldern, und natürlich passenden Labels, die untereinander angeordnet sind, ist mir überhaupt nicht klar, wie ich das so machen soll, dass es auch für einen sehenden vernünftig aussieht.
Ist ja ein Unterschied ob nun 1024x768 oder 1900x1320 Auflösung zugrundeliegt.
Kann mir mal bitte jemand auf die Sprünge helfen?
Ach ja, die Windows 10 Skalierung vergesst erstmal, die funktioniert bei den Screen-Readern ohnehin nicht.

Herzlichen Dank schon mal und herzliche Grüße
Wandogau

**Sherlock**

Ich glaube nicht, daß es im Windows Desktop Umfeld unglaublich viele Bildschirmauflösungen gibt. Es gibt eher eine handvoll: klassische 1024*768 (in sehr geringem Umfang), 1920*1080 (der Löwenanteil) und eine wachsende Zahl von 4K Monitoren. Wichtig ist es für einen Entwickler seine Zielgruppe zu kennen, oder zu definieren. Ersteres erfordert eine Marktanalyse, was man seriös nur mit Geld hinbekommt, das man vermutlich lieber behalten möchte. Letzteres ist also das Mittel der Wahl: Definiere einfach die Auflösung Deiner Wahl als optimal für Deine Anwendung, und Du hast zumindest auf absehbare Zeit keine Probleme. Ich würde auch jetzt noch zu 1080p tendieren, da diese Auflösung sehr verbreitet ist, auch auf Notebooks. Es ist aber beim Oberflächendesign immer sinnvoll, wenn man auf Größenänderungen reagieren kann. Grids und Memos eignen sich ohne große Arbeit hervorragend dazu, sonst leer bleibende Flächen zu füllen, wenn eine Applikation auf einer höheren Auflösung genutzt wird, als bei der Entwicklung vorgesehen. Delphis Align zusammen mit reichlich Panels oder in FMX Layouts bietet da viel Platz für entsprechende Dynamik.

Sherlock

**himitsu**

Zitat:

Ach ja, die Windows 10 Skalierung vergesst erstmal, die funktioniert bei den Screen-Readern ohnehin nicht.

Falsch?

Die Fenster werden ja erstmal dargestellt und das dann gelesen, also gibt es ALLES.
Außerdem ließt man nicht das Fenster, sondern nutzt besser eine passende API.
So bietet Windows eine API für ScreenReader, welche auch Delphi unterstüzen kann. Dort wird intern eine Schnittstelle angeboten, um die "wichtigsten" Komponenten richtig auslesen zu können, ohne die Pixel analysieren zu müssen.

Accessibility API

Gerade da FMX oft komplett selbstgemalt ist, gibt es da keine "gute" Möglichkeit die einzelnen Komponenten extern auszulesen, so wie in der VCL (Win32-API),
auch wenn z.B. in der VCL das Label kein eigenes WinControl ist und somit ebenfalls extern garnicht existiert.

https://www.delphipraxis.net/196472-...it-delphi.html

https://www.fmxexpress.com/accessibi...ndows-and-osx/

https://stackoverflow.com/questions/...screen-readers

https://edn.embarcadero.com/article/33642

4K?
8K ist das neue Hochauflösend.

(auch wenn der deutsche Markt immer bissl hinterherhängt)
und Ultra Wide (ein extra breiter Monitor, anstatt zwei Normale)

https://www.amazon.de/Philips-439P9H.../dp/B07YZYZDSD (wobei das nicht so richtig 8K ist, sondern 2x 4K nebeneinander)

Querformat oder Hochformat,

ein, zwei oder mehr Monitore

gern auch ein großer Monitor und ein "kleinerer" im Hochformat danaben (für Chats usw.)

Hochformat passt auch mehr Quellcode/Zeilen auf den Screen, da die meisten Entwickler es nicht ausnutzen und keine 3000 Zeichen lange Codezeilen erstellen, um Hochauflösend in Breit auszunutzen.

**Daniel**

Himi ... Marco ist - wie er schreibt - blind und nutzt Windows über einen Screenreader.
Wenn er also sagt, dass es da teils massive Schwierigkeiten gibt, dann kommen diese Informationen aus allererster Hand und es ist vielleicht nicht ganz so einfach, als dass man jetzt mit einer Handvoll Links zu APIs herumwedelt und das Problem damit löst.

**himitsu**

Aber dennoch wird die Ausgabe irgendwo graphisch dargestellt - egal ob auf einem virtuellen Bildschirm oder real und demnach kann auch eine Skallierung enthalten sein.

Ansonsten sind FullHD-Monitore wohl aktuell immernoch am Vergreitesten, im Desktop-Bereich.
1920 breit
1080 hoch, bzw. 1200

Dass es mit ScreenReadern einige Schwierigkeiten gibt, haben wir auch schon mitbekommen.
Zuletzt durch den Einsatz eines UI-Testing-Frameworks, welches Probleme mit Grids bekommt, da Diese oft gezeichnet sind und somit standardmäßig nicht ausgelesen werden können.
Das Selbe betrifft auch eine UI Automation.

Bei Delphi kann man z.B. eine Accessibility API nachrüsten, damit die Programme ausgelesen werden können
und dann ist auch die Auflösung fast egal.
Für Grids und Componenten von DevExpress gibt es zusätzlich auch eine UI Test Extension, für z.B. den Zugriff aus TestComlete von SmartBear, was im Prinzip auch eine Art von Accessibility API darstellt.

**jobo**

Ich gebe nie etwas bei ClientWidth oder ClientHight ein. Ich ziehe mir das Formular so groß, wie es nötig scheint.
Für 5 Eingabefelder und Labels wäre es sicher weit unter den hier genannten „gängigen“ Auflösungen. Mein „Gamelaptop“, der mittlerweile fast 10 Jahre alt ist, hat bspw. eine Auflösung von 1600x900.
Es ist wahrscheinlich Geschmackssache oder Gewohnheit. Häufig habe ich viele Programme geöffnet und seltener sind die auf Fullscreen eingestellt. Ich finde jedenfalls Programm gut, die sich nicht ungefragt und unnötig breit machen. Bspw. Calc.exe, (gibt es vielleicht gar nicht mehr unter Windows 10?) der Windows Taschenrechner: Eine „Display“ Label und eine Handvoll Buttons in der Standardeinstellung, plus eine Menuzeile. Das ergibt geschätzt 200x300 Pixel. Vollkommen okay für mich. Es größer zu machen, schiene mir eher lächerlich.

Nun ist nicht jede Anwendung so übersichtlich. Möchte man dynamisch (und viel) Daten oder Text darstellen, also z.B. Treeview, Listview, Grids und Memos, bietet sich ein Formularaufbau an, der dynamisch auf die Fenstergröße reagiert. Das ist wie genannt wirklich einfach mit der Align Property by Panels und den Komponenten, die man in den Panels platziert. Alle Komponenten folgen dann der Größenänderung. Das ist keine Skalierung oder zumindest keine vollständige bzw. lineare (für alle Formularelemente).
WindowState mache ich selten schon zur Designzeit auf wsMaximized. Ich platziere meist diverse Panels im Fenster, die sich per Align automatisch an die Fenstergröße anpassen. Das wäre das „Basislayout“.
Abstände von Komponenten innerhalb der Panels könnte man auf minimal 8 oder sogar 4 Pixel bringen. Ein Tlabel zum Tedit vielleicht sogar noch näher. Man würde sich überlegen, ob man Labels über die zugehörige Komponente setzt oder links davon, Letzteres eher bei ausreichend Platz.

Apropos Skalierung und 8 oder 4 Pixel und 8 oder 4K Monitore. Auch diese absoluten Pixel Angaben würden auf den hochauflösenden Monitoren wahrscheinlich lesbare Anwendungen ergeben, da eben mittlerweile auch bei Windows (automatisch oder gewählt) skaliert wird.

**himitsu**

Zitat:

Ich gebe nie etwas bei ClientWidth oder ClientHight ein. Ich ziehe mir das Formular so groß, wie es nötig scheint.

Es ist egal, ob du ClientWidth, Width oder direkt via Maus die Fenstergröße änderst.
In der DFM gespeichert wird ClientWidth und ClientHeight, also abzüglich der Titelleiste und des Rahmens.
Vor länger Zeit hatte Delphi aber Width und Height gespeichert, was zu Problemen führte, vor allem seit Windows XP mit Styles, bzw. Designs arbeitet und da auch die Größen ständig änderte.
Selbst im Windows 10 gibt es Rahmen, auch wenn es meistens grauenhaft so aussieht, als wenn es garkeine Rahmen mehr gibt. Diese sind dennoch unsichtbar vorhanden.

Eines muß man aber beachten, denn Windows begrenzt das Fenster.
Maximal so groß wie der Desktop, was aber Delphi nicht mitbekommt, wenn es abgeschnitten wird.

Wurde das Fenster größer erstellt, als es zur Laufzeit sein kann, dann rutschen Komponenten rechts und unten aus dem Fenster.
Vor allem Anchor wird aber ab der Position berechnet, wo es erstellt wurde und somit bleibt es dann auch außerhalb.
Das ist auch der rund, warum Delphi bei Fenstern nun ClientWidth statt Width speichert, denn wenn sich der Fensterrahmen im nächsten Windows ändert, dann wäre es auch verrutscht.

Also muss man Fenster eigentlich für den kleinst möglichen Bildschirm entwickeln
und größer Fenster werden dann über Skalierung, Align, Anchor und Dergleichen unterstützt.

Lösung: Alles nochmal in ein Panel mit Align=alClient, falls nicht bereits ein Panel, GridPanel, FloatPanel oder Dergleichen vorhanden ist.
Nach dem Erstellen kann man dieses Panel dann im OnCreate manuell ans Fenster anpassen, also Panel-Width auf ClientWidth ändern und schon liegt, Dank Align, der Inhalt wieder an der richtigen Stelle.

**jobo**

Zitat von himitsu:

Zitat:

Ich gebe nie etwas bei ClientWidth oder ClientHight ein. Ich ziehe mir das Formular so groß, wie es nötig scheint.

Es ist egal, ob du ClientWidth, Width oder direkt via Maus die Fenstergröße änderst.
In der DFM gespeichert wird ClientWidth und ClientHeight, also abzüglich der Titelleiste und des Rahmens.

Das sollte jedem irgendwann klar sein, der die VCL benutzt.

Es ging mir darum, den "Werdegang" eines Formulars rüberzubringen. Häufig gibt es keinen festen Plan, der sich z.B. in vorgegebenen Größenangaben ausdrückt.

**TurboMagic**

Zitat von jobo:

Ich finde jedenfalls Programm gut, die sich nicht ungefragt und unnötig breit machen. Bspw. Calc.exe, (gibt es vielleicht gar nicht mehr unter Windows 10?) der Windows Taschenrechner: Eine „Display“ Label und eine Handvoll Buttons in der Standardeinstellung, plus eine Menuzeile. Das ergibt geschätzt 200x300 Pixel. Vollkommen okay für mich. Es größer zu machen, schiene mir eher lächerlich.

Doch Calc.exe gibt es, es wurde aber so umgebaut, dass es jetzt wohl eine andere GUI Bibliothek benutzt die zwar variable Fenstergrößen und Tastenskalierung bietet, was per se ja nicht schlecht ist, nur startet die Anwendung jetzt echt langsam im Vergleich zu früher.

**himitsu**

Ja, beim Taschenrechner, der wurde echt extrem groß und langsamer.
Allerdings sind da jetzt auch mehr Funktionen drin, wie z.B. eine Live-Historie und weil alles für Touch-Bedienung sein muß, ist es nun auch für Tastatur und Maus etwas überdimensioniert.

Und bei der Größe muß man auch bedenken, dass die Auflösung der Monitore inzwischen rießig ist und damit mehr Inhalt und Details drauf passen.

Hab grade in der DOSBox ein paar uralte Windowse auf der Platte rumliegen rumliegen, für Turbo Pascal.