DFM speichert kein Objekt im Objekt als published property

[H4ndy]

Hallo,

Mal wieder ein kleines Problemchen.

Ich hab eine visuelle Komponente erstellt, welche wiederum ein spezielles Objekt als eigene published property hat, so dass man dieses Objekt im Objektinspektor aufklappen und dort eben die Eigenschaft direkt ändern kann. Jedoch werden diese Änderungen nicht in der DFM gespeichert (und somit nach dem erneuten Öffnen und im Programm verschwunden sind).

Muss ich da noch irgendetwas angeben, so dass Delphi die Eigenschaften des Objektes in der DFM mit ablegt?
Im Moment wird das Objekt im private vorgehalten und im Constructor/Destructor jeweils angelegt und weggeworfen.
In der DFM steht dann nur "MeinUnterObjektProperty = MutterObjekt.FPrivatesUnterObjekt", was ja prinzipiell richtig ist, aber nicht das ist, was ich will.

Platform ist Delphi 7 unter Windows XP.

Hier vereinfacht (darf leider keinen Original-Quelltext liefern):

Delphi-Quellcode:

  TMeineKomponente = class(TVorfahre)
  private
    { Private-Deklarationen }
    FUnterobjekt: TWasAnderes;

  protected
    procedure SetUnterobjekt(Value: TWasAnderes);
    function GetUnterobjekt: TWasAnderes;
  public
    { Public-Deklarationen }
    constructor Create(AOwner: TComponent); override;
    destructor Destroy; override;

  published
    { Published-Deklarationen }
    property Unterobjekt: TWasAnderes read GetUnterobjekt write SetUnterobjekt;
  end;

[himitsu]

Die Objekt-(De)Serialisierung speichert/lädt keine Objekte in Porperties!
Abgesehn von ein paar ausnahmen TCollection und dessen Items, TStrings und k.A. was sonst noch.

Aber eigentlich dachte ich, es werden zumindestens die Objekteigenschaften gespeichert.
Und es gäbe "nur" beim Laden Probleme, da derartige Objekte nicht von der VCL erstellt werden, sondern höchsten, wenn das Objekt vorhanden ist, die Eingenschaften geladen werden.

[edit]
ich glaub es ist eher so:
- es werden alle Eigenschaften und die Eigenschaften von Objekten in Published Properties gespeichert, sowie die Eigenschaften von Objekten in den Items von TCollection

- bei Laden werden aber nur Eigenschaften in schon existierende Objekte geladen, sowie Objekte in den Item von TCollection (und eventuell noch ähnlichen Container-Klassen) erstellt ... sonst Keine.

[H4ndy]

Hmm Schade, da muss ich das mit den Eigenschaften Speichern irgendwie anders lösen, aber erstmal Danke für die Hinweise. Findet sich leider kaum was zu dem Thema...

[Assertor]

Hi,

@Himi - das geht doch viel einfacher (1 Zeile!)

normalerweise geht das durch einen Aufruf von SetSubComponent(True); im Konstruktor der Unterkomponente.

Ich kann bestätigen, das das mit Delphi 2006-2010 ohne Probleme funktioniert. Im Objekt Inspektor wird dann der Property-Baum für die Subkomponente dann grün dargestellt. Alles, was geändert wird, wird zusammen mit der Hauptkomponente dann in der DFM gespeichert.

Abeeer: Für D6 gab es einen QC Eintrag zu SetSubComponent. Laut QC ist das in D7 gefixt, mußt aber selber mal testen ob es keine Probleme gibt: http://qc.embarcadero.com/wc/qcmain.aspx?d=1732

Edit: Das Unterobjekt muß natürlich weiterhin im Kontruktor der Hauptkomponente erstellt und im Destruktor freigegeben werden. Es geht hier nur um das automatisch speichern und laden der Einstellungen. Ersatzbar zur Laufzeit ist die Unterkomponente natürlich auch, vorherige freigeben und neue zuweisen (meinetwegen auch über die published Property oder besser über einen entsprechenden getter/setter wie oben erwähnt).

Gruß Assertor

[H4ndy]

Wow, das funktioniert perfekt!
Ich bedanke mich

[Assertor]

Hi,

Zitat von H4ndy:

Wow, das funktioniert perfekt!
Ich bedanke mich

Bitte, gerne!



Gruß Assertor

[himitsu]

Hab mich auch mal wieder an meinen Serialisierer gesetzt (dabei dachte ich, der wäre soweit erstmal fertig )

Also es gibt dann wohl *3* 4 verschiedene Fälle, wie man Objekte in den published Properties behandeln müßte

1: es wird nur der Name gespeichtert und beim Laden wird ein vorhandenes Objekt gesucht (wie bei Form.ActiveControl)
2: es werden die Werte des darin enthaltenen Objektes gespeichtert/geladen
3: es wird, zusätzlich zu 2, auch noch das Objekt erstellt, wenn es beim Laden noch nicht existiert
4: es darf nichts gespeichert werden

Aber wie kann man das denn nun ordentlich unterscheiden, was zu machen wäre?

csSubComponent = 3 oder 2 ?
csTransient = 4

[Assertor]

Hi himitsu,

Zitat von himitsu:

Also es gibt dann wohl *3* 4 verschiedene Fälle, wie man Objekte in den published Properties behandeln müßte

1: es wird nur der Name gespeichtert und beim Laden wird ein vorhandenes Objekt gesucht (wie bei Form.ActiveControl)
2: es werden die Werte des darin enthaltenen Objektes gespeichtert/geladen
3: es wird, zusätzlich zu 2, auch noch das Objekt erstellt, wenn es beim Laden noch nicht existiert
4: es darf nichts gespeichert werden

Aber wie kann man das denn nun ordentlich unterscheiden, was zu machen wäre?

csSubComponent = 3 oder 2 ?
csTransient = 4

1. dürfte Probleme machen, wenn die Subkomponente keinen Namen hat - und das ist ja durchaus möglich wenn diese im Konstruktor der Hauptkompo erzeugt wird.

Ich würde jetzt sagen csSubComponent in der Regel 2 und csTransient immer 4 (entspricht ja auch der OH). Für 3. dürfte es eigentlich keine Verwendung geben, da wenn das Subproperty nicht erstellt ist der Komponentenentwickler dafür sorgen muß, daß es auf nil zeigt. Sonst würde es in der IDE im OI eh krachen.

Überlicherweise sind die OI Eigenschaften von Subkomponenten ja eigene Instanzen der Hauptkomponente die im Konstruktor und Desktruktor erstellt und freigeben werden. Wenn der Entwickler die Subkomponente ersetzt, erfolgt das ja überlicherweise zur Laufzeit (Assign o.ä.), also per Code. Mir ist auch kein Weg bekannt, das im OI anders zu handeln.

Also nehm' ich 2 und 4.

Gruß Assertor

[himitsu]

Die 3 würde doch .Components der Form entsprechen, wo doch auch der DFM-Deserialisierer die Komponenten erstellt.
Und theoretisch könnte sowas auch bei einem Einzelproperty möglich sein.

[Assertor]

Hallo himitsu,

hab in der Mailflut die Antwortbenachrichtigung total übersehen...

Zitat von himitsu:

Die 3 würde doch .Components der Form entsprechen, wo doch auch der DFM-Deserialisierer die Komponenten erstellt.
Und theoretisch könnte sowas auch bei einem Einzelproperty möglich sein.

Das stimmt zwar theoretisch, aber in der Praxis ist mir der Fall bei anderen Komponenten noch nicht (bewußt) untergekommen. Ich denke auch, das würde die IDE nicht zulassen.

Üblicherweise wäre auch dann die Relation ja Form zu Subkomponente im Erstellungsprozess und in der Verknüpfung der Abhängigkeit Hauptkomponente zu Subkomponente.

Gruß Assertor