VCL.Graphics.pas DefFontData initialisierung veraltet

[Rolf Frei]

Habe eben festgestellt das im Jahr 2021 der DefFontData Record in der Vcl.Graphics Unit immer noch mit "MS Sans Serif" intialisiert wird?! Hat das einen vernünftigen Grund oder wieso wird das nicht an den aktuellen Stand (Segoe UI) angepasst? Sollte man das mal melden?

[himitsu]

Ich glaub das wurde nach D7 einmal geändert.
Sei doch nicht so ungeduldig ... die sind nicht die Schnellsten.

Aber diese Vorgabe kann man doch auch selber ändern?

Tipp: in quality.embarcadero.com schauen, ob es schon was gibt, oder eine Anfrage stellen, dass das mal "aktualisiert" werden möge.



Wir (Arbeit) haben nahezu alle unsere Komonenten und die Forms abgeleitet, somit hatten wir keine Probleme da den Font mal anzupassen.
(weiß nur grad nicht was da aktuell ist, bei uns)

[Rolf Frei]

Ja, dass man das einfach in der DPR ändern kann ist mir schon klar, aber wieso ist das immer noch so drin? Hat das irgend welche Gründe, die ich gerade nicht sehen kann? Kann das eventuell mit dem Fontnamen "Default" irgendwelche Nebenwirkungen ergeben? Sollte man dafür vieleicht mal einen Report aufmachen?

Bekommt man eigentlich irgendwie den Namen des Default Font der aktuellen Windows Version?

Habe mal einen Report gemacht. Eine Suche nach DefFontData hatte kein Ergebnis geliefert.

[Uwe Raabe]

DefFontData wird in InitDefFontData initialisiert. Die direkte Initialisierung der globalen Variable in der Deklaration ist damit obsolet.

[Rolf Frei]

InitDefFontData macht das aber auch nicht richtig. Da ist dann Tahoma als Default drin zumindest noch in meinem 10.3. Ist das in 10.4.2 anders? Da wird in der Registry der Wert aus FontSubstitutes->MS Shell Dlg 2 gelesen und das ist meiner Meinung nach so nicht richtig. Da muss es doch eine andere Funktion geben mit der man den Defaultfont des Betriebsystems bekommt?! Tahoma wäre ja dann nur die Ersatzsschriftart.

Delphi-Quellcode:

var
  f: TFont;
begin
  f := TFont.Create;
  ShowMessage(f.Name);
  f.Free;
end;

[Uwe Raabe]

Was verstehst du denn unter dem Defaultfont des Betriebsystems?

Und wieso ist die Schrift unter MS Shell Dlg 2 eine Ersatzschriftart?

[Rolf Frei]

Zitat:

Zitat von Uwe Raabe (Beitrag 1488351)

Was verstehst du denn unter dem Defaultfont des Betriebsystems?

Und wieso ist die Schrift unter MS Shell Dlg 2 eine Ersatzschriftart?

Sind das ernst gemeinte Fragen? :gruebel:

Die Defaultschriftart des OS ist das was eben als Standard von MS vorgegeben wird und das ist nun mal unter Windows 10 (glaub seit Vista) Segoe UI und nicht Tahoma.

FontSubstitutes = Ersatzschrift wenn die orignale Schrift nicht vorhanden ist.

Zitat:

Font substitution is the process of using one font in place of another when the intended font either is not available or does not contain glyphs for the required characters.

[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:

Zitat von Uwe Raabe (Beitrag 1488893)

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! :thumb:

[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:

Zitat von himitsu (Beitrag 1488899)

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)

[Uwe Raabe]

Zitat:

Zitat von KodeZwerg (Beitrag 1488895)

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:

Zitat von himitsu (Beitrag 1488910)

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]

Ohh, stimmt, in der VCL wird der Font bei einer neuen Form gespeichert.

Ich hatte grade FMX im Blick und wenn dort am Font nichts geändert wurde, dann wird er dort nicht gespeichert.

[Uwe Raabe]

FMX verwendet aber auch kein DefFontData.

[TurboMagic]

Hallo CodeZwerg,

meölde dich doch einfach mit deinem EDN/EMBT Login unter quality.embarcadero.com an,
klicke aauf den großen roten Button zum erstellen eines neuen Eintrags, wähle als Typ
Feature Request aus und fülle das Formular aus. Einfach mal reinschreiben, dass du die
VCL default Font geändert haben willst und als Kategorie VCL auswählen.
Abschicken und uns die URL (wird kurz in einem Popup angezeigt, also einfach draufklicken)
hier schicken. Dann finden es sicher einige und stimmen dafür.

Wenn ich sowas kann, kannst du das bestimmt auch ;-)

Grüße
TurboMagic

[KodeZwerg]

Zitat:

Zitat von TurboMagic (Beitrag 1488950)

Hallo CodeZwerg,

Wenn ich sowas kann, kannst du das bestimmt auch ;-)

Hallo DurboMagic!

Was muss ins Feld Summary rein?

[KodeZwerg]

https://quality.embarcadero.com/browse/RSP-33937 Ich hoffe ich habe alles richtig gemacht. (Da könnt Ihr voten)

[Rolf Frei]

Ich habe das schon vorher gemeldet (RSP-33856). Euer Gedankengang mit der TForm ist eigentlich überflüssig. Der Font wird seit jeher in der DFM gepseichert und wenn man da den Font aktualisieren will, muss das zur Runtime oder halt im der IDE manuell bei jeder Form gemacht werden. Einfach nachträglich automatisch sollte das auf keinen Fall passieren.

Es geht in meinem Fall auch garnicht um die Fromularfonts sondern und die Vorgabe bei der Erstellung eines TFont. Der sollte mit "Segoe UI 9pt" initialisiert werden und nicht mit dem veratlteten Tahoma. An dem Formular darf da nichts automatisch geändert werden, da das sonst durch den unterschiedlichen Platzbedarf, zu einem Fehlverhalten führen kann. Wenn jemand seine Anwendung auf Segoe UI umstellen will, kann er das mit dem refind.exe auf einfache Art machen.

Emba muss da lediglich dafür sorgen, dass DefFontData/Init... nicht mehr Tahoma nutzt sondern das neue Segoe UI. Weiter braucht man da nichts ändern.

[Uwe Raabe]

Na ja, das deckt dann zwar deinen konkreten Anwendungsfall ab, aber berücksichtigt nicht die Auswirkungen an anderer Stelle. Wie schon gesagt, wenn du es ausprobieren willst, musst du nur den Registry-Eintrag entsprechend ändern. Ich habe daraufhin (wie erwartet) festgestellt, dass in einem Projekt alle neuen Forms mit Segoe UI erstellt wurden, was zu einer Inkonsistenz mit den anderen Forms der Anwendung führte. Im Falle einer Änderung in DefFontData muss das halt allen Beteiligten klar sein.

Besser wäre es meiner Meinung nach, wenn wir (wie früher) das Template für ein neues Form anpassen könnten.

[Rolf Frei]

Ja aber das ist ja nichts Neues. Früher war alles MS Sans Serif und da wurden dann irgend wann auch die neuen Formen mit Tahoma erstellt. Dazu gibt es ja das refind Tool um das relativ einfach zu ändern. Ist also nichts anderes als das was wir früher schon mal hatten. Hier muss man dann halt einfach mit der Zeit gehen. Wer seine Formen nicht mit Segoue UI will, machts sich halt eine eigegen TForm im Repository als Designvorgabe (oder gibt es das nicht mehr in neueren Delphis?). Wenn man dann "neue Form" auswählt wird diese mit den gewünschten Fonts verwendet. Ich nutzte das schon lange udn alle meine Formen bekommen so Segoe UI als Default, wenn ich eine neue Form erstelle.

Es geht bei mir nicht um einen spezifischen Fall sondern grundsätzlich darum, dass TFont nicht mit dem Standardfont erstellt wird. Die meisten Komponenten werden dann den Font eh selber setzen oder vererben, aber in meinem Fall von einer 3rd Party Komponente wurde eben nur ein TFont erstellt, ohne die Schirft zu ändern. Dadurch hatte ich in D7 dann MS Sans Serif in dieser Komponente. In neueren Delphi's ist es Tahoma. Dadurch bin ich erst auf diese Problem gestossen.

[KodeZwerg]

Hallo Rolf, Du hättest ja hier mal erwähnen können das Du bereits einen QP gemacht hast, auch wenn der etwas von meinem Abweicht.

Diesen Code ruf ich im FormCreate mit Self auf, alle Controls (ParentFont = True) nutzen dann das was das System hergibt solange man die Font nicht selbst eingestellt hat. Auch eine Größenanpassung wird vorgenommen.
Vielleicht hilft Dir das solange um über die Runden zu kommen bis Embarcadero was unternimmt.
Microsoft wird sicherlich nicht den HKEY ändern da die Gefahr besteht das vorhandene/alte Software damit einen defekt erleidet.

Delphi-Quellcode:

procedure ApplyFontAndScale(aForm: TForm);
var
  OldSize : Integer;
  Font    : TFont;
begin
  OldSize := aForm.Font.Size;
  if Screen.MessageFont.Size <> OldSize then begin
    Font := TFont.Create;
    try
      Font.Assign(Screen.MessageFont);
      Font.Size := OldSize;
      aForm.Font := Font;
    finally
      Font.Free;
    end;
    aForm.ScaleBy(Abs(Screen.MessageFont.Size), Abs(OldSize));
  end else
    aForm.Font := Screen.MessageFont;

  if aForm.BorderStyle <> bsSizeable then begin
    if aForm.Height > Screen.WorkAreaHeight then
      aForm.ScaleBy(Screen.WorkAreaHeight, aForm.Height);
    if aForm.Width > Screen.WorkAreaWidth then
      aForm.ScaleBy(Screen.WorkAreaWidth, aForm.Width);
  end;
end;

[Rolf Frei]

Habe doch in Post #3 geschrieben, dass ich einen Report eröffnet habe. :wink:

[KodeZwerg]

Zitat:

Zitat von Rolf Frei (Beitrag 1488311)

Habe mal einen Report gemacht.

Stimmt schon, ein Link wäre für beginner wie meiner einer wäre da hilfreicher gewesen als nur diese Aussage, aber Du hast natürlich Recht "erwähnt hast Du es" ;-)
(Ich habe absolut keinerlei Erfahrung mit diesen QP Zeugs, wenn jemand einen Link posted kann ich zumindest hin hüpfen wenn mir die Topic zusagt und mit-voten)

ob es was bringt steht dann wieder auf einem anderen blatt papier hehe