Nja, der Designer/
DFM speichern immer nur in der aktuellen Ansicht,
dazu dann noch die jeweiligen DPI
und NACH dem Laden wird alles dann jedesmal umgerechnet, wenn sich diese gespeicherten von den aktuellen DPI unterscheiden.
Auch bekommst du massive Probleme, wenn du größer designst, als es dann zur Laufzeit oder beim nächsten Bearbeiten real verfügbar ist.
Windows/CreateWindow kürzt Fenster, welche größer als der Desktop sind, aber Delphi vergisst schon seit 20 Jahren darauf zu achten. (ebenso wie auf geänderte Rahmengrößen, falls Width/Height gespeichert wurde)
Es wird schon seit Jahren nicht mehr Width und Height gespeichert, sondern ClientWidth und ClientHeight.
Grund: im Windows sind seit XP in jeder Version und je nach einstellung die Fensterrahmen unterschiedlich dick.
Auch in Windows 10/11 ist der Rahmen nicht 0 oder 1 Pixel, so wie man es sieht, sondern knapp 8 Pixel, da der größte Teil unsichtbar ist. (dort, wo der Schatten gemalt wird und wo außerhalb des Fensters die Maus für das Vergrößern reagiert)
Und noch nie hat Delphi es geschafft beim Laden der
DFM die Größe des Inhalts richtig anzupassen, wenn das Fenster (CreateWindow) mit der falschen ClientSize generiert wurde.
Problematisch, wenn man mit
Anchors arbeitet.
Notlösug: ein Panel (ohne Rahmen und mit alClient) als Hintergrund, hinter allen Komponenten.
Außerdem wird die ClientSize nicht sofort gesetzt, sondern verzögert, da Emba oft Probleme hatte, beim Umrechnen von/zu Rect auf CientRect, wenn beim Erstellen das Fenster z.B. noch nicht sichtbar ist.
Besonders grausam wird es dadurch bei der Vererbung, denn
abhängig von gewissen Dingen (AutoScroll und HorzScrollBar/VertScrollBar.Range) wird doch Width und Height gespeichert und wenn sich das bei der Vererbung ändert, dann raucht es (hätte man mit 2 Zeilen Code reparieren können, aber weigert bösartig sich).
Ja, es ist unschön, aber ich kann jedem nur von AutoScroll und HorzScrollBar/VertScrollBar.Range abraten und wenn doch, dann erst im OnCreate setzen.