Persistenz zwischen Designtime und Runtime

[Socke]

Hallo zusammen,

ich entwickler zurzeit einige Komponenten, die in Lazarus zur Designtime verwendet werden sollen, aber erst zur Laufzeit aktiv werden. Der Benutzer soll zur Entwurfszeit in Lazarus verschiedene Einstellungen vornehmen können, diese sollen dort jedoch nur gespeichert werden. Wenn das Programm startet, sollen verschiedene Aktionen in Abhängigkeit der Einstellungen durchgeführt werden (z.B. Worker-Threads starten und mit den angegeben Daten versorgen).

Wie speichert man hier idealerweise die Daten und zu welchen Zeitpunkten werden die Daten von der Persistenz "produktiv" gesetzt? Kann man während der Laufzeit nur mit den produktiven Daten arbeiten und zum Streamen die Daten in der Persistenz aktualisieren?

[mse]

Komponenten können durch Auswerten von "tcomponent.componentstate csdesigning" den Entwurfszeitszustand erkennen.
Die Aktivierung geschieht meist in "loaded()", da dort bereits alle Komponenten des Formulares geladen sind. Manchmal ist das zu früh, da Abhängigkeiten zu weiteren Formularen bestehen. In diesem Fall muss das Erstellen der abhängigen Formulare zwischen "begingloballoading()"/"endgloballoading()" geschehen. Eine andere Möglichkeit ist das Aktivieren beim Start der main event loop. In MSEgui wird das durch das posten eines events an sich selbst durchgeführt.
Die letzte Frage verstehe ich leider nicht.

[Socke]

Komponenten können durch Auswerten von "tcomponent.componentstate csdesigning" den Entwurfszeitszustand erkennen.
Die Aktivierung geschieht meist in "loaded()", da dort bereits alle Komponenten des Formulares geladen sind. Manchmal ist das zu früh, da Abhängigkeiten zu weiteren Formularen bestehen. In diesem Fall muss das Erstellen der abhängigen Formulare zwischen "begingloballoading()"/"endgloballoading()" geschehen. Eine andere Möglichkeit ist das Aktivieren beim Start der main event loop. In MSEgui wird das durch das posten eines events an sich selbst durchgeführt.
Die letzte Frage verstehe ich leider nicht.

Vielen Dank für den Hinweis auf die Methode Loaded(); vielleicht ist es genau das, was ich suche.

Als kleinen Hinweis am Rande: Die Komponenten sollen eigenständig funktionsfähig sein und nicht auf Formulare beschränkt sein; auch wenn dies das bevorzuge Einsatzgebiet sein wird.

Um meine Frage zu verdeutlichen schreibe ich mal die Übergänge der Daten von einem Zustand in den anderen auf:

• Designzeit: Eigenschaften werden festgelegt und in die LFM-Datei des Formulars gestreamt
• Laufzeit, Loading: Streaming von der LFM-Datei in die Eigenschaften der Komponente; bisher keine weiter Aktion
• Laufzeit, alles geladen: Start der Worker-Threads wenn die Eigenschaft "Running" den Wert "True" hat
• Laufzeit: Zugriff auf aktuelle Werte der Worker-Threads bzw. auf gespeicherte Werte falls kein Worker-Thread existiert
• Laufzeit, Writing: Worker-Threads werden gestoppt, Aktuelle Werte werden gespeichert und können dann gestream werden

Gibt es eine Methode in TComponent, die aufgerufen wird, sobald alle Kinder des Owners fertig geladen wurden?

[mse]

[*]Laufzeit, Writing: Worker-Threads werden gestoppt, Aktuelle Werte werden gespeichert und können dann gestream werden[/list]

Mit streamen meinst du in *.lfm abspeichern durch writecomponent()/writerootcomponent()? Wenn das Formular mit den geänderten Daten wieder in Lazarus geöffnet werden soll gibt es vermutlich einiges zu beachten.

Gibt es eine Methode in TComponent, die aufgerufen wird, sobald alle Kinder des Owners fertig geladen wurden?

"loaded()" wird frühestens dann aufgerufen. In einem "begingoballoading()" Block wird es verzögert bis zum Aufruf von "endgloballoading()". Dies kann für inline Komponenten (z.B. TFrame) auch implizit geschehen. In der Regel wird in der überschriebenen loaded() Prozedur zuerst "inherited" aufgerufen damit das "csLoading" flag rückgesetzt wird.