Control-Skalierung unter Windows 10

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

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

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 von Rolf Frei:

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.

[Rolf Frei]

Zitat von 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.

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.