Erkennen, wann alle Propertys geladen sind

[gemeni2005]

Hallo,

ich habe eine Komponente, die als published Property auf einen TComponent-Nachfahren verweist, der im Datenmodul liegt.

Das Property wird korrekt beim Fixup geladen. Nun muss ich aber an einer bestimmten Stelle erkennen, ob der Fixup bereits abgeschlossen ist. Da das Property optional ist, kann ich nicht einfach auf nil abfragen.

Gemäß Dokumentation wird in ComponentState dafür das Flag csFixups gesetzt, wenn Propertys auf fremde Forms verweisen, die noch nicht geladen sind. Das scheint aber nicht der Fall zu sein. Auch konnte ich im VCL-Sourcecode nur eine Stelle finden, in der das Flag überhaupt angesprochen wird: System.Classes GlobalFixupReferences - dort wird es wieder entfernt.

Weiß jemand, ob das Flag überhaupt gesetzt wird und wenn ja, wo? Oder kann ich anders erkennen, das das Fixup erledigt ist nun nun auch die Propertys aus anderen Modulen gesetzt sein müssten?

Danke für eure Rückmeldungen.

Robert

[peterbelow]

Zitat:

Zitat von gemeni2005 (Beitrag 1499150)

Hallo,

ich habe eine Komponente, die als published Property auf einen TComponent-Nachfahren verweist, der im Datenmodul liegt.

Ich hoffe, das datamodule wird vor dem Form erzeugt?

Zitat:

Das Property wird korrekt beim Fixup geladen. Nun muss ich aber an einer bestimmten Stelle erkennen, ob der Fixup bereits abgeschlossen ist. Da das Property optional ist, kann ich nicht einfach auf nil abfragen.

Wo ist diese "bestimmte Stelle"? Wenn Du die Methode Loaded überschreibst sollte dort das Fixup erledigt sein, jedenfalls wenn das DM schon existiert.

[himitsu]

Wenn es auf was anderes verweißt, was noch nicht geladen ist, dann funktioniert es nur, wenn das Andere vor dem Ende des Ladens erstellt/geladen wird, also späteres wenn im Fixup nochmal danach gesucht wird.

Das DatenModul bzw. eine andere Form muß also schon vorher vorhanden sein. (außer man erstellt es irgendwie mitten beim Laden, z.B. über ein KomponentenCreate oder PropertySetter)

[gemeni2005]

Hallo,

danke für eure Antworten.

Das Datenmodul wird vor der Form erzeugt und das Property auch korrekt versorgt, wenn denn eines hinterlegt ist.

Im Getter möchte ich einen Default-Wert zurückgeben, falls das Property nicht durch den User explizit gesetzt wurde:

Code:

function TRkToolBar.GetVisualStyle: TRkVisualStyle;
begin
  if Assigned(FVisualStyle) then
    Result := FVisualStyle
  else
    Result := FDefaultVisualStyle;
end;

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.

Nun dachte ich, ich kann es über csFixups lösen, so dass der Fixup nil zurückbekommt und dann die Zuweisung vornimmt:

Code:

function TRkToolBar.GetVisualStyle: TRkVisualStyle;
begin
  if Assigned(FVisualStyle) then
    Result := FVisualStyle
  else
    Result := FDefaultVisualStyle;
  if (csFixups in ComponentState) then
    Result := nil;
end;

Aber offensichtlich wird entgegen der Dokumentation das Flag nie versorgt (komischerweise in GlobalFixupReferences entfernt: Exclude(TComponent(Instance).FComponentState, csFixups);)

Wenn ich keinen Getter verwende, funktioniert die Zuweisung, allerdings kann ich dann zur Laufzeit keinen Standard zurückgeben.

Robert

[Uwe Raabe]

Mach mal einen Breakpoint im Getter und schau dir den ComponentState im Debugger an. Ich vermute auch, dass du mit einer Überprüfung auf csLoading weiter kommst.

[gemeni2005]

Hallo Uwe,

danke für deine Rückmeldung. Das habe ich schon gemacht. Leider wird csLoading bereits in Loaded der Komponente gelöscht, der gesamte Global-Fixup-Mechanismus läuft aber hinterher.
Leider habe ich auch keine Möglichkeit gefunden, mich in den ganzen Fixup-Ablauf einzuklinken.

Robert

[Uwe Raabe]

Ich bin ja faul - kannst du ein kleines Beispielprojekt anhängen?

[gemeni2005]

Hallo Uwe,

gerne anbei. Vielen Dank für deine Bemühungen.
Beim ersten Öffnen in der IDE wird das Property gelöscht, obwohl das Datenmodul als erste Form definiert ist. Schließe ich nur die Form und öffne sie erneut, bleibt es erhalten.
Das Verhalten ist in beiden Fällen wie erwartet (Property wird zugewiesen), sobald ich keinen Getter definiere.

Viele Grüße

Robert

[Uwe Raabe]

Da fehlt Rk.Vcl.ToolBar.pas

[gemeni2005]

Guten Morgen Uwe,

sorry, wie es manchmal so ist: Die Datei war in einem Suchpfad. Nun habe ich sie eingefügt.
Viele Grüße
Robert

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