Collections speichern: Items mit Unterobjekt

[CalganX]

Hi,
ich habe schon wieder ein Problem mit dem Speichern von Collections. :?
Ich habe in meinem Collection-Item eine Eigenschaft für eine Konfiguration. Diese Eigenschaft ist eine eigene Klasse. Das sieht dann ungefähr so aus:

Delphi-Quellcode:

  TXcopyProfile = class(TCollectionItem)
  private
    {...}
    FXcopyConfig: TXCConfig;
  published
    constructor Create(Collection: TCollection); override;
    destructor Destroy; override;

    {Eigenschaften}
    {...}
    property XcopyConfig: TXCConfig read FXcopyConfig write FXcopyConfig;
  end;

TXCConfig ist eine Klasse, in der nur einige Strings, Boolean-Werte und eine Stringlist drinsteht.

Wenn ich nun meine Collection speichere möchte ich gerne auch diese Eigenschaft speichern, aber scheinbar funktioniert das nicht ohne Weiteres, da nach dem Speichern und wieder Laden aus der Datei alle Eigenschaft der Konfigurations-Eigenschaft keinen Wert mehr haben.
Ist das nicht möglich so einfach eine Klasse in ein Collection-Item zu packen?

Achja... ich verwende für das Laden und Speichern die Klasse von Jens Schumann und maximov ([cl]"dpCollection"[/cl]).

Chris

[Robert_G]

Zeige mal die Deklaration von TXCConfig her. ;)

[CalganX]

Hi,
einfacher gehts wohl kaum:

Delphi-Quellcode:

  TXCConfig = class(TObject)
  private
    FRecursive: Boolean;
    FSimulate: Boolean;
    FConfirmOverwrite: Boolean;
    FDetailed: Boolean;
    FAddParams: string;
    FSource: TStringList;
    FTarget: TStringList;
    FOnlyExistingFiles: Boolean;
  public
    constructor Create;
    destructor Destroy; override;
  published
    property ConfirmOverwrite: Boolean read FConfirmOverwrite write FConfirmOverwrite;
    property Recursive: Boolean read FRecursive write FRecursive;
    property Simulate: Boolean read FSimulate write FSimulate;
    property Detailed: Boolean read FDetailed write FDetailed;
    property AdditionalParams: string read FAddParams write FAddParams;
    property Target: TStringList read FTarget;
    property Source: TStringList read FSource;
    property OnlyExistingFiles: Boolean read FOnlyExistingFiles write FOnlyExistingFiles;
  end;

Die einzigen Methoden sind Konstruktor und Destruktor. Darin werden auch nur die Stringlisten-Objekte erstellt. ;)

Chris

Edit: Ich nehme eine Klasse nur deswegen, weil ich beim Record nicht die Möglichkeit habe die Stringlisten zu initialisieren. ;)

[Robert_G]

TStrings hat keine published properties. Deshlab gibt es da auch nix, was Delphis RTTI sehen und damit speichern kann. :?

[CalganX]

Hi Robert,
aua. :wall:
Das ist jetzt doof. :? Sehr doof.

Aber gut. Ich werde mir da was überlegen (müssen).
Danke für deine Hilfe,
Chris

[Robert_G]

Was machen Source & Target?
Wäre es vielleicht sinnvoll auch den beiden eine Klasse zu verpassen (welche rein zufällig von TCollectionItem ableitet und und in eine TCollection-Ableitung gesteckt werden kann ... :mrgreen: )

Falls ich es in den nächsten 50 Jahre fertig bekomme, dass sich meine Collection mit vertretbarem Ressourcenhunger zu XML serialisiert, werde ich mich nochmal melden.
Die kommt nämlich ohne die Unit Classes aus und zwingt dich nicht von irgendeiner Basisklasse abzuleiten. :)
Aber für solche (für mich eigentlich sinnlosen) Spielereien habe ich leider einfach nicht die Zeit. :?

Zitat:

Zitat von Chakotay1308

Edit: Ich nehme eine Klasse nur deswegen, weil ich beim Record nicht die Möglichkeit habe die Stringlisten zu initialisieren. ;)

Ich tue mal so als hätte ich das übersehen.
Records gibt's IMHO nur um kompatibel zu Uraltcode und der WinAPI zu sein. Im eigentlichen Programm haben die nix zu suchen. ;)

[Jens Schumann]

Hallo,
das Problem ist das TXCConfig nicht von TPersistent abgeleitet ist.
Nur ab TPersistent steht das Delphi-Streaming zur Verfügung !!!
Ich würde sicherheitshalber auch die Assign-Methode überschreiben.
Das macht die Sache dann rund.

Source und Target brauchen einen Setter. Darin steht dann z.B.

Delphi-Quellcode:

procedure TXCConfig.SetSource(const Value : TStringList);
begin
  FSoure.Assign(Value);
end;

P.S. Ich nehme Objekte weil ich mich bemühe objektorientiert zu programmieren.
Das passen Records nicht so richtig ins Konzept.

[Jens Schumann]

Zitat:

Zitat von Robert_G

Records gibt's IMHO nur um kompatibel zu Uraltcode und der WinAPI zu sein. Im eigentlichen Programm haben die nix zu suchen. ;)

Ganz meine Meinung

[CalganX]

Hi,
ich verwende ja schon gar keine Records mehr. ;)
Objekte und Klassen sind sowieso viel flexibler (Vererbung, Eigenschaften, Methoden etc.)

Aber du meinst nicht, dass ich TXCConfig von TPersistent ableiten soll, oder? Das funktioniert so nämlich nicht. ;)
Wenn ich das richtig sehe, brauche ich aber eigentlich keinen Getter bzw. Setter, weil die Stringlisten selber ja read-only sind.
Vielleicht könntest du einem armen, dummen, jungen Schüler wie mir genauer erklären, was du gemeint hast!? :stupid:

Chris

[Jens Schumann]

Zitat:

Zitat von Chakotay1308

Aber du meinst nicht, dass ich TXCConfig von TPersistent ableiten soll, oder? Das funktioniert so nämlich nicht. ;)
Wenn ich das richtig sehe, brauche ich aber eigentlich keinen Getter bzw. Setter, weil die Stringlisten selber ja read-only sind.
Vielleicht könntest du einem armen, dummen, jungen Schüler wie mir genauer erklären, was du gemeint hast!? :stupid:
Chris

Ich meine, dass TXConfig von TPersistent abgeleitet sein muss.
Die Stringliste selbst ist read-only. Das heißt Du kannst den Stringlisten keine neue Objektreferenz zuweisen. Was passiert wenn Du folgendes machst:

Delphi-Quellcode:

...
var
  myList : TStringList;
begin
  myList:=TStringlist.Create;
  FXYConfig.Source:=amList; // was passiert hier ?
  myList.Free;
end;
...

Mit einem Setter würde der Inhalt aus myList in FXYConfig.Source kopiert.