Ausführung auf 150% Bildschirm

[Pfaffe]

Meine Kunden entscheiden, ob sie auf 150% schalten. Sehr schön finden viele die Technik im Webbrowser Strg.-Mausrad. Die Geraration 50+ nimmt zu und die haben das Geld zum investieren.
Weiterer Erfahrungsbericht mit Test auf einem weiteren Gerät mit Win 10.1 und 150%.
Bei vcl-Programmen mit DX10 wird nicht alles skaliert, z.B. Combobox mit csOwnerDrawFixed.
Bei vcl-Programmen mit DX8 ist die Skalierung OK, jedoch die Schrift nicht super scharf.

[Sherlock]

DX8 skaliert gar nicht, das macht Windows für Dich. Darum ist es auch so unscharf. Das dürfte auch keinen Kunden freuen.

Im Prinzip wirst du nicht umhin kommen, das selbst auszuprogrammieren, auch und vor allem im Falle eines Rechners mit mehreren Monitoren (mit unterschiedlichen DPI). Dann wird Windows nämlich maximal bekloppt und selbst Microsoft Anwendungen skalieren dann nicht einheitlich richtig. Ich habe zB drei Monitore am Rechner, einer davon hat bei gleicher auflösung eine kleine Diagonale (Notebook halt) und das Outook wird immer unscharf dargestellt, Word hingegen einwandfrei. Übrigens, ich habe das Skalieren ausgeschaltet, und für alle Monitore 100% eingestellt. Warum mein 8.1 trotzdem dran rumspinnt, kann mir keiner sagen.

Sherlock

[Pfaffe]

Zitat:

Im Prinzip wirst du nicht umhin kommen, das selbst auszuprogrammieren

Das will ich nicht akzeptieren! Dafür habe ich doch bei Emba bezahlt. Ich klicke die Oberfläche zusammen und kann mich auf meine Fachwelt konzentrieren. Und mit FMX kann ich meinen Kundenkreis erweitern, da meine Programme jetzt auch unabhängig von Windows sind. Durch die Styles kann ich alte vorhandene Programme optisch aufpeppen und "Alten Wein in neuen Flaschen" verkaufen.

[bra]

Zitat:

Zitat von Sherlock (Beitrag 1323032)

Ich verzichte auf Skalierung. Wofür kaufe ich mir mehr Pixel, wenn ich sie dann durch aufgeblasene Inhalte wieder verliere? Freilich gibt es Kunden, die mehr oder weniger Freiwillig, die Skalierung eingeschaltet haben (ab Windows 7 oder 8 wird bei angeschlossenem FullHD-Display automatisch skaliert!!). Aber die sehen den Platzverlust genau wie ich, und lassen sich gerne dazu anleiten, die Skalierung zu dekativieren.

Es ist keine Lösung dem Kunden zu sagen, er soll die Skalierung abschalten. Zum einen gibt es sehschwache Leute, die ohne entsprechende Skalierung einfach gar nix mehr erkennen und zum anderen gibt es auch genügend moderne Monitore mit Auflösungen, bei denen man ohne Skalierung nicht viel erkennt.

Nur mal als Beispiel: Ich habe zuhause einen 40 Zoll Monitor mit 4k-Auflösung. Wenn ich da die Schrift auf 100% lasse, kann ich auch nur schlecht etwas lesen, also hab ich sie auf 125% gestellt.


Das Problem ist ja, dass schon die IDE selbst mit verschiedenen DPI-Skalierungen enorm rumspackt, wie soll sie es dann vernünftig mit den erstellten Programmen hinbekommen. Dazu gibt es leider Dutzende Einträge im Quality von EMB.

[Pfaffe]

Zitat:

Wenn Ihr in XE8 in der Manifestdatei nicht das DPIAware-Flag gesetzt habt, dann Scaled Delphi unter Windows 10 selber gar nichts (weil dem Programm eine 100%-Auflösung vorgegaukelt wird) und Windows nimmt die Skalierung selber vor.
...
Davon mal abgesehen, ist in DX10 ein Bug: Auch wenn Ihr "Hochauflösung aktivieren" deaktiviert, wird diese Option nicht (dauerhaft) gespeichert. Wenn Ihr den Dialog beim nächsten Mal wieder aufruft, dann ist die Checkbox wieder aktiviert.

Die Informationen von Harry Stahl haben mich ein gutes Stück weitergebracht!
Mit DPIAware-Flag in DX10 werden die Anwendungen deutlich Augen freundlicher, bei Auflösungen >100%, als wenn man die Skalierung Windows 10 überlässt. Leider, Leider, Leider, funktioniert das nicht zu 100% zuverlässig, so dass man viel testen muss, insbesondere wenn man Altprojekte mit DX10 compilieren möchte. Der Bug mit der Checkbox war mir nicht bekannt und hat meine Testerei ziemlich verfälscht. Ein Altprojekte ohne DPIAware-Flag verhält sich so, als wenn man es mit XE8 compiliert hat.
Liebe IDE Entwickler, bitte macht die Bugs raus!

[omp]

Ich bin jetzt auch über die Darstellungs-Probleme mit HDPI gestolpert.
Ribbon und Grid von DevExpress sehen sehr gut aus. Standard VCL-Komponenten sind aber viel zu groß.

Zum IDE-Bug (Checkbox ist beim Öffnen der Optionen immer aktiviert): Habe AppEnableHighDPI direkt in der .dproj auf false gesetzt. Scheint zu funktionieren.

Gruß, Harald

[omp]

Ich bin gerade wieder dabei, mich mit diesem Problem zu beschäftigen und habe auch etwas gefunden.

Kompiliert wird auf System mit 100% Skalierung (96 dpi), Hochauflösung ist in Projektoptionen aktiviert. In der dpr wird Application.DefaultFont auf Segoe UI eingestellt, Formulare haben ParentFont=true.

Auf Systemen mit 100% Skalierung (also entsprechend der Kompilierung) ist alles ok. Formulare haben DefaultFont. Auf Systemen mit abweichender Skalierung haben die Formulare wieder Tahoma.

Das Problem dürfte in TCustomForm.ReadState liegen: Dort wird Font.Size des Formulares angepasst, wenn die aktuelle Skalierung von der kompilierten abweicht. Ein Setzen von Font.Size führt dann automatisch zu ParentFont=false und somit zur Aktivierung der Font-Einstellung des Formulares mit Tahoma.

Gruß, Harald

[a.def]

Zitat:

Zitat von Pfaffe (Beitrag 1322802)

Ich habe ein Notebook mit Windows 10.1, einer Bildschirmauflösung von 1920x1080 und bei der Größeneinstellung 150%.
Führe ich dort ein mir Seattle Update 1 erstelltes Programm aus, dann wird das Programm nicht richtig dargestellt (scaled=true). Egal ob ich die "Hochauflösung" eingeschaltet habe oder nicht.
Erstelle ich das Programm mit XE8, dann funktioniert es.
Ist da was Kaputt in Seattle? Welche Erfahrungen habt Ihr?

Und schon der dritte Thread in dem gesagt wird, dass Berlin massive DPI-Probleme hat die es zuvor nicht gab.
Hoffentlich wird dieses Thema nicht runtergespielt wie die beiden anderen :(

[Uwe Raabe]

Zitat:

Zitat von a.def (Beitrag 1359617)

Und schon der dritte Thread in dem gesagt wird, dass Berlin massive DPI-Probleme hat die es zuvor nicht gab.(

Nur, daß es sich hierbei nicht um Berlin sondern Seattle gehandelt hat und es vorher dieses DPI-Flag überhaupt nicht gab (was logischerweise auch keine Fehler damit bedeutet).

So ganz kann ich das nicht nachvollziehen: Wenn man das alte Verhalten will, dann nimmt man einfach das Flag heraus. Dann sollte es sich doch wieder so verhalten wie früher, oder?

[a.def]

Das ist ja das Problem unter Delphi 10 Seattle oder Berlin.
Egal ob man es raus nimmt oder nicht, egal ob man DPIAware auf True oder False stellt, das Resultat von XE8 zu Seattle oder Berlin ist immer verschieden bei hoher DPI.
Verschieden heißt hier, dass nach XE8 alles "kaputt" dargestellt wird.