Wie ein komplexes Object In eine Datei speichern?

[Kedariodakon]

Ich habe ein Object in diesem befinden sich:

Code:

 - Einige Felder...
 - Einige Objecte mit Feldern...
 - Einige Eigene Listen wovon in manchen:
    - Felder sind
    - Einige Eigene Listen sind wovon in allen:
       - einigen Felder sind
       - Objecte mit Feldern sind
    - Objecte mit Feldern sind

Ich hoffe soweit ist das erstmal klar :zwinker:

Nun will ich dieses eine Object speichern und wieder laden können, und zwar so, dass keinerlei Inhalt verlohren geht...

Die Frage ist nur Wie :gruebel:

Hat da wer ein paar Tips für mich?
Vielleicht einen Lösungsansatz?

Irgendwie find ich nichts wirklich brauchbares in der Hilfe :roll:

Bye

[alcaeus]

In der Hilfe nicht, aber in der DP: DPCollection. Die DPCollection speichert alles so ab, wie Delphi seine Forms speichert.

Greetz
alcaeus

[Kedariodakon]

Zitat:

Zitat von alcaeus

In der Hilfe nicht, aber in der DP: DPCollection. Die DPCollection speichert alles so ab, wie Delphi seine Forms speichert.

Greetz
alcaeus

Dies speichert doch nur Published Propertys mit Write Eigenschaftsdeklaration, soweit ich weiß Oder? :gruebel:
Aber keines dieser xxx Objecte hat published Propertys...
Und die meisten davon haben auch keine Write Eigenschaftsdeklaration...


Bye

[alcaeus]

Zitat:

Zitat von Kedariodakon

Dies speichert doch nur Published Propertys mit Write Eigenschaftsdeklaration, soweit ich weiß Oder? :gruebel:
Aber keines dieser xxx Objecte hat published Propertys...
Und die meisten davon haben auch keine Write Eigenschaftsdeklaration...

Dann hast du eben keine gescheite Klasse erstellt ;)
Eine "normale" Klasse arbeitet immer mit published properties, und nicht mit irgendwelchen public/private Dingen. Glaub mir, der Aufwand die Klasse anzupassen ist geringer, als ein verlässliches Speicherverfahren zu entwickeln. Ich habs selbst bemerkt :zwinker:

Greetz
alcaeus

[Jens Schumann]

Hallo,
wenn die Eigenschaft unbedingt public bleiben sollen, dann hilft hier auch DefineProperties weiter.

[Kedariodakon]

öhm für was brauch ich published Propertys wenn ich mit den Komponenten nicht VCL arbeite ???

Alle Klassen von der einen Klasse dort abzuleiten, damit sie gespeichert werden + alles auf Published Propertys umzustellen ist ein Ding der Unmöglichkeit...

Also muß eine andere Alternative her...

Für weitere Tips bin ich offen...

Bye

[Jens Schumann]

Zitat:

Zitat von Kedariodakon

...Und die meisten davon haben auch keine Write Eigenschaftsdeklaration...
Bye

Eigenschaften, die nur gelesen werden brauchen doch nicht gespeichert werden :gruebel:
Der Wert einer solchen Eigenschaft ergibt ich doch aus dem inneren Zustand des Objektes. Das Speichern einer solchen Eigenschaft wäre dann redundant.

[Jens Schumann]

Zitat:

Zitat von Kedariodakon

öhm für was brauch ich published Propertys wenn ich mit den Komponenten nicht VCL arbeite ???

Das bedeutet, dass der Basistype Deiner Klassenhierarchie nicht TObject ist.
Dann musst Du Dir in der Tat etwas anderes einfallen lassen.

[Jens Schumann]

Zitat:

Zitat von Kedariodakon

Alle Klassen von der einen Klasse dort abzuleiten, damit sie gespeichert werden + alles auf Published Propertys umzustellen ist ein Ding der Unmöglichkeit...

Das ist auch gar nicht nötigt. Du bastelst Dir ein KontainerObjekt. Dieses KontainerObjekt ist ein Nachfahre von TCollectionItem. D.h. Du schiebst in die Collection nur ein Element (das Kontainerobjekt). Das Kontainerobjekt hat jetzt als published properties die Klassen, die Du speichern möchtest. Dafür müssen Deine Klassen min. von TPersistent abstammen.

[Kedariodakon]

Zitat:

Zitat von Jens Schumann

Eigenschaften, die nur gelesen werden brauchen doch nicht gespeichert werden :gruebel:
Der Wert einer solchen Eigenschaft ergibt ich doch aus dem inneren Zustand des Objektes. Das Speichern einer solchen Eigenschaft wäre dann redundant.

Öhm die Felder werden durch eine Funktion direkt belegt und sind danach nur noch lesbar als Propertys...

Zitat:

Zitat von Jens Schumann

Das bedeutet, dass der Basistype Deiner Klassenhierarchie nicht TObject ist.
Dann musst Du Dir in der Tat etwas anderes einfallen lassen.

:gruebel: Alle Klassen sind von TObject abgeleitet... Jedenfalls kenn ich das nur so :roll:


Bye