Bildschirmauflösung und Positionierung von Controls

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

[TurboMagic]

Nur weil er mehr Menüs hat muss er doch nicht langsammer starten oder?
Oder starten deine Delphi Programme signifikant langsamer nur weil du mehr
Menüpunkte reinbaust? Solange du dadurch nicht noch mehr sachen als vorher
initialisierst sondern die erst bei Bedarf erzeugst sollte doch nichts
langsamer werden, oder?

Grüße
TurboMagic