Reise von Berlin nach Athens

[jsheyer]

FastReport ist kein Problems, du musst das passende Setup haben.

Das mit dem Parallel Betrieb ist schon lange möglich, nur wenn z:b. das Update von 12.1 auf 12.2 käme dann wird 12.1 deinstalliert.
Oder in Deiner alten Version von 10.1 auf 10.2, 10.3, etc. dann wird die jeweiligere 10er Version deinstalliert.
Die letzten Jahre hatte ich eigentlich keine Probleme damit.

[Uwe Raabe]

Zitat von jsheyer:

Oder in Deiner alten Version von 10.1 auf 10.2, 10.3, etc. dann wird die jeweiligere 10er Version deinstalliert.

Das ist nicht ganz richtig! Delphi 10, 10.1, 10.2, 10.3, 10.4, 11 und 12 können nebeneinander existieren (tun sie hier auch). Die 10er Reihe war ein Ausreißer, aber seit 11 ist man wieder zu vernünftigen Versionsnummern zurückgekehrt. Mal sehen wie lange das anhält...

[Papaschlumpf73]

Bei mir gab es auch immer mal Theater mit Parallel-Installationen. Vor allem bei den Drittanbieter-Komponenten. Deshalb hat bei mir jede Delphi-Version seine eigene VM. Das hat sich ganz gut bewährt.

[dummzeuch]

Wichtig: Solange Du Projekte in beiden Versionen parallel bearbeitest, ist die Property TForm.OldCreateOrder ein Problem:
* Delphi 12 löscht sie aus den DFM-Dateien und nimmt False als Default an
* Ältere Delphi Versionen erstellen sie beim Abspeichern wieder, wenn sie nicht existiert, mit OldCreateOrder=True. (Neue Formulare erstellen diese älteren Versionen mit OldCreateOrder=False.)

Das kann fatale Konsequenzen haben, denn mit OldCreateOrder=True, werden FormCreate Events ausgeführt, bevor der Constructor komplett ausgeführt wurde, wie das früher mal bei Delphi 5(?) oder sogar noch früher der Fall war.

Ich meine mich dunkel zu erinnern, dass Uwe Raabe darüber gebloggt hatte.

[himitsu]

Jupp, das bezüglich OldCreateOrder.
Bei uns D10/11 und XE.

Da Emba sich eh weigerte einen anderen Bug zu beheben,
haben wir nun also einen Hook im DFM-Reader der IDE, welcher auch das gleich behebt.



Bei z.B. Formvererbung gibt es massive Probleme,
ebenso wenn jemand im Constructor/DFM sowohl Width/Heigt als auch ClientWidth/ClientHeight setzt, denn ClientWidth/ClientHeight wird verzögert im AfterConstructor geladen, womit ein später zugewiesenes Width/Height bösartig ignoriert wird.

[dummzeuch]

Zitat von himitsu:

Bei z.B. Formvererbung gibt es massive Probleme,
ebenso wenn jemand im Constructor/DFM sowohl Width/Heigt als auch ClientWidth/ClientHeight setzt, denn ClientWidth/ClientHeight wird verzögert im AfterConstructor geladen, womit ein später zugewiesenes Width/Height bösartig ignoriert wird.

Oh, das ist jetzt interessant. Seit welcher Delphi-Version ist das? Das könnte evtl. der Grund für ein Problem in GExperts sein.

[himitsu]

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)

[SearchBot]

Zitat von dummzeuch:

Wichtig: Solange Du Projekte in beiden Versionen parallel bearbeitest, ist die Property TForm.OldCreateOrder ein Problem:
* Delphi 12 löscht sie aus den DFM-Dateien und nimmt False als Default an
* Ältere Delphi Versionen erstellen sie beim Abspeichern wieder, wenn sie nicht existiert, mit OldCreateOrder=True. (Neue Formulare erstellen diese älteren Versionen mit OldCreateOrder=False.)

Das kann fatale Konsequenzen haben, denn mit OldCreateOrder=True, werden FormCreate Events ausgeführt, bevor der Constructor komplett ausgeführt wurde, wie das früher mal bei Delphi 5(?) oder sogar noch früher der Fall war.

Ich meine mich dunkel zu erinnern, dass Uwe Raabe darüber gebloggt hatte.

Oh, danke, gut zu wissen

Zitat von himitsu:

...
haben wir nun also einen Hook im DFM-Reader der IDE, welcher auch das gleich behebt.

Bei z.B. Formvererbung gibt es massive Probleme,...

Einen Hook? Wo bekomme ich den dann her oder wie hänge ich den rein?

[Uwe Raabe]

Dafür ist nicht zwingend ein Hook notwendig. Erstelle eine Unit mit folgendem Inhalt:

Delphi-Quellcode:

unit FixOldCreateOrder;

interface

uses
  System.Classes, Vcl.Forms;

type
  TDataModuleFix = class(TDataModule)
  protected
    procedure Loaded; override;
  end;

type
  TFormFix = class(TForm)
  protected
    procedure Loaded; override;
  end;

type
  TForm = TFormFix;

implementation

procedure TFormFix.Loaded;
begin
  inherited;
  OldCreateOrder := False;
end;

procedure TDataModuleFix.Loaded;
begin
  inherited;
  OldCreateOrder := False;
end;

end.

Diese Unit muss dann in allen Forms und DataModules als letztes in der Interface Uses-Anweisung stehen.

Im Designer steht dann zwar immer noch OldCreateOrder als True, aber das hat ja keine direkten Auswirkungen. Beim Programmstart wird das entsprechend korrigiert.

Für etwaige Abkömmlinge von TCustomActiveForm und TCustomDockForm müsste das dann entsprechend ergänzt werden.

[himitsu]

Weiß nicht genau ... frühestens im 10.2 oder vielleicht erst 11.0.
irgendwo zwischen XE und 10.4

In DFM wird ja "inzwischen" normal ClientWidth/ClientHeight gespeichert,
aber abhängig von anderen Property wird stattdessen Width/Height gespeichert (was ich teilweise für total schwachsinnig halte).
Auch andere Property haben solche abweichungen.

Und da Emba manchmal Probleme hatte, im Create auf das ClientWidth/ClientHeight zuzugreifen (Exception), wird das in einer Variable gespeichert, welcher erst im AfterConstruction angewendet wird.
Wird aber nach ClientWidth etwas an Width zugewiesen, dann wird jenes somit vom ClientWidth wieder "falsch" überschrieben.

Lösung war einfach im Width ein FClientWidth:=0; und fertig, aber neeeeeeeeeeee.

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

Im Programm kann man sich da problemlos in seine FormKlasse oder einen Vorfahren die Setter überschreiben und es reparieren,
aber im FormDesigner kommt man nur per Hook dran. (bei uns sind deswegen zusammen mehrere Wochen an Arbeitszeit draufgegangen, für etwas, das Emba hätte mit zwei Zeilen Code lösen können)

Zitat:

Dafür ist nicht zwingend ein Hook notwendig

Das sieht bei Formvererbung anders aus, aber auch ohne schon.

Wenn du das dort, an dieser Stelle, änderst, dann wird/kann kann es passieren, dass OnCreate doppelt ausgeführt wird, im alten Delphi.
Im Constructor, da der den Wert aus DFM beachtet wird, dann schreibt Loaded es um und AfterConstruction sieht den neuen Wert und macht es nochmal.
War mir vor kurzem einmal aufgefallen, da im OnCreate eine TComponent erstellt wurde und es dann hieß "Name gibt es schon *peng*".