Delphi-PRAXiS
Seite 1 von 3  1 23      

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Die Delphi-IDE (https://www.delphipraxis.net/62-die-delphi-ide/)
-   -   TForm.Height vs. ClientHeight (https://www.delphipraxis.net/207137-tform-height-vs-clientheight.html)

himitsu 26. Feb 2021 18:32

TForm.Height vs. ClientHeight
 
N'abend,

also ganz früher wurde mal Height in der DFM gespeichert (D7), was natürlich Spaß machte, als jede Windows-Version unterschiedlich große Titel und Border hatte,
also wurde nun ClientHeight gespeichert (so steht es auch in unseren DFMs drin)
aber nun im 10.4.1/2 sind fast ALLE Forms nun kaputt, da die Größe nicht mehr stimmt.

Trotz nichtfunktionierendem DeklarationSuchen hatte ich mich nun durchgekämpft und was gefunden.

Delphi-Quellcode:
type
  TControl = class(TComponent)
    property ClientHeight: Integer read GetClientHeight write SetClientHeight stored False;

  TCustomForm = class(TScrollingWinControl)
    property ClientHeight write SetClientHeight stored IsClientSizeStored;
    property ClientWidth write SetClientWidth stored IsClientSizeStored;

function TCustomForm.IsClientSizeStored: Boolean;
begin
  Result := not IsFormSizeStored;
end;

function TCustomForm.IsFormSizeStored: Boolean;
begin
  Result := AutoScroll or (HorzScrollBar.Range <> 0) or (VertScrollBar.Range <> 0);
end;
OK, um eine Minimalgröße mit Scrollbar zu bekommen, ist oftmals bei HorzScrollBar/VertScrollBar was eingetragen.
Somit würde bei diesen Fenstern ab nun Height statt ClientHeight gespeichert.

ABER, warum wird dann dort, wo noch ClientHeight in den DFM steht, das nicht geladen?
Weder in der IDE, noch im kompilierten Programm stimmt die Größe (es dürfte etwa die Standardgröße der TForm sein).

Geladen müsste es eigentlich werden, denn in der DFM steht es drin, also wird auch der Setter aufgerufen, aber scheinbar funktioniert hier was nicht und Delphi "ignoriert" es.
Und ja, wir kommen beim csReadingState durch.
Delphi-Quellcode:
procedure TCustomForm.SetClientHeight(Value: Integer);
begin
  if csReadingState in ControlState then
  begin
    FClientHeight := Value;
    ScalingFlags := ScalingFlags + [sfHeight];
  end else inherited ClientHeight := Value;
end;

Michael II 26. Feb 2021 22:56

AW: TForm.Height vs. ClientHeight
 
Kannst du mal ein Minimalprojekt posten und schreiben, was man testen soll?

Mir ist das nicht aufgefallen. ( OK, ich lade bei vielen Fenstern clientheight und clientwidth beim Erzeugen des Fensters, aber ich habe auch andere... und die sehen "normal" aus und "leben" teilweise seit Delphi2... )

Ich habe soeben eine Form erzeugt, clientheight und clientwidth werden normal geladen und die Werte stimmen (IDE (zum Beispiel 400x500) und zur Laufzeit (500x625, da scaled=TRUE und unter Windows 125%)).
Ich habe auch via Editor in .dfm clientwidth und clientheight verändert, das Projekt neu geladen. Sowohl in der IDE wie auch zur Laufzeit sind die Werte von clientwidth und clientheight wie erwartet.

( Vor einigen Delphiversionen gab's ja mal ein Problem beim Laden gewisser Fenster in der IDE. Soweit ich mich erinnere war bei jedem Laden das Fenster etwas kleiner oder grösser. Aber das wurde damals rasch behoben. )

Sehr wahrscheinlich teste ich nicht das, was du meinst... drum Minimalprojekt und Anleitung ;-).

himitsu 26. Feb 2021 23:24

AW: TForm.Height vs. ClientHeight
 
Joar, wo soll man anfangen?
Wir hatten nur "paar" der über 300 Units geöffnet, aber schon bei den Wichtigsten wurde einfach die Größe aus der DFM ignoriert.

Upgrade von XE zu 10.4.x

* inzwischen funktioniert zumindestens das Compilieren recht gut
* CodeInsight ist eine Katastrophe (aber ignorieren wir das erstmal)
* erste Versuche beim Debuggen von DesignTimePackages lief komplett schief, da von fast allen eigenen Packages keine Debuginfos gefunden wurden (ich würde die Schuld aber hier erstmal auf Eurekalog schieben)
* das Öffnen von FormUnits war saulangsam, aber da gab es schon Abhilfe


* und eben bei vielen Forms stimmt einfach die Größe garnicht

Wie gesagt, es wird einfach ClientHeight komplett ignoriert.
Es sind zwar mehrfach vererbte Forms, aber das sollte eigentlich egal sein.


Im Programm könnte ich den Setter von ClientHeight/ClientWidth überschreiben und das Problem bestimmt beheben, aber der FormDesigner nutzt nicht "die" Klasse des Vorfahren, sondern einen generischen TForm-Dummy, also kann ich da nichts machen und eine Lösung nur im Programm wäre sinnlos, wenn der FormDesigner beim nächsten Speichern das entgültig zerschießt.


Eine neue leere Unit/DFM, um die "vermuteten" Dinge zu erweitern, brachte leider keine Ergebnisse (hier funktioniert es).
Code:
object Form2: TForm2
  Left = 50
  Top = 100
  ClientHeight = 1200
  ClientWidth = 800
  HorzScrollBar.Range = 1100
  VertScrollBar.Range = 770

  Caption = 'Form2'
  Color = clBtnFace
  Font.Charset = DEFAULT_CHARSET
  Font.Color = clWindowText
  Font.Height = -11
  Font.Name = 'Tahoma'
  Font.Style = []
  OldCreateOrder = False
  OnCreate = FormCreate
  PixelsPerInch = 96
  TextHeight = 13
end
Nach dem Speichern ist es dann, wie erwartet, mit Width/Height, wo es vorher ClientWidth/ClientHeight war.
Siehe oben, liegt am HorzScrollBar, was ich ja schon rausgefunden hatte.
Und es wäre auch egal, wenn die "richtig" Größe gespeichert würde (egal ob als Height oder ClientHeight), nachdem sie beim Öffnen auch geladen wurde.
Code:
object Form2: TForm2
  Left = 0
  Top = 0
  Width = 833
  Height = 1100
  HorzScrollBar.Range = 1150
  VertScrollBar.Range = 770
  ...

Uwe Raabe 27. Feb 2021 10:26

AW: TForm.Height vs. ClientHeight
 
Dann setz doch ganz pragmatisch die Scrollbar-Ranges erst im FormCreate oder so.

himitsu 27. Feb 2021 12:19

AW: TForm.Height vs. ClientHeight
 
Joar, falls es nur daran liegt.
Im "einfachen" Test ließ es sich nicht reproduzieren.

Drum die Rundfrage, ob sowas Andere auch schon hatten und vielleicht sogar mit "einfacher" Lösung.


Und dann massig Units suchen, da manuell die DFMs bearbeiten und das nach PAS kopieren. (oder das mit der Größe eventuell auch anders lösen)


Hatte erstmal begonnen, nochmal die Branches zu vergleichen, zwischen XE un 10.4

Michael II 27. Feb 2021 13:34

AW: TForm.Height vs. ClientHeight
 
Zitat:

Zitat von himitsu (Beitrag 1484038)
Und dann massig Units suchen, da manuell die DFMs bearbeiten und das nach PAS kopieren. (oder das mit der Größe eventuell auch anders lösen)

Manuell die DFMs... wir sind hier unter uns; da kannst du ruhig "zugeben", dass du ein kleines Programm arbeiten lassen wirst. ;-)

Ich würde HorzScrollBar.Range, VertScrollBar.Range auch aus der DFM ins FormCreate verschieben.

"Mist" ist, dass (wie du schreibst) die Form-Abmessungen nicht mehr stimmen. Aber du hast ja sicher massenhaft Backups...

Michael II 28. Feb 2021 05:03

AW: TForm.Height vs. ClientHeight
 
Zitat:

Zitat von himitsu (Beitrag 1484025)
Wie gesagt, es wird einfach ClientHeight komplett ignoriert.

Code:
object Form2: TForm2
  Left = 50
  Top = 100
  ClientHeight = 1200
  ClientWidth = 800
  HorzScrollBar.Range = 1100
  VertScrollBar.Range = 770

  Caption = 'Form2'
  Color = clBtnFace
  Font.Charset = DEFAULT_CHARSET
  Font.Color = clWindowText
  Font.Height = -11
  Font.Name = 'Tahoma'
  Font.Style = []
  OldCreateOrder = False
  OnCreate = FormCreate
  PixelsPerInch = 96
  TextHeight = 13
end
Nach dem Speichern ist es dann, ...
Code:
object Form2: TForm2
  Left = 0
  Top = 0
  Width = 833
  Height = 1100
  HorzScrollBar.Range = 1150
  VertScrollBar.Range = 770
  ...

Nur noch kurz: Ist dein Beispiel (oben) eines wo es schief läuft?

Falls Nein, dann lies nicht weiter.

Falls aber Ja: Du schreibst, dass ClientHeight komplett ignoriert wird. Ist es auch mit Clientwidth so, wenn du Clientwidth im DFM nur gross genug (zum Beispiel 3000) wählst?
Wenn du deinen Monitor mit einer Auflösung 1920x1092 (zum Beispiel 1920x1092 HD Monitor mit 100% Skalierung unter Windows Anzeigeeinstellungen) verwendest, dann vermute ich, dass nach dem Speichern Height=1100 und Width=1940 drin steht.
(Dann würde das von dir beschriebene "Problem" aber abhängig von der "Windows Auflösung" und unabhängig von der Verwendung von ScrollBars auftreten: Wenn du im DFM ClientWidth=3000 und ClientHeight=3000 ohne Scrollbars wählen würdest, dann hättest du nach dem Laden und Speichern sehr wahrscheinlich Client Werte um 1924x1061 im DFM.)

himitsu 28. Feb 2021 12:41

AW: TForm.Height vs. ClientHeight
 
Nein, leider nicht.
Das ist jenes, was allen fehlerhaftens Forms gemeinsam ist (was ich bissher entdeckt hab),
aber "irgendwas" fehlt noch. :cry:

ClientHeight/ClientWidth ist in allen DFMs aus'm Delphi XE gespeichert,
aber in 10.3 und 10.4 (davor weiß ich nicht), da wird Dieses nicht "beachtet", wenn die Forms im Formdesigner oder im laufenden Programm geladen werden,
jedenfalls dort nicht, wo auch HorzScrollBar/VertScrollBar vorhanden sind.


Die Forms sind und waren kleiner als FullHD bei 100% und nach dem Laden sind sie "jetzt" noch kleiner,
ungefähr so hoch, wie eine nagelneue TForm ist.

Michael II 28. Feb 2021 13:05

AW: TForm.Height vs. ClientHeight
 
Zitat:

Zitat von himitsu (Beitrag 1484088)

Die Forms sind und waren kleiner als FullHD bei 100% und nach dem Laden sind sie "jetzt" noch kleiner,
ungefähr so hoch, wie eine nagelneue TForm ist.

Dann war dein gepostetes Beispiel etwas "schräg"... dort hast du ClientHeight = 1200 im Ausgangs DFM File (klar höher als HD) - und dieser Wert wurde in deinem Beispiel auf Height=1100 gekürzt. Dies entspricht exakt der Höhe, welche von Delphi gespeichert wird, wenn du unter Windows Auflösung ?x1092, 100% eingestellt hast.

Falls du ein weiteres Beispiel hast, dann gern - sonst bin ich leise ;-).

himitsu 28. Feb 2021 13:35

AW: TForm.Height vs. ClientHeight
 
Sorry, ich hatte das Beispiel testweise per Hand zusammengeklöppelt/gekürzt und bissl auf 100er gerundet.

Ja, mein Monitor ist zufällig 1920x1200, aber du hast Recht, ich hatte hier die Zahlen verdreht.
Es ist querformat und nicht hoch, also 1200 war Width und nicht Height. :oops:


Alle Zeitangaben in WEZ +1. Es ist jetzt 06:30 Uhr.
Seite 1 von 3  1 23      

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz