Um es nochmals zu trennen
* einmal OldCreateOrder, bei uns zwischen XE und D11
* und andererseits LadeProbleme im D11, z.B. bei ClientWidth und Width, mit Zuweisung im Code (Create bzw. OnCreate) sowie Unterschiede zwischen DFMs bezüglich der FormVererbung
z.B. in VorfahrDFM ClientWidth und in NachfahrDFM mit Width, oder Width im Create oder OnCreate und ClientWidth in
DFM.
Es gab immer wieder irgendwo ein paar Sonderfälle, wo es mit dem OldCreateOrder:=False; irgendwo nicht mehr ging.
In
DFM mit False, in
DFM mit True, nicht in
DFM oder teilweise in
DFM und dann auch noch unterschiedlich, ...
Wir haben hier aber auch eine wilde Mischung.
* im Delphi mit FormVererbung (mehrere
DFM pro Form)
* über den Greatis FormDesigner die
DFM zur Laufzeit aus der Datenbank
* manuell zur Laufzeit die
DFM aus der Datenbank (TReader.ReadRootComponent)
Ich glaub ganz zu Beginn hatte Emba im DataModul das Ignore-OldCreateOrder vergessen und dann knallte es, wenn das noch in der
DFM stand.
Da wir zur Laufzeit fehlerhafte Property ignorieren, ähnlich wie im FormDesigner der
IDE (wobei wir ebenfalls den Fehler abgangen und ins Log schreiben, bzw. anzeigen, anstatt abrauchen zu lassen)
Dem TReader.OnError im Form.ReadState etwas zugewiesen und darin Handled=True.
Den letzten Fall, wo OnCreate doppelt ausgeführt wurde, hatte ich dann so abgefangen.
Da wir die Stelle nicht fanden, wo/warum hier OldCreate immernoch/wieder True war, wurde letztendlich einfach das erste OnCreate (hier im inherited) unterdrückt.
Delphi-Quellcode:
procedure TCimBaseForm.DoCreate;
begin
{ TODO -oUmstieg XE DX/D11 -cUmstieg XE DX/D11 : Dieses Handling kann entfernt werden, sobald kein XE mehr benutzt wird }
// Delphi 11 löscht OldCreateOrder, weil es seit längerem nicht mehr benutzt wird
// Delphi XE fügt im FormDesigner OldCreateOrder:=True; ein, wenn es das Property (noch) nicht findet. Es muß aber False sein/bleiben.
{$IFDEF VER220 DelphiXE}
// Wenn OldCreateOrder=True in DFM steht dann kommst es schon im Constructor hier vorbei, aber es darf erst im AfterConstrution hier ankommen.
// Außer dem StackTrace hab ich aber nichts gefunden, was hier erkennen lässt, wer das aufruft.
// Im AfterConstruction ist es aber definitiv False, da siehe TCimBaseForm.Create, somit kann es hier eigentlich nur noch vom Constructor kommen
// und in diesem Fall wird OnCreate nicht ausgefürt, da es sonnst doppelt ausgeführt wird, also nochmal in AfterContruction, und es dann knallt.
if OldCreateOrder
then begin
OldCreateOrder := False;
Exit;
end;
{$ENDIF}
try
inherited;
except
Exception.InsertStackInfo(SecureFullName('
TCimBaseForm') + '
.DoCreate');
// TCustomForm.DoCreate - TCustomForm.HandleCreateException -> Application.HandleException -> THauptForm.ApplicationEvents1Exception -> CimShowExceptionDialog
end;
end;
Loaded ist aber auch nicht deterministisch.
Vor allem bei FormVererbung und/oder Kreuzreferenzen von Forms/Datenmodulen/Komponenten, wird das verzögert.
z.B. auf einer Form ein TDBEdit und eine TDataSource, aber das Edit vor der DataSource in der
DFM, dann kann dem Edit.DataSource die DataSource noch nicht zugewiesen werden,
somit ist beim DBEdit.Loaded dieses Property noch nicht gesetzt, da es dann erst ganz am Ende zugewiesen wird und dann da nochmals dessen Loaded.
Das betrifft auch DatenModule und Frames, wo nach dem Laden dieser eventuell erst viel Später, also nach dem Laden aller zusammengehörenden Forms/Frames/Datenmodule
die fehlenden Referenzen aufgelöst werden und erst dann das Loaded ausgelöst wird. (z.B. GlobalFixupReferences)