Delphi 12 und HighDPI

[harfes]

Da noch nicht alle meine Komponeneten für D12 vorliegen, habe ich es zwar bereits heruntergeladen, aber noch nicht installiert. Eine Frage an alle, die D12 schon testen: Wie sieht es denn in D12 mit HighDPI aus? Hat sich da wirklich was getan? In D11.3 war es ja immer noch mit deutlichen Mängeln behaftet...

Hartmut

[Thomasl]

Gleiche frage.

Können Forms immer mit 96DPI in der DFM gespeichert werden. (auch Ohne Rundungsfehler wenn einer das mal mit einer anderen DPI öffnet/speichert)
Zur Zeit ist die IDE in HighDPI nicht benutzbar. Beim selbst Erstelltem Programm bekommt man es aber mit einigen Krücken ans laufen.

(Wir sind noch bei 11.2/11.3)

[Uwe Raabe]

In den letzten Monaten habe ich mit Delphi 11.3 schon einige VCL-Applikationen mit High-DPI-Support geschrieben bzw. angepasst. Das geht meistens auch recht gut und erfordert nur kleine Anpassungen. Delphi 12 erleichtert das auch noch etwas mehr.

Die IDE habe ich bisher dazu immer im /highdpi:unaware verwendet, da sonst entweder das Design visuell inakzeptabel ist oder die DFMs nicht in 96 dpi gespeichert werden. Mittlerweile versuche ich es schrittweise auch die IDE mit High DPI zu nutzen, auch wenn das forcierte Speichern mit 96 dpi dort immer noch nicht mit Bordmitteln unterstützt wird.

Kürzlich habe ich einen Artikel (Designing in High DPI) dazu geschrieben, in dem ich die Problematik beschreibe und mögliche Workarounds nenne. Parallel dazu arbeite ich noch an einem Plugin, das die fehlende Funktionalität nachbilden soll - ist aber im Moment noch ziemlich rudimentär.

Falls noch nicht geschehen kann ja jeder den das betrifft für den entsprechenden Feature-Request voten: RSP-35301: Option to design in Screen PPI but save in 96 PPI

Auch ein weiterer Request fällt in diesen Bereich: RSP-42546: Allow individual High DPI Mode for each VCL Form Designer instance

[harfes]

Ok, also auf einem 34"-Breitmonitor mit 96dpi zu arbeiten, ist absolutes NoGo! D.h. es hat sich in D12 nicht wirklich was Brauchbares getan und das Gefrickel geht weiter wie bei D11.

@Uwe: Deine Artikel habe ich gelesen (sehr gut! Danke dafür!) und auch bei Emba vorbeigeschaut - aber (vielleicht eine blöde Frage, da noch nie gemacht): wie "vote" ich denn da? Einen Button dafür habe ich nicht gefunden...oder habe ich was übersehen? :shock:

Hartmut

[himitsu]

also auf 38" UWQHD+ geht es mit 5K bei 100% schon noch (nur den Font des CodeEditors hab ich bissl hochgeschraubt)

[blawen]

Zitat:

Zitat von harfes (Beitrag 1529683)

wie "vote" ich denn da? Einen Button dafür habe ich nicht gefunden...oder habe ich was übersehen? :shock:

Einen "Button" gibt es nicht, aber einen "Link"
Anhang 56452

Ich betreibe meinen Laptop in drei unterschiedlichen Konstellationen:
- Nur Laptop (HD)
- Laptop mit einem 4k Monitor (200%) und einem HD-Monitor (100%)
- Laptop mit einem 4k Monitor (150%)

Zitat:

auf einem 34"-Breitmonitor mit 96dpi zu arbeiten, ist absolutes NoGo!

Die D11er IDE habe ich bisher auch im "unaware" Modus benutzt und abgesehen vom etwas verwaschenen Eindruck der IDE habe ich keine Probleme.
Die D12er IDE teste ich aktuell im "normalen" und soweit sieht es gut aus., wobei der "grosse" Test erst noch kommen wird.
Aktuell fehlen mir noch D12 Komponenten von Devart und TMS.

Mit der 200% Skalierung habe ich quasi auch nur 96 dpi. Für eine 4k Auflösung mit einer 100% Skalierung sind meine Augen definitiv nicht geeignet.
Wer weiss, vielleicht gibt es für diese auch irgendwann ein 4k Update ;-)

[himitsu]

Zitat:

Einen "Button" gibt es nicht, aber einen "Link"

du hattes er hatte schon auf den Link gedrückt und somit gevotet.

Nochmal drücken = deinen den Vote wieder entfernen (drum steht dort auch "Remove" :zwinker:)
und dann nochmal = den Vote wieder hinzufügen
und ...

(Selbes gilt für das "Beobachten" darunter)

[Harry Stahl]

Ich denke bei der Frage muss man unterscheiden, ob es

1 die Nutzbarkeit der IDE betrifft
a) als Einzelentwickler
b) im Team

2 die mit Delphi erzeugten Programme mit Unterstützung für HighDPI angeht

3 um VCL oder FMX Programme geht


Zu 1:

a)

IDE: Ich nutze als Einzelentwickler Delphi seit 11.x auf einem 3 Monitor-System, der Haupt-Monitor hat High DPI, die anderen 96 DPI.
Da gab es und gibt es nach wie vor Probleme, wenn man einzelne Fenster auf unterschiedliche Monitore verteilt. Da muss noch dran
gearbeitet werden, ich denke mit 12.1 wird es Verbesserungen geben

b)

Da ich keine Projekt-Entwicklung im Team mache, kann ich dazu nichts aus eigener Erfahrung sagen, nur so viel, das zu zu hören ist,
dass derzeit die Nutzung für Entwicklung von VCL-Programmen im Team bei unterschiedlichen Monitorauflösungen nur im 96-DPI-Formular-Modus ohne Probleme zu verwenden ist.

Zu 2:

VCL/FMX: Bei FMX-Programmen gibt es keine mir nennenswert bekannten Probleme bei der Entwicklung in der Delphi-High DPI-IDE (die Einstellungen unter Tools, HighDPI gelten ja nur für VCL-programme), da gibt es auch keine Unterschiede zwischen 11.3 und 12.x, funktioniert beides gleich gut.

Unter 12.0 stelle ich aber Verbesserungen für die im HighDPI- nutzbaren VCL-Programme fest. So musste ich z.B. bislang selber in bestimmten
Konstellationen bei zur Laufzeit erstellten Controls die Skalierungsfaktoren für Fonts in Listboxen, usw. selber manuell nachjustieren, je nachdem, ob das Programm auf einem HighDPI-Monitor oder auf auf einem 96 DPI Monitor startet (in einem mixed-System).

Das ist nun nicht mehr erforderlich, da stimmt alles zum Programmstart. Nach wie vor muss man Anpassungen vornehmen, wenn man das Programm dann auf Monitoren mit unterschiedlichen Auflösungen zieht (z.B. im "FormAfterMonitorDpiChanged"-Event), aber das ist unter der VCL wohl so (unter FMX nicht notwendig, da passt sich alles von alleine an).

Also hier schon mal einen dicken Plus-Punkt für Delphi 12.0.

zu 3)

Wie gesagt, unter FMX gibt es im Prinzip keine Probleme, aber VCL muss man unbedingt testen, insbesondere die von mir erwähnte Mixed-Systeme (also Monitore mit HighDPI und welche ohne HighDPI).

Ich persönlich empfinde Programme, die nicht DPI unterstützen und dann z.B. verwaschen angezeigt werden als absolutes NoGo.
Wenn man aber die über Monitor v2 Unterstützung aktiviert, muss man es aber auch richtig machen und die unterschiedlichen Konstellationen prüfen, sonst werden Elemente evtl. ganz groß oder ganz klein oder verschoben oder falsch positioniert dargestellt, was zur praktischen Unnutzbarkeit der Programme führt.

Ich bin jedenfalls froh, dass ich seit Delphi 11.x die IDE im HighDPI Modus nutzen kann. Gerade wenn die Sehfähigkeit schon etwas nachlässt quält einen ein unscharf dargestelltes Programm um so mehr...

[harfes]

@himitsu und blawen: danke für die Klarstellung - es ist ein wenig "strange", aber wenn es so geht...

@harry: danke für die ausführlichen Info's und: das mit den Augen kenne ich sehr gut!:shock: Und darum geht es ja letztendlich, denn das ist ja auch der Grund, warum ich bei den VCL-Programmen das so gut wie möglich hinbekommen muss - es gibt genügend ältere Benutzer mit nicht mehr so guten Augen, die von der Firma einen grossen Monitor bekommen, aber dann auf ein "unscharfes" Programm blicken müssen weil sie mit 300% o.ä. arbeiten.:-D

Sobald meine Fremd-Komponenten verfügbar sind (TMS ist gestern erschienen, Devart soll diese Woche kommen), werde ich mal testen. Wie sieht es mit FastReport (Emba-Edition) und den JEDI's aus?

Hartmut

[MEissing]

Fast Report 2023.3 ist in GetIt vorhanden

Jedi?
https://github.com/project-jedi/jvcl.../jvcl/packages
https://github.com/project-jedi/jcl/...r/jcl/packages

D29 = Delphi 12

[harfes]

@Matthias: perfekt - danke!

Hartmut

[jaenicke]

Das sieht unter Delphi 12 schon gut aus was die erzeugten Programme angeht. Dort sehe ich nun nach ersten Tests mit der Trial bei meinen privaten Projekten keine Probleme mehr.

Wobei ich persönlich mir für die Entwicklungsmaschine schlicht Monitore kaufe, die für meine Augen von der Größe zur Auflösung passen. WQHD auf 28" ist bei 100% z.B. für mich sehr gut lesbar. Warum sollte ich mir denn z.B. einen 27" Bildschirm kaufen und auf 5k betreiben, wenn ich dann nichts mehr sehen kann ohne Skalierung? Eine zusätzliche potentielle Fehlerquelle brauche ich nicht.

So kann ich mit Delphi ganz einfach mit 100% arbeiten, brauche keine Skalierung unter Windows und muss mir nur darum Sorgen machen, dass die mit Delphi geschriebenen Anwendungen unter HighDPI korrekt aussehen.

Davon abgesehen sollte Delphi natürlich fehlerfrei auch unter HighDPI funktionieren.

[ULIK]

Zitat:

Zitat von Uwe Raabe (Beitrag 1529602)

In den letzten Monaten habe ich mit Delphi 11.3 schon einige VCL-Applikationen mit High-DPI-Support geschrieben bzw. angepasst. Das geht meistens auch recht gut und erfordert nur kleine Anpassungen. Delphi 12 erleichtert das auch noch etwas mehr.

Du Glücklicher: Ich versuch schon seit fast 1 1/2 Jahren unsere Anwendung umzustellen und finde immer noch Sachen, die nicht gehen :cry:

Einfaches Beispiel (Delphi 11.3):

- Neues leeres VCL Projekt, DPI V2 Aware
- starten auf Monitor mit 100% (2650x1440)
- Fenster in der Höhe verändern, daß es fast die gesamte Höhe verwendet
- mit Shift+WINDOWS auf den zweiten Monitor mit 200% (3840x2160) schieben (--> nun sollte das Fenster nicht mehr ganz Platz haben)
- mit Shift+WINDOWS zurück auf den ersten Monitor schieben

--> Fenster hat nun eine andere Höhe

Oder das:

- Neues VCL Projekt, DPI V2 Aware, Form 400x400 bei 96 DPI Design
- starten auf Monitor mit 100%
- Fenster maximieren
- mit Shift+WINDOWS+Pfeil rechts auf den zweiten Monitor schieben
- mit Shift+WINDOWS+Pfeil links zurück auf den ersten Monitor schieben
- Maximierung aufheben

--> Jetzt hat das Fenster eine andere Größe (ca. 400x300)

Würde das unter Delphi 12 korrekt die Größe beibehalten?

Frage zu Delphi 12: sind die Konopka Komponenten inzwischen endlich durchgehend DPI Aware gemacht worden? Unter 11.3 gab es noch massenhaft hart hinterlegte Offsets für Layout-Berechnungen und Zeichenroutinen (z.B. in RzTabs.pas die 'Magic Numbers' von MMX durchgehen).

[Uwe Raabe]

So, ich habe mal mein kleines Plugin auf GitHub gestellt: https://github.com/UweRaabe/DFMScaling

Das ist noch eine ziemliche Baustelle und bei weitem noch nicht ausreichend getestet. Wer mag kann es ja mal ausprobieren. Feedback ist willkommen.

[Delami]

Zitat:

Zitat von Uwe Raabe (Beitrag 1529729)

So, ich habe mal mein kleines Plugin auf GitHub gestellt: https://github.com/UweRaabe/DFMScaling

Das ist noch eine ziemliche Baustelle und bei weitem noch nicht ausreichend getestet. Wer mag kann es ja mal ausprobieren. Feedback ist willkommen.

Gute Idee, es mag noch leider keine Frames. Beim Speichern gibt es Fehlermeldungen:

Zitat:

---------------------------
Error
---------------------------
Error reading Frame2.OnResize: Invalid property value.
---------------------------
OK
---------------------------

[Uwe Raabe]

Baustelle halt. Mach doch bitte mal ein Beispielprojekt zum testen.

[Delami]

Beispiel Projekt braucht es da nicht. Einfach ein neues Projekt mit einem Form und einem Frame erstellen, Frame auf Form zuweisen und speichern.
Fehler ist dann bei mir: Class TFrame2 not found.

[TigerLilly]

Zitat:

Zitat von Delami (Beitrag 1529747)

Beispiel Projekt braucht es da nicht. Einfach ein neues Projekt mit einem Form und einem Frame erstellen, Frame auf Form zuweisen und speichern.
Fehler ist dann bei mir: Class TFrame2 not found.

Jeder noch so kleine Aufwand, den du Uwe Raabe abnehmen kannst, ist Zeichen deiner Wertschätzung für den Aufwand, den er betreibt. Klar, ist kein großes Ding so einen Frame zusammenzuklicken, aber machen muss es ja doch wer.

[Uwe Raabe]

Ich hatte auch schon von anderer Stelle den Report bekommen, dass alleine das Zuweisen von Events den Fehler auslöst. Insofern ist das mit dem Beispielprojekt wirklich nicht notwendig.

Grundsätzlich würde ich es aber schon begrüßen, wenn es bei Fehlern konkrete und reproduzierbare Schritte gibt, gegebenenfalls unterstütz von einem kleinen Projekt um eventuell die Anzahl der Schritte zu minimieren und die übersehenen Eigenschaften in DFMs zu neutralisieren.

[Delami]

Zitat:

Zitat von Uwe Raabe (Beitrag 1529753)

Grundsätzlich würde ich es aber schon begrüßen, wenn es bei Fehlern konkrete und reproduzierbare Schritte gibt, gegebenenfalls unterstütz von einem kleinen Projekt um eventuell die Anzahl der Schritte zu minimieren und die übersehenen Eigenschaften in DFMs zu neutralisieren.

Klar, wird gemacht :)

[Uwe Raabe]

Der letzte Commit sollte jetzt das Event-Problem lösen.

[UliBru]

Der TOpenDialog in Delphi 12 sieht nach wie vor unsauber aus, siehe Anhang.
Wie bekommt man die kleinen Icons auf eine vernünftige Größe?

[TurboMagic]

Zitat:

Zitat von harfes (Beitrag 1529697)

Sobald meine Fremd-Komponenten verfügbar sind (TMS ist gestern erschienen, Devart soll diese Woche kommen), werde ich mal testen. Wie sieht es mit FastReport (Emba-Edition) und den JEDI's aus?

Hartmut

Inzwischen ist JEDI auch in GetIt.

[Kas Ob.]

@UliBru, Hi
I saw the name of your application and the types of the files then decided to see for my self, searched for acourate then clicked and got this response in the browser (attached a screenshot)
Anhang 56477
This made me smile :), "smells like a bothost and/or Server Farm" :-D
I swear i am not robot !, where is the CAPATCHA to proof myself ? i want to have fun solving puzzles with bicycles and fire hydrants.

Anyway, your hosting/server may be a little aggressive in filtering traffic.


ps: Kyivstar is the biggest ISP (broadband and mobile) in Ukraine https://kyivstar.ua/home-internet

[UliBru]

Zitat:

Zitat von Kas Ob. (Beitrag 1530296)

@UliBru, Hi
Anyway, your hosting/server may be a little aggressive in filtering traffic.

[offtopic on]
Hi,
sorry for the blacklist. Please try again
[/offtopic OFF]

[Kas Ob.]

Zitat:

Zitat von UliBru (Beitrag 1530299)

Zitat:

Zitat von Kas Ob. (Beitrag 1530296)

@UliBru, Hi
Anyway, your hosting/server may be a little aggressive in filtering traffic.

[offtopic on]
Hi,
sorry for the blacklist. Please try again
[/offtopic OFF]

Now, it is fine from both broadband and 4G from Kyivstar.

[UliBru]

Und ich hab noch ein "triviales" Problem mit HighDPI was ich mir nicht erklären kann.
Bei meinem Bildschirm arbeite ich mit 175% Skalierung, das passt am besten.
Nun mache ich eine einfache Form mit einer einfachen Groupbox.
Die Form ist 1130 px breit, ClientWidth ist dabei 1106 px. Die Groupbox ist 1078 px breit, Left = 14. Damit ist die Groupbox im Designer sauber symmetrisch.
Wenn ich das speichere zeigt mir das DFM eine Form1.ClientWidth vom 632 px und für die Groupbox eine Width von 616 px und Left mit 8 px. Das passt mit dem Faktor 1.75.

So, und wenn ich nun das Programm kompiliere und laufen lasse, dann ist die Goupbox nicht mehr mittig, die Form1.ClientWidth ist nun 1116 px anstelle von 1106 px.
Ich habe mal das kleine Testprogramm angehängt, es tut nix ausser die Daten noch anzuzeigen.

Wie bekommt man die Anzeige zur Laufzeit mit der Anzeige zur Entwurfszeit passend übereinander?

Hinweis: ich habe es mit Automatic bzw. Manuell mit 96 * 1.75 = 168 ppi versucht, DPI Awareness ist Per Monitor V2

[Uwe Raabe]

Könnte hiermit zusammenhängen: RSP-37558 - Form border uses IDE DPI, but should use form DPI

[UliBru]

Vielen Dank. https://quality.embarcadero.com/browse/RSP-37558 ist aber nicht die Ursache.
Ich bin dahintergekommen. Wenn man unter Project - Options - Custom Styles einen anderen Style wählt als default Windows dann ändert sich die ClientWidth.
Im Default-Modus ist alles richtig. Abhängig vom gewählten Style vergrößert sich die ClientWidth der Form bei mir um 10 oder 12 px (ich habe nicht alle Styles bzw. Scalings getestet).

Fazit: es ist wohl kein HighDPI Thema, sondern eine Frage der Styles. Das Problem wurde schon früher bemerkt, Gugl zeigt diverse Fundstellen.
Keine Ahnung ob es eine generelle Lösung gibt, ich finde schon was. Es ist eben mal wieder kein Rapid Application Development, wie öfter schon Kampf an unerwarteten Fronten.

[Uwe Raabe]

Du kannst ja mal versuchen ob es hilft wenn du in den Formular-Designer Optionen die VCL-Stile deaktivierst.

[UliBru]

Zitat:

Zitat von Uwe Raabe (Beitrag 1530559)

Du kannst ja mal versuchen ob es hilft wenn du in den Formular-Designer Optionen die VCL-Stile deaktivierst.

Nein, das hilft leider nicht. Es passiert dasselbe seltsame Verhalten.
Mittlerweile bin ich der Meinung dass es ein Bug ist. Wir haben ja das Schlagwort WYSIWYG. Und wenn der Style im Designer aktiviert ist, sollte ich ja zur Laufzeit genau dasselbe bekommen, was ich zur Designzeit bereits sehe. In diesem Fall ändert sich aber klar die ClientWidth der form, während ClientHeight passt.

[Uwe Raabe]

Wie ich das sehe, liegt das Problem darin, dass beim Skalieren des Forms Width das ClientWidth implizit über Winapi.Windows.GetClientRect ermittelt wird. Das ist naturgemäß von der DPI Awareness des Handles abhängig und berücksichtigt die dafür gültige BorderWidth, was in dieser Situation aber falsch ist.

Ich muss das mal in einer ruhigen Stunde näher untersuchen.