TForm.Height vs. ClientHeight

[himitsu]

OK, den genauen Grund konnte ich nun sehen, leider.

Es liegt indirekt an der Vererbung.

Es gibt 3 Vorfahren
* der Erste ohne DFM
* dann zwei mit DFM, mit ClientWidth/ClientHeight (Standard, wie bei fast Allen)
* und dann die eigenetliche(n) Form(s), teilweise mit Width/Height in der DFM (weil HorzScrollBar.Range bzw. VertScrollBar.Range)

Wenn die DFMs geladen werden, werden zuerst die Vorfahren mit ClientWidth/ClientHeight geladen und darüber dann die Property die eigentlichen FormDFM,
somit steht insgesamt sowohl ClientWidth/ClientHeight, als auch Width/Height, in der DFM.

ClientWidth/ClientHeight werden von TForm aber zwischengespeichert und erst später (TCustomForm.CMShowingChanged bzw. TCustomForm.ScaleForPPIRect) ausgewertet.
"Eigentlich" würde hier ja zuletzt Width/Height aus den DFMs geladen und die vorher geladenen ClientWidth/ClientHeight überschreiben, nur setzt die TForm dabei nicht FClientWidth/FClientHeight zurück, wodurch sie dann nachfolgend mit aller Hörte zuschlagen.


Im SetWidth/SetHeight könnte ich den Fehler zwar beheben, aber nur zur Laufzeit, im Programm, aber nicht im FormDesigner.



Aber das Schön, von alleine tritt dieser Fehler nur auf, wenn aus der DFM ClientHeight/ClientHeight geladen wird, was standardmäßig bei fast Jedem der Fall ist.
Und es betrifft Alle, die zusätzlich Width/Height in der DFM stehen haben, aber auch jene, welche Width/Height im Contructor beim Laden von SubKomponenten (vor dem Anzeigen) zuweisen, oder HorzScrollBar/VertScrollBar aktivieren.
Außerdem zerballert es dir die Form, wenn sich die DPI zur Laufzeit ändern, z.B. mit'm RDP verbinden oder einen Monitor anschalten/ausschalten/anstöpseln/...