VCL.Graphics.pas DefFontData initialisierung veraltet

[Uwe Raabe]

MS Shell Dlg 2 ist eine logische Schriftart (es gibt keinen Font dieses Namens), die je nach Windows-Version unterschiedlich sein kann (deswegen FontSubstitutes). Damit wird unter anderem das Problem gelöst, dass auf älteren oder neueren Systemen die gewählte Schriftart eventuell nicht vorhanden ist bzw. durch die Spracheinstellung nicht verwendet werden kann. Insofern ist die Verwendung dieser Schriftart ein probates Mittel für eine weite Kompatibilität der Applikation bezüglich verschiedener Windows-Versionen und Windows-Sprachen.

Insbesondere schreibt Microsoft über diesen Font auch:

Zitat:

the shell font, also known as the system or default font,

Wenn Microsoft also eine andere Schriftwart als System- oder Default-Font haben will, dann brauchen sie das nur entsprechend in die Registry einzutragen. Haben sie aber nicht.

[KodeZwerg]

Ich habe mir gerade mal diesen Guideline durchgelesen und stimme Rolf zu das da was falsch ist, es sei denn Microsoft irrt sich.

Zitat:

Win32 or WinForms / Windows Vista or later = Use the appropriate Segoe UI font.

Zitat:

Extensible components or pre-Windows Vista = To target Windows XP and Windows 2000, use the 8 point MS Shell Dlg 2 pseudo font, which maps to Tahoma.
To target earlier versions of Windows, use 8 point MS Shell Dlg pseudo font, which maps to Tahoma on Windows 2000 and Windows XP, and to MS Sans Serif on Windows 95, Windows 98, Windows Millennium Edition, and Windows NT 4.0.

[Uwe Raabe]

Unter dem Aspekt dass Windows XP nicht mehr als Target-Plattform unterstützt wird, könnte man in der Tat über eine Anpassung des Default-Fonts nachdenken. Einen entsprechenden QP-Eintrag würde ich auch unterstützen.

Man muss dabei aber bedenken, dass sich eine Änderung dieser Grundeinstellung auf die Erweiterung bestehender Projekte auswirkt. Bestehende Forms behalten die Tahoma-Einstellung, während neue Forms dann mit Segoe UI erzeugt werden.

[KodeZwerg]

Zitat von Uwe Raabe:

Unter dem Aspekt dass Windows XP nicht mehr als Target-Plattform unterstützt wird, könnte man in der Tat über eine Anpassung des Default-Fonts nachdenken. Einen entsprechenden QP-Eintrag würde ich auch unterstützen.

Man muss dabei aber bedenken, dass sich eine Änderung dieser Grundeinstellung auf die Erweiterung bestehender Projekte auswirkt. Bestehende Forms behalten die Tahoma-Einstellung, während neue Forms dann mit Segoe UI erzeugt werden.

Zu Deinen Bedenken:
Ich wäre ja für einen Boolean oder switch, Legacy = linkt auf Tahoma, Modern = linkt auf Segoe UI
//edit: Also als Projekt-Option meine ich das, nicht als "Form.Property"

Zum QP:
Einen QP, so etwas habe ich noch nie gemacht und auch keine Erfahrung damit (ich mache da bestimmt alles falsch), meine Stimme würde ich definitiv auch geben wenn es jemand hier postet.



Danke auf jeden Fall für Deine mir wichtige Meinung!

[Uwe Raabe]

Zitat von KodeZwerg:

Ich wäre ja für einen Boolean oder switch, Legacy = linkt auf Tahoma, Modern = linkt auf Segoe UI
//edit: Also als Projekt-Option meine ich das, nicht als "Form.Property"

Das halte ich für den Zweck für Overkill und sehe eine Realisierung eher unwahrscheinlich. Schließlich steht es jedem frei, den Font seines Forms zu ändern. Man muss den oben beschriebenen Sachverhalt ja nur kommunizieren. Diese Projekt-Option müsste man ja auch irgendwie setzen.

[himitsu]

Einfach umstellen geht aber auch nicht.
Du kompilierst deine Anwendung neu und plötzlich sieht alles anders aus.

Aber die Variante wie beim OldCreateOrder wäre schon OK.
Alte Forms muß man dann manuell umstellen und neue Forms nutzen direkt den neuen Font.

[Uwe Raabe]

Zitat von himitsu:

Einfach umstellen geht aber auch nicht.
Du kompilierst deine Anwendung neu und plötzlich sieht alles anders aus.

Stimmt ja nicht. Da ein TForm seinen Font (aktuell Tahoma) in der DFM speichert und sich damit nicht mehr um DefFontData kümmert ist der Wert von DefFontData ziemlich egal. Lediglich die IDE wertet das aus, wenn man ein neues Form zum Projekt hinzufügt. Man kann das leicht verifizieren, wenn man einfach mal den Registry-Eintrag auf Segoe UI ändert und nach einem Neustart der IDE ein bestehendes VCL-Forms-Projekt öffnet und ein neues Form hinzufügt.

Wenn man allerdings ein Form dynamisch erzeugt und ohne DFM die Controls per Code darauf platziert, kann das schon Auswirkungen haben. Das ließe sich aber mit einer entsprechenden Initialisierung von DefFontData wieder auf den gewünschten Stand zurücksetzen. Das wäre auch im Moment schon ein gangbarer Weg um zur Laufzeit ein eventuelles Überschreiben von MS Shell Dlg 2 in der Registry durch den User zu neutralisieren.

[himitsu]

So schwer ist es nicht.
http://quality.embarcadero.com

Das "Legacy " lässt sich problemlos wie bei der OnCreate-Reihenfolge umsetzen. (Property OldCreateOrder)
Wenn das Property in einer bestehenden DFM noch nicht drin ist, dann wird es auf True gesetzt
und bei neuen Forms auf False. (oder andersrum)
Hier würde ich aber besser einen Enum anstatt eines Boolean verwenden, falls/wenn in Zukunft mal wieder der Fort geändert wird.

Ja, es einfach so unverhoft/unbemerkt zu ändern, kann paar Probleme bereiten.
Vor allem wenn der Font größer/länger würde, als der Alte, und dann Texte abgeschnitten werden oder überlappen.

[KodeZwerg]

Zitat von himitsu:

Ja, es einfach so unverhoft/unbemerkt zu ändern, kann paar Probleme bereiten.
Vor allem wenn der Font größer/länger würde, als der Alte, und dann Texte abgeschnitten werden oder überlappen.

Deswegen meinte ich es ja eher als Projekt-Option, nicht als Form.Property (oder Application.Property)
Somit wäre gewährleistet das bestehende Projekte nicht beschädigt werden selbst wenn man darin neue Forms erstellt.
Das war zumindest mein Grundgedanke zu Uwes berechtigten bedenken.
Ob sich dann die Projekt-Option auch als eine Form/Application Property ableitet, da bin ich überfragt, aber sicherlich denkbar möglich. (Vielleicht als Read-Only, so das man es eh nur in den Optionen ändern kann)
Es müsste ja die zugrundeliegende RTL angepasst werden, wenn ich dann noch an diese ganzen Style-Hooks denke wird mir schlecht.

Wenn ein neues Projekt entworfen wird sollte es halt aktiviert sein, bei alten eben nicht. (...aber halt nachrüstbar was dann natürlich zu mühsamen durchtesten jeder Form führen könnte wenn die IDE da keine automatische Anpassung für einen vornimmt...)


Ich bin jedenfalls voller Hoffnung das es realisierbar ist.


Auch würde mich eine Option freuen die das Windows Theme (dark/light) für moderne Applikationen einführt.

[himitsu]

Das ist halt eine Überlegung.

In der DFM gespeichert, kannst jeder Form in Ruhe nacheinander umstellen und prüfen/anpassen.

Global gespeichert, stellst du es um und mußt dann alle Forms zusammen prüfen/anpassen.
Wenn sich aber alle Forms selbst anpassen, weil sie z.B. bereits für MultiLanguage vorgesehn sind, so sich Textlängen auch ändern können, dann ist eine "globale" Einstellung auch ganz nett.
(OK, wir haben unsere Forms/Komponenten abgeleitet und könnten es auch zentral an einer Stelle ändern, selbst wenn es je Form/DFM gespeichert ist)