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. :wink: (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:

Zitat von himitsu (Beitrag 1472209)

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:

Zitat von jobo (Beitrag 1472203)

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. :oops:

[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

[Marco Steinebach]

Hallo zusammen,
erst einmal ganz, ganz herzlichen Dank für die vielen Antworten. Nun, es ist ja auch nicht ganz einfach, einem Blinden zu erklären, wie was aussieht. Das gleiche Problem hätte ich, wenn ich einem gehörlosen Menschen erklären sollte, wie man eine Audio-Datei vernünftig schneidet. ;-)
Also: Mit der Skalierung meinte ich, dass man bei W10 einstellen kann, das Text z.B. 150% groß dargestellt wird. Und da ist bei älteren Anwendungen, wie meinen, beim Screen-Reader schluß - der liest schlicht nix mehr vor, außer der Titelleiste. ;-) . Bei modernen W10-Apps, Outlook o.ä. spielt das Ganze sowieso keine Rolle, da hier mittels UIA und MSAA und co ausgelesen wird.
Ich hab ein kleines Test-Programm, dem verpaß ich mal ein Panel und lade es mal hoch, vielleicht hat ja jemand Lust, sich das mal anzuschauen, und mir zu sagen, wie es wirkt,, etc.

Ach ja, und da mein gutes, altes D5 noch lange nix von Accessibility wußte, schau ich mir ganz sicher mal die accessibility-api an - danke für den Hinweis.

Herzlich grüßt
Wandogau

[KodeZwerg]

Falls Deine Frage war, wie ermittel ich den DPI Wert, könnte Dir das hier weiterhelfen:

Delphi-Quellcode:

{ hier beginnt eine Delphi methode }
function GetDPI: Integer;
var
  DC: hDC;
begin
  DC := GetDC(HWND_DESKTOP);
  try
    Result := GetDeviceCaps(DC, LOGPIXELSY);
  finally
    ReleaseDC(DC, HWND_DESKTOP);
  end;
end;

Bei 96 dpi (100%-Skalierung) sollte eine 1 returned werden.

[Marco Steinebach]

Hallo zusammen,
So, und nu geht die Fragerei schon los. ;-)
Mein Prog, ich hab das ganze Verzeichnis angehängt, der Code ist ja nun wirklich nix spannendes, ;-), hat ja im Grunde 5 Teile, in die man den Bildschirm teilen könnte:
Menüleiste
Eingabebereich
Ausgabebereich
Schalter
Copyright
Wieviele, und welche, Panels brauch ich, damit das Ganze sinnig wird? Um jeden der Bereiche eines und eines um alles???? Hiiilfe. ;-)
Über eure Antworten würde ich mich sehr freuen!
Herzlich grüßt
Wandogau

[KodeZwerg]

Ich lade mir mal Dein Projekt auf meinen Stick und würde für alles nötige eine Sinnvolle Panel-Ebene erstellen/nutzen.
Per AutoAlign braucht man sich dann um die Positionierung weniger Gedanken machen.
Morgen werde ich es Hochladen (ich hoffe es wurden keine Fremdkomponenten verwendet).

Mit freundlich Grüßen



Ps: Da ich Panels liebe zum Positionieren kann es Anfangs recht chaotisch wirken.
Für sehende ist da immer der Bevel-Part entscheidend, der bestimmt ob ein Panel sichtbar wirkt oder sich tranzparent einreiht.
Des weiteren gibt es noch den Tabulator-Tasten-Bonus den so ein Panel mit sich bringt.

[KodeZwerg]

Da ich leider nicht im Besitz der TMS Komponenten bin beschreibe ich Dir was für Änderungen ich machen würde.

1. Ein Grundpanel mit Align = alClient, ohne Border Bevel etc.
2. Pro 2'er Abschnitt ein weiteres Panel mit Align = alTop,
um die Augen zu schonen würde ich nur den unteren Rand aktivieren (Border Bevel)
3. Den Panels die aktiven Inhalt haben je ein OnResize zuweisen oder in den sub-panels bereits
gut Aligned vorgehen und Inhalt auf alClient für automatik setzen.
(mit aktiv meine ich hierbei mehrzeiliger krams, wie diese listviews)

Das was sehende Bemängeln würden und hoffentlich mit guter Panel Nutzung nun angegangen wird:
Diese 3 ListViews, viel zu klein dimensioniert, man erkennt fast nichts.
Die Checkbox "Anmeldung erfor" ist zu schmal, der Text hört da auf wie ich es schrieb.
Ich weiß noch nicht ob das ein normales programm verhalten ist oder das im betrieb sich ändert,
"Beginnt am:" "ListBox" "LbWochenTag1", aufs letzte Label bezogen.
"Endet am:" "ListBox" "LbWochenTag3", aufs letzte Label bezogen.
"Anmeldeschluß:" "ListBox" "LbWochenTag2", aufs letzte Label bezogen.


Hier eine längere Beschreibung wie ich das mit den Panels meine:
Ein völlig transparentes Panel als Hauptpanel wie oben Beschrieben.
Ein Panel mit alTop rauf, nennen wir es "GanzOben"
in dieses ein weiters Panel mit alTop, nennen wir es "pnlTitel"
in dieses ein panel mit alLeft und Caption = "Titel:".
als weiteres element das EditFeld mit alClient mit in pnlTitel rein.
nun in "GanzOben" unter "pnlTitel" ein Panel alClient namens "pnlKategorie"
in "pnlKategorie" ein Panel mit alLeft und Caption = "Kategorien:"
als weiteres Element die ListView alClient mit rein.
Nun ist das oberste der 2'er Abschnitte fertig.
So würde ich weitermachen bis ich bei "GanzUnten" angekommen bin.
Bei allen Panels wo ich es nicht angegeben habe = die Caption leeren.
Drauf achten wie die Panel werte für Border und Bevel sind,
am schlichtesten/am meisten transparent ist es wenn man nichts davon verwendet.
Kleine akzente schaden aber nicht, also würde ich jedem AbschnittsPanel wenigstens
einen Bottom-Strich zeichnen lassen.
Also immer einen Einzeiler mit einem mehrzeiler in ein Panel quetschen :-)

Momentant ist das Fenster resizable, wenn das ein feature sein soll würde ich dem hauptpanel ein
OnResize zuweisen und die Abschnitte per Height neu zeichnen lassen.
Anstelle OnResize kann man auch dem Anwender das Größengedöns per TSplitter überlassen.
Oder eine kombination aus beidem, delphi ist da sehr großzügig :-)


Später kann man ja noch mit dem Gedanken spielen eine selbstspeichernde konfiguration zu benutzen
um Formular dimension und splitter positionen zu speichern/laden...

Ich hoffe ich konnte dir das feeling ein klein wenig vermitteln!