Erkennen, wann alle Propertys geladen sind

[Uwe Raabe]

Zitat:

Zitat von gemeni2005 (Beitrag 1499165)

Das Problem ist, dass bei diesem Getter der Fixup-Mechanismus den Default-Wert zurückbekommt und das im DFM vorhandene Property aus dem Datenmoodul nicht mehr zuweist, obwohl der Wert sauber in der DFM-Datei vorhanden ist.

Schuld ist hier diese Codezeile in GlobalFixupReferences:

Delphi-Quellcode:

               
 if (Root <> nil) or (GetOrdProp(aPropFixup.FInstance, aPropFixup.FPropInfo) <> 0) then

Diese wird am Ende von ReadRootComponent, also beim Laden des Forms, aufgerufen. Existiert das Datenmodul dann noch nicht, ist zwar Root = nil, aber GetOrdProp liefert FDefaultChild zurück und das Fixup wird entfernt.

Wenn du damit leben kannst, dass zur Designtime in der IDE das Property mit nil anstatt FDefaultChild im Objektinspektor steht, dann kannst du das mit folgendem Code erreichen:

Delphi-Quellcode:

function TParentComponent.GetChild: TChildComponent;
begin
  if Assigned(FChild) or (csDesigning in ComponentState) then
    Result := FChild
  else
    Result := FDefaultChild;
end;

[himitsu]

Jupp, den ComponentState im Setter auf csLoading oder csReading prüfen,
in diesem Fall die Aktion nicht ausführen (nur den Wert speichern)

und die gewünschte Aktion dann später im Loaded nachholen.



Aber wie schon gesagt, hier muß dann das Datenmodul entweder vor dem Laden vorhanden sein, oder es müsste während des Ladens erstellt werden.

Wir haben hier auch ein paar nette Effekte mit einem Datenmodul, was einmal über ein Designtime-Package als instanz in der IDE vorhanden ist. (die VCL/IDE speichert eine globale Liste mit allen Forms und Datenmodulen und kann darüber das Gegenüber finden)
Spaßig wird es, wenn man dann zusätzlich noch die Unit mit diesem Datenmodul öffnet, also dann das Modul doppelt vorhanden ist.
Allersdings kann man sich auch über RegisterFindGlobalComponentProc registrieren und die Übersetzung Name-zu-Instanz selber vorgeben.

Delphi-Quellcode:

class function TIDEHelperModul.FindGlobalModules(const Name: string): TComponent;
begin
  Result := nil;
  if SameText(Name, 'DM1')   then Result := UDM1.DM1;
  if SameText(Name, 'SysDB') then Result := UDataModul_SysDB.SysDB;
  if SameText(Name, 'DMSys') then Result := USysModule.DMSys;
  //
  // nicht beim Laden / nur vollständig :
  //   TReader.ReadRootComponent>FindUniqueName findet sich sonst selber und ändert den Namen -> "DM1" zu "DM1_1" -> Referenzen werden dann nicht mehr gefunden oder falsch gespeichert
  //   Grund: siehe TDM1.Create -> globale Instanz vorher setzen, für deren Benutzung während des Ladens der enthaltenen pgQueries
  if Assigned(Result) and ((csReading in Result.ComponentState) or (csDestroying in Result.ComponentState)) then
    Result := nil;
end;

[edit]
OK, dann csDesigning ... ist für die Instanz, welche gerade in der Delphi-IDE bearbeitet wird.
Kann also im Getter oder Setter benutzt werden, für das was man z.B. im Objektinspektor eingibt oder angezeigt bekommt.

[Uwe Raabe]

Zitat:

Zitat von himitsu (Beitrag 1499213)

Aber wie schon gesagt, hier muß dann das Datenmodul entweder vor dem Laden vorhanden sein, oder es müsste während des Ladens erstellt werden.

Problem ist halt, dass man das zur Designzeit nur schwer unter Kontrolle kriegt.

[himitsu]

Wie gesagt, wir haben unsere globalen Datenmodule via DesigntimePackage (kompiliert) in der IDE und lassen die Forms/Komponenten mit den Property darauf gehen. (ich hatte dann nur noch das FindGlobalComponent angepasst, damit es die richtigen findet und sich nicht an die geöffneten Datenmodule hängt, weil man diese Units sonst nicht mehr schließen kann)
So ist z.B. auch unser Datenmodul mit der DB-Connection vorhanden die Queries/Grids können Daten zur Designtime anzeigen, sowie andere zentralen Laufzeitfunktionen.

Ansonsten müsste man immer dafür sorgen, dass die Unit mit dem Datenmodul vorher geöffnet ist.
Bei uns findet Delphi solche Units auch schwer ... die sind in einem anderen Projekt (BPL).
Frühe hatten wie diese Units dann in jedem Projekt mit aufgenommen, aber das brachte z.B. Probleme, wenn Delphi kompilieren wollte, weil es nicht mehr wusste zu welchem Projekt diese Units gehören.

[gemeni2005]

Hallo,

vielen Dank für eure Hilfe. Die Stelle, die Uwe zitiert, hatte ich auch als Ursache ausgemacht. Nach meinem Verständnis der Doku wäre genau dafür csFixups da, das aber in den VCL-Sourcen offensichtlich nirgends gesetzt, komischerweise aber entfernt wird.

Da das Property Style-Informationen beinhaltet, brauche ich es auch zur Laufzeit zwingend. Dann werde ich mir etwas anderes einfallen lassen müssen.

Viele Grüße

Robert

[Uwe Raabe]

Zitat:

Zitat von gemeni2005 (Beitrag 1499223)

Nach meinem Verständnis der Doku wäre genau dafür csFixups da, das aber in den VCL-Sourcen offensichtlich nirgends gesetzt, komischerweise aber entfernt wird.

Keine Ahnung ob das jemals anders war. Zumindest seit Delphi 5 ist das jedenfalls so. Das Flag hat offenbar keine Wirkung.

Ich vermute aber, dass hier eine Kollision mit irgendeinem Requirement vorliegt. Die besagte Codezeile bedeutet eigentlich: Wenn ein Klassen-Property einen Wert enthält, soll kein Fixup mehr dafür gemacht werden. Da würde dann auch ein Setzen von csFixups irgendwo nichts helfen.

[himitsu]

Es hat definitiv keine Wirkung.
Aber was in der Hilfe steht, stimmt im Prinzip noch ... es wird gelöscht, wenn alles fertig gladen ist (nach GlobalFixupReferences).

Diese Fixups sind Rekursiv.
Wenn mehrere Forms/Datenmodule parallel/verschachtelt geladen werden, dann werden Fixups erst am Ende behandelt.
-> Komponenten-Property, welche nicht zugewiesen werden konnten, weil beim Laden des Property die Instanz noch unbekannt ist, dann wird Name+PropertyReferenz gespeichert und am Ende noch "einmal" versucht es zu finden.

Selbst wenn csFixups mal eine Wirkung hatte, dann wäre es dennoch keine Lösung dafür gewesen, wenn das Datenmodul nicht irgendwann während des Ladens auftaucht.