Control-Skalierung unter Windows 10

[Benmik]

Ich bin kürzlich auf Windows 10 umgestiegen, weil ich mir einen 4K-Monitor zugelegt habe. Natürlich musste ich dann die Skalierung ändern, sie steht zurzeit auf 175%. (Eigentlich hat so ein 4K-Monitor nur Nachteile, außer bei seinem Hauptzweck, dem Anzeigen von Bildern und Videos). Ich habe auf meinen Forms zig Textboxen, Panels und so weiter, die jetzt in großer Zahl verschoben und verknautscht sind. Die Formen stehen alle auf Scaled, eine Reihe von Größen funktionieren auch; ich glaube, wenn Text oder Aufschriften ins Spiel kommen, dann werden sie vergrößert, aber der Container nicht, vor allem nicht vertikal.

Muss ich das alles jetzt händisch machen oder gibt es da einen einfacheren Weg?

[Uwe Raabe]

Am schnellsten bekommst du das weg, wenn du die High-DPI Unterstützung im Manifest deaktivierst.

Soll die aber erhalten bleiben, dann musst du schon konkret zeigen, was du machst und was dann nicht funktioniert. Es gibt keine pauschalen Empfehlungen für diese Problematik, da man dort an zu vielen Stellmöglichkeiten was kaputt machen kann.

[Bernhard Geyer]

Also ich habe auch einen 4k (zweitmonitor) und habe mit 10.2 (fast) keine Probleme.
Oft liegt es an einen Code oder "Altforms" welche seit den Umstieg D6->X6->10.2 noch nicht neu gespeichert wurden.

In 10.3 gib es glaube ich durch übearbeitung des HighDPI-Funktionalität noch ein paar "Baustellen" die man selbst umschiffen muss.
Evtl. auch alte Controls funktionieren wegen fehlender Anpassung an neue Delphi-Versionen nicht richtig (Skalierungsmethode gibts jetzt in erweiterter Version).

[Benmik]

Das Umstellung in den Projektoptionen - Manifest von "Über Monitor V2" auf "Keiner" hatte durchschlagenden Erfolg, alles sah aus wie vorher.

Nur handelt es sich ja um ein Bildanzeigeprogramm. Und dann werden die Bilder leider mitskaliert und der Vorteil eines hochauflösenden Monitors ist dahin.

Zu einem Teil ist es auch so, dass ich Controls - in der Regel TPanel - je nach Inhalt anpassen muss. Das hatte ich zum Teil mit absoluten Pixelangaben gemacht, was mir jetzt natürlich auf die Füße fällt. Gibt es eine Möglichkeit, einen Faktor zu ermitteln?

[old7]

K.A. ob's Dir weiterhilft, aber bei allen meinen Forms habe ich damals (uraltes Delphi7pe) im OI auf
scaled := false;
umgestellt und überlasse seitdem das Skalieren den Systemeinstellungen von Windows (>=8). Keine Probleme dadurch/damit. Benutze aber auch nur einen Monitor und 100-150% für's Skalieren durch Windows und keine in die Skalierung reinfummelnden Manifeste.

[Uwe Raabe]

Zitat:

Zitat von old7 (Beitrag 1432031)

scaled := false;
umgestellt und überlasse seitdem das Skalieren den Systemeinstellungen von Windows

Das entspricht exakt dem Verhalten mit der DPI-Option "keine" und führt zu der unscharfen Bilddarstellung, da Windows einfach die Pixel vergrößert.

[Benmik]

So isses, das hatte ich auch schon probiert, da ich vorher ja etwas rumgelesen hatte.

Es scheint ja keinen Zauberweg zu geben. Ich habe jetzt so eine Art (Frickel-)Lösung gefunden. Man hätte sich schon denken können, dass absolute Pixelangaben einem irgendwann mal auf die Füße fallen.

[old7]

@Uwe Raabe: Was würdest Du empfehlen? Gibt es überhaupt eine (eher allgemeingültige) Empfehlung bezüglich "scaled := ?????" bei neueren Delphis?

Was meinst Du mit "der unscharfen Bilddarstellung"? Graphiken auf/in den Forms oder auch die Textdarstellung auf/in den Formularen? Oder das Zoomen von Windows (auf über 100%) allgemein?

[Uwe Raabe]

Zitat:

Zitat von old7 (Beitrag 1432037)

@Uwe Raabe: Was würdest Du empfehlen? Gibt es überhaupt eine (eher allgemeingültige) Empfehlung bezüglich "scaled := ?????" bei neueren Delphis?

Solange man nicht selbst an der Skalierung von Forms rumfummelt, was unter High-DPI Gesichtspunkten eigentlich nur kontraproduktiv sein kann, sollte Scaled immer auf True stehen. Je nach Delphi- und Windows-Version kommt man mit einem passenden Manifest sicher noch am ehesten zum Ziel.

Zitat:

Zitat von old7 (Beitrag 1432037)

Was meinst Du mit "der unscharfen Bilddarstellung"? Graphiken auf/in den Forms oder auch die Textdarstellung auf/in den Formularen? Oder das Zoomen von Windows (auf über 100%) allgemein?

Wenn die Anwendung selbst nicht als DPI-aware erstellt wurde, übernimmt Windows die Skalierung. Dabei wird z.B. auf einem 200% System einfach jedes Pixel verdoppelt bzw. bei anderen Skalierungen entsprechend interpoliert. Das führt dann zu einer verwaschenen oder verpixelten Darstellung.

Für Schriften kann man da noch etwas rausholen, wenn man unter Windows in den Eigenschaften bei Kompatibilität - Hohe DPI-Skalierung überschreiben das System (Erweitert) einstellt. Dabei bleiben aber Grafiken wie Icons und Bilder unberührt.

Die High-DPI Unterstützung wird mit jeder Windows- und Delphi-Version besser. Für halbwegs normale Anwendungen sollte das aktuell auch ausreichen, aber es gibt halt immer Sonderfälle, die noch nicht so richtig abgedeckt sind. Da muss man dann im Einzelfall nach Lösungen suchen oder halt Kompromisse eingehen.

[bcvs]

Zitat:

Zitat von Benmik (Beitrag 1432030)

Gibt es eine Möglichkeit, einen Faktor zu ermitteln?

Ja:

Delphi-Quellcode:

Screen.PixelsPerInch/96

Wobei die 96 davon ausgeht, dass du deine Forms in der IDE mit 100% designst.

[Uwe Raabe]

Zitat:

Zitat von bcvs (Beitrag 1432064)

Delphi-Quellcode:

Screen.PixelsPerInch/96

Funktioniert aber nur dann, wenn alle Monitore im System die gleiche DPI haben bzw. die Anwendung nicht Per Monitor DPI Aware unterstützt.

Den aktuellen DPI-Wert für ein Form bekommt man mit der protected function GetParentCurrentDpi. Der Parent eines Forms ist in der Regel nil, was dann den Wert des Forms liefert.

[Alfonso]

Ich habe festgestellt, dass wenn ich eine Rio Anwendung mit High DPI erstelle und (Monitorv2) und ich die Anwendung im 4 K Monitor starte, wo alles super aussieht, und dann auf ein Full HD bildschirm verschiebe, sich nichts tut. Das Fenster bleibt dann riesig, die Controls auch. Eigentlich sollte sich das Fenster dann doch automatisch verkleiner.
Setzte ich DPI auf "keiner", dann verhält sich das Formular wie erwartet.

Woran liegt das?

[Uwe Raabe]

Welche Windows Version?
Welche Skalierung ist auf den einzelnen Monitoren eingestellt?
Welche Skalierung hat der primäre Monitor?

[Alfonso]

Windows 10 1809
Primärmonitor 4K 200%
Sekundärmonitor Full HD 100%

[Uwe Raabe]

Wenn beide Monitore dieselbe Größe haben, dann sollte das Form auch auf beiden Monitoren gleich groß dargestellt werden. Auf dem 4k Monitor hat es halt nur doppelt so viele Pixel in X und Y.

Kannst du ein Beispielprojekt anhängen und genau beschreiben, was du erwartest und was passiert.

[Benmik]

Ich habe eine Form, wo der Anwender Optionen einstellen kann. Naturgemäß gibt es da zahlreiche GroupBoxen mit CheckBoxes, OptionButtons, Edits und so weiter; dazu werden die auch noch je nach Situation dynamisch angepasst, ein- und ausgeblendet, wodurch sich die Höhe der GroupBoxes und auch mal die des PageControls ändert. Ich habe natürlich alle absoluten Pixelangaben entfernt und mir eine Funktion geschrieben, die mir das alles einrichtet. Jetzt klappt alles unter allen Auflösungen und Skalierungen, aber es war eine völlig abartige Arbeit. Das kann es auf Dauer nicht sein.

[Uwe Raabe]

Dann solltest du nicht mit Left, Top, Width und Height arbeiten, sondern mit Align und AlignWithMargins. Sobald du dynamisch Positionen oder Größen setzt, musst du wohl oder übel den aktuellen DPI-Wert berücksichtigen. Wie sollte das auch sonst gehen?

[Benmik]

Naja, nehmen wir mal das angehängte Beispiel. Unter Windows 10 und einem 4K-Monitor bei einer Skalierung von 175% sah mein schönes Fenster plötzlich so aus (Bild 1). Vorher (und jetzt wieder) sah es ordentlich aus (Bild 2). In aller Regel ist es so, dass Breite keine Problem ist, Höhe wohl.

Die Lösung, die ich gefunden habe, ist garantiert keine, die den Embarcadero-Schönheitspreis gewinnen wird. Meine Prozedur nimmt das unterste Control, das in der GroupBox ist, und bestimmt danach die Höhe der GroupBox, also Top + Height + RandUnten. Dadurch wird es egal, was Windows mit der Skalierung treibt, ich orientiere mich an den tatsächlichen Verhältnissen, ohne genau zu wissen, ob und wieviel Windows da skaliert. In der Praxis funktioniert's.

[Bernhard Geyer]

Zitat:

Zitat von Benmik (Beitrag 1434086)

Naja, nehmen wir mal das angehängte Beispiel. Unter Windows 10 und einem 4K-Monitor bei einer Skalierung von 175% sah mein schönes Fenster plötzlich so aus (Bild 1). Vorher (und jetzt wieder) sah es ordentlich aus (Bild 2). In aller Regel ist es so, dass Breite keine Problem ist, Höhe wohl.

Kann auch sein das Windows mal wieder mist gebaut hat.
Habe hier auch schon den Fall gehabt das selbst der Windows Explorer nicht mehr richtig beim verschieben vom 2k (100%) auf den 4k (200%) Monitor richtig neu gezeichnet wurde.

[Rolf Frei]

Zitat:

Zitat von Benmik (Beitrag 1434086)

Naja, nehmen wir mal das angehängte Beispiel. Unter Windows 10 und einem 4K-Monitor bei einer Skalierung von 175% sah mein schönes Fenster plötzlich so aus (Bild 1). Vorher (und jetzt wieder) sah es ordentlich aus (Bild 2). In aller Regel ist es so, dass Breite keine Problem ist, Höhe wohl.

Die Lösung, die ich gefunden habe, ist garantiert keine, die den Embarcadero-Schönheitspreis gewinnen wird. Meine Prozedur nimmt das unterste Control, das in der GroupBox ist, und bestimmt danach die Höhe der GroupBox, also Top + Height + RandUnten. Dadurch wird es egal, was Windows mit der Skalierung treibt, ich orientiere mich an den tatsächlichen Verhältnissen, ohne genau zu wissen, ob und wieviel Windows da skaliert. In der Praxis funktioniert's.

Haben deine Forms AutosSroll=True? Das führt genau zu diesem Effekt. Daher immer alle Forms mit AutoScroll=False speichern udn das Prooperty zur Runtime setzen. Hast du eventuell noch etwas in Constraint definert, das du vergessen hast zur Runtime umzurechnen?

[Benmik]

Zitat:

Zitat von Rolf Frei (Beitrag 1434139)

Haben deine Forms AutosSroll=True? ... Hast du eventuell noch etwas in Constraint definert...

Beides nein. Beides habe ich noch nie benutzt.

[TurboMagic]

Falls AutoScroll = true ein solches Problem ist, wäre evtl. ein QP bugreport diesbezüglich angebracht.
Am besten mit einem Minimalbeispiel, z.B. eine Form wo's an ist und die zeigt was psssiert wenn's bereits statisch an ist
und ein Button drauf, der ein 2. Fenster öffnet bei dem das aus ist und erst zur Laufzeit aktiviert ist und genauso
Controls drauf die zeigen, dass das dann besser ist.

[Benmik]

Zitat:

Zitat von Uwe Raabe (Beitrag 1434085)

... mit Align und AlignWithMargins ... den aktuellen DPI-Wert berücksichtigen.

Wie sähe denn sowas aus?

[Uwe Raabe]

Zitat:

Zitat von Benmik (Beitrag 1434218)

Wie sähe denn sowas aus?

Zeig doch mal ein überschaubares Beispiel auf dem ich aufbauen kann.

[Rolf Frei]

Zitat:

Zitat von TurboMagic (Beitrag 1434192)

Falls AutoScroll = true ein solches Problem ist, wäre evtl. ein QP bugreport diesbezüglich angebracht.
Am besten mit einem Minimalbeispiel, z.B. eine Form wo's an ist und die zeigt was psssiert wenn's bereits statisch an ist
und ein Button drauf, der ein 2. Fenster öffnet bei dem das aus ist und erst zur Laufzeit aktiviert ist und genauso
Controls drauf die zeigen, dass das dann besser ist.

Das ist "As Designed" seit Jahren so oder wurde das mal geändert? Arbeite noch zu 95% mit Delphi 7 und da ist das der Default. Wenn eine Form AutoScroll=True hat, wird die Grösse der Form mit Absicht nicht angepasst und dafür Scrollbars angezeigt. Kann aber gut sein, dass das mal geändert hat und aktuell nicht mehr so ist.

[Benmik]

Zitat:

Zitat von Uwe Raabe (Beitrag 1434220)

Zitat:

Zitat von Benmik (Beitrag 1434218)

Wie sähe denn sowas aus?

Zeig doch mal ein überschaubares Beispiel auf dem ich aufbauen kann.

@Uwe Tut mir sehr leid, dass ich auf dein Angebot gar nicht geantwortet habe, war jetzt eine Woche auf Dienstreise und konnte nicht antworten. Ich müsste da viel Code extrahieren, ich schaue mal, ob ich's hinkriege.