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

[maximov]

Hats du wenigstens eine gemeinsame basisklasse?

[Jens Schumann]

Zitat:

Zitat von Kedariodakon

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

Dann werden die Eigenschaften indirekt geschrieben. Dann kann die Eigenschaft auch gleich einen Getter und Setter verpassen.

Zitat:

Zitat von Kedariodakon

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

Das hast geschrieben, dass Du nonVCL arbeitest. Die VCL fängt aber bei TObject an.

[Kedariodakon]

Zitat:

Zitat von Jens Schumann

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.

Der Ärger fängt schon da an, wo meine Listen von TObjectList abgeleitet sind, die hat kein TPersistent als Vorgänger :roll:
Also müssen alle Listen neu geschrieben werden, fast alle Objecte und und und...

Und nu?

Scheinbar muß ich wohl doch eigene komplexe Funktionen zum Speichern schreiben :roll:

Zitat:

Zitat von Jens Schumann

Das hast geschrieben, dass Du nonVCL arbeitest. Die VCL fängt aber bei TObject an.

OK My Fault...

Hatte das ein bischen anders gemeint...
Meinte eigendlich Komponenten...


Bye

[Jens Schumann]

Zitat:

Zitat von Kedariodakon

Der Ärger fängt schon da an, wo meine Listen von TObjectList abgeleitet sind, die hat kein TPersistent als Vorgänger :roll:
Also müssen alle Listen neu geschrieben werden, fast alle Objecte und und und...

Etwas besseres als die Listen neu zu schreiben fällt mir nicht ein. Anstatt TObjectList nimmst Du dann TmxJsCollection und TCollectionItem.

[Kedariodakon]

hmm :|

na mal schaun ob das gut geht :drunken:

Bye

[maximov]

Zitat:

Zitat von Jens Schumann

...
Das hast geschrieben, dass Du nonVCL arbeitest. Die VCL fängt aber bei TObject an.

Das halte ich für ein gerücht! Die VCL fängt IMO bei Classes.pas an.


@Kedariodakon: Implementier in deine klassen doch ein interface, welche zum speichern benutzt werden kann. Oder du erstellt dir eine gemeinsame basisklasse.

[Kedariodakon]

Zitat:

Zitat von maximov

Das halte ich für ein gerücht! Die VCL fängt IMO bei Classes.pas an.
@Kedariodakon: Implementier in deine klassen doch ein interface, welche zum speichern benutzt werden kann. Oder du erstellt dir eine gemeinsame basisklasse.

Bis jetzt habe ich noch nie mit interfaces gearbeitet, gibt es dazu vielleicht ein gutes tutorial oder e-Book, um den Einstieg zu vereinfachen?

Bye

[sniper_w]

Alle Klassen sind von TObject abgeleiten. Alle. Alle. Egal ob mit ode ohne VCL.

Delphi-Quellcode:

type e = class
end;

e ist automatisch von TObjekt abgeleitet.

Delphi-Quellcode:

type e=object
end;

e ist NICHT von TObject abgeleitet.

[Kedariodakon]

Zitat:

Zitat von sniper_w

Delphi-Quellcode:

type e=object
end;

e ist NICHT von TObject abgeleitet.

Und was ist es dann?

Bye

[sniper_w]

Es ist von nichts abgeleitet und OBJECT ist eine Abwärtskompatibilitet mit TurboPascal...Gute allte Zeiten... :love:

[Robert_G]

Zitat:

Zitat von sniper_w

Es ist von nichts abgeleitet und OBJECT ist eine Abwärtskompatibilitet mit TurboPascal...Gute allte Zeiten... :love:

In einem anderen Thread hörte ich, dass es von record ableitet.

[Kedariodakon]

Zitat:

Zitat von sniper_w

Es ist von nichts abgeleitet und OBJECT ist eine Abwärtskompatibilitet mit TurboPascal...Gute allte Zeiten... :love:

Lass mich raten in dem Fall bringt mir das gar nix :wink:

Bye

[Eisenherz]

Eine Alternative zu DPCollection findest du hier.
Hier bist du nicht gezwungen von einer bestimmten Klasse abzuleiten. Deine zu speichernden Daten müssen nicht als published Properties vorliegen und sie können auch Readonly sein.
Dafür musst du aber mehr Code eintippen als mit DPCollection.
Die Tippfaulen können aber auch published-Properties nutzen. Das wird aber im Tutorial nicht gezeigt. Dafür gibt es "nur" ein eigenes Beispielprogramm.

[sniper_w]

Ich weiss nicht ob dir das weiter hilft: :angel2:

Delphi-Quellcode:

uses
  TypInfo;

procedure ListComponentProperties(Component: TComponent; Strings: TStrings);
var
  Count, Size, I: Integer;
  List: PPropList;
  PropInfo: PPropInfo;
  PropOrEvent, PropValue: string;
begin
  Count := GetPropList(Component.ClassInfo, tkAny, nil);
  Size  := Count * SizeOf(Pointer);
  GetMem(List, Size);
  try
    Count := GetPropList(Component.ClassInfo, tkAny, List);
    for I := 0 to Count - 1 do
    begin
      PropInfo := List^[I];
      if PropInfo^.PropType^.Kind in tkMethods then
        PropOrEvent := 'Event'
      else
        PropOrEvent := 'Property';
      PropValue := VarToStr(GetPropValue(Component, PropInfo^.Name));
      Strings.Add(Format('[%s] %s: %s = %s', [PropOrEvent, PropInfo^.Name,
        PropInfo^.PropType^.Name, PropValue]));
    end;
  finally
    FreeMem(List);
  end;
end;

procedure TForm1.Button1Click(Sender: TObject);
begin
  ListBox1.Clear;
  ListComponentProperties(ListBox1, ListBox1.Items);
end;

[maximov]

@Sniper_w: hilft nicht so richtig, da er von TObject ableitet. Gut er könnte {$M+} nutzen.

Also entweder er wählt eins der angebotenen Persistierungs-framework oder er muss sich selbst ein schreiben, was durchaus eine erfahrung sein kann. Ein paar versuche hat jeder ;)

[Kedariodakon]

Zitat:

Zitat von maximov

@Sniper_w: hilft nicht so richtig, da er von TObject ableitet. Gut er könnte {$M+} nutzen.

Also entweder er wählt eins der angebotenen Persistierungs-framework oder er muss sich selbst ein schreiben, was durchaus eine erfahrung sein kann. Ein paar versuche hat jeder ;)

öhm :oops:

Ich glaub das übersteigt meine aktuellen Kenntnisse bei weitem...

Bye

[sniper_w]

Zitat:

@Sniper_w: hilft nicht so richtig, da er von TObject ableitet. Gut er könnte {$M+} nutzen.

Mein Beispiel ist aber für TObject Familie abgestimmt. :shock:

[maximov]

Zitat:

Zitat von sniper_w

Zitat:

@Sniper_w: hilft nicht so richtig, da er von TObject ableitet. Gut er könnte {$M+} nutzen.

Mein Beispiel ist aber für TObject Familie abgestimmt. :shock:

Offensichtlich nicht ganz:

Zitat:

Zitat von sniper_w

...
procedure ListComponentProperties(Component: TComponent; Strings: TStrings);

TPersistence würde an diese stelle am meisten sinn ergeben. TComponent ist eigentlich übertrieben und TObject hat nicht die nötigen TypeInfos.


@Kaderioko: Zeig doch mal ein paar klassenköpfe, damit wir wissen wie die substanze aussieht.