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/...

[Uwe Raabe]

Jetzt bin ich ja mal auf QP-Eintrag gespannt...

[himitsu]

Eine "schnelle" Lösung ist hier die Width/Height in den DFMs zu suchen und durch ClientWidth/ClientHeight zu ersetzen (notfalls mit bissl Zuschlag, aber egal, da wir mit Align arbeiten) und HorzScrollBar/VertScrollBar in den constructor zu verschieben.


Ich hab jetzt erstmal das absolute MinimalBeispiel gebastelt

• nagelneue VCL-Anwendung erstellen
• Alt+F12 (in die DFM)
• unterhalb von ClientHeight ein Height einfügen
  
  Delphi-Quellcode:

  object Form12: TForm12
    Left = 0
    Top = 0
    Caption = 'Form12'
    ClientHeight = 299
    ClientWidth = 635
    Color = clBtnFace

  Delphi-Quellcode:

    Height = 800
    Width = 50

• nicht zurück in den Designer
• speichern
• und F9
• =
• eigentlich müsste die jetzt 999 hoch und 50 breit sein, aber sie ist noch so, wie vorher im Designer gesehn, also was in ClientHeight/ClientWidth steht.

Bin grad nochmal im XE am Probieren.


Grundsätzlich ist es doch eh ein Fehler, dass Width/Height gespeichert wird?
wenn irgendwas nicht miz Align ausgerichtet ist, dann kann die Form per se falsch geladen werden. (das, weswegen man damals von Height auf ClientHeight umgestiegen ist)

[Rolf Frei]

Noch eine Anmerkung für dich, die aber eventuell bei aktuellen Versionen nicht mehr zutrifft:

Sobald AutoScroll=True im DFM steht, wird die Grösse (Widht/Height) des Fenster gespeichert. Ist das False wird ClientWidth/Height gespeichert. Ob das aktuell noch so ist, habe ich jetzt nicht getestet, aber in D7 war es noch so. Daher haben alle meine Formen AutoScroll=False und wenn ich es irgendwo benötige, setze ich das Propety im OnCreate der Form auf True. Wieso man da unterscheidet und nicht generell ClientXY nutzt, wissen wohl auch nur die, die das mal so angedacht haben.

Bis glaube ich D3 wurde nur Width/Height gespeichert was dann spätestens bei Windows XP (andere Titelgrösse der Fenster) zu falschem Forminhalt führte. Durch die grössere Titelleiste wurden in Delphi Formen der Clientbereich verkleinert. Da wurde dan auf ClientXY umgestellt, aber eben nur wenn AutoScroll=False ist, was IMO ein ziemlicher Blödsinn ist.

[himitsu]

Delphi 7 war's auch noch so.
Und ja, als es seit XP mit den verschiedenen Fensterrahmen/Titelleisten in jedem neuen Windows anders.
Man konnte da nur alles in ein Panel legen und das mit alClient, sonst rutschten schnell mal Komponenten aus dem Fenster.


Hmmm, also Grundsätzlich ist im XE der Code ähnlich.
Dort wird auch mal Height und mal ClientHeight gespeichert, abhängig von VertScrollBar.
Und im SetClientHeight wird ebenfalls in einer Variable zwischengespeichert.

Delphi-Quellcode:

  ClientHeight = 299
  ClientWidth = 635
  Height = 800
  Width = 50

Mein Beispiel liefert also auch im XE schon eine falsche Größe.

Aber zusammen mit der Vererbung (ClientHeight in einer DFM und Height in einer Anderen), da funktionierte damals noch (D5, D7, XE)

[himitsu]

https://quality.embarcadero.com/browse/RSP-33368

[himitsu]

Zitat von Closed:

Works As Expected

Ähhhh NEIN!

Erwarten tut man tu ich was Anderes.


Und außer dem Status kein Wort dazu.
Echt nett.

Vor allem, da das Problem vermutlich mit 2 Zeilen Code, ala FClientWidth:=0; gelöst wäre.

[himitsu]

Muß man da jetzt nochmal ein neues Tiket machen, oder bekommen die das so mit, dass man nochmal was nachgeschoben hat?
https://quality.embarcadero.com/browse/RSP-33368


Oder gibt es sonst wirklich niemand Anderes, der auch Form-Vererbung nutzt.

[Rolf Frei]

Ich sage es nochmals: Height und Width wurden nur gepeichert, wenn Autoscroll=True ist. Also die Frage, ob du diese auf True hast? Wenn ja setze das im Design auf False und setzte zur Runtime das Property im OnCreate der Form, wenn du dieses Feature nutzen willst. Ich nutze selber nur wenige vererbte Formen, aber bei keiner habe ich dieses Problem, weil bei mir alle Formen AutoScroll=False haben. Schau mal ob das in deiner Situation was ändert.

[himitsu]

Hier soll es aber Autoscroll sein, z.B. für bei Kunden mit zu kleinen Monitoren, was in der Fabrikhallte schonmal vorkommen kann.


Das Scroll ist auch garnicht das Problem ... nur dass Delphi hier einen Bug hat, beim Laden der Fenstergröße.