Sub-Komponenten serialisieren

[DGL-luke]

Hallo, ich habe folgende Konstellation:

Delphi-Quellcode:

type
  TBaseFormElementManager = class abstract(TComponent)
    protected
      FControl: TControl;    //<--- der da
      FNaturalDimensions: TDRect;

      MouseUpEvents:   TEventList;
      MouseDownEvents: TEventList;
      MouseMoveEvents: TEventList;
    public
      procedure SetElement(Value: TControl); virtual;
      function  GetElement: TControl; virtual;

      procedure SetLeftMm(Value: Double);  
      procedure SetTopMm(Value: Double);
      procedure SetWidthMm(Value: Double); 
      procedure SetHeightMm(Value: Double);

      procedure SetLeftPx(Value: Integer); //<--- hier
      procedure SetTopPx(Value: Integer);   
      procedure SetWidthPx(Value: Integer); 
      procedure SetHeightPx(Value: Integer);

das will ich speichern und vor allem laden:

Delphi-Quellcode:

procedure TFormElementSupplier.Save(FileName: string);
var i,size: Integer;
    m: TBaseFormElementManager;
    ms,msc: TMemoryStream;
begin
  ms := TMemoryStream.Create;
  msc := TMemoryStream.Create;
  try
    for i := 0 to Elements.Count -1 do
    begin
      ms.Size := 0;
      ms.WriteComponent(Elements[i]);
      ms.Position := 0;
      size := ms.Size;
      msc.Write(size,SizeOf(size));
      msc.CopyFrom(ms, size);
    end;
    msc.Position := 0;
    msc.SaveToFile(FileName);
  finally
    ms.Free;
    msc.Free;
  end;
end;

Delphi-Quellcode:

procedure TFormElementSupplier.Load(FileName: string);
var c: TComponent;
    ms,msc: TMemoryStream;
    size: Integer;
begin
  ms := TMemoryStream.Create;
  msc := TMemoryStream.Create;
  try
    ms.LoadFromFile(FileName);
    while ms.Position < ms.Size do
    begin
      ms.Read(size,SizeOf(size));
      msc.Clear;
      msc.CopyFrom(ms,size);
      msc.Position := 0;
      c := nil;
      c := msc.ReadComponent(nil); //<--- HIER
      Elements.Add(c as TBaseFormElementManager);
    end;
  finally
    ms.Free;
    msc.Free;
  end;
end;

Im ReadComponent wird aber gleich ins SetLeftPx gesprungen, was ich auch nachvollziehen kann:

Delphi-Quellcode:

procedure TBaseFormElementManager.SetLeftPx(Value: Integer);
begin
  if Assigned(FControl) then
    FControl.Left := Value
  else
    raise EElementNotCreated.Create('No Element Created yet.');
end;

Wo dann FControl auf nil ausgewertet wird und die Exception kommt.

Wie bringe ich das ganze System dazu, dass das Control ordentlich zugewiesen wird? Bzw. überhaupt mitgespeichert, ich weiß ja nicht, ob das überhaupt passiert.

Ich sollte vielleicht noch einmal erwähnen, dass TBaseFormElementManager nie instanziiert wird, sondern es sich immer um nachfahren handelt.

EDIT: hab inzwischen "Setsubcomponent" gefunden... ändert nix... :gruebel:

[DGL-luke]

Niemand einen Tipp für mich?

[Khabarakh]

Zitat:

Zitat von DGL-luke

Im ReadComponent wird aber gleich ins SetLeftPx gesprungen, was ich auch nachvollziehen kann:

Hm, ich leider nicht ;) . Im von dir geposteten Code deutet aber auch nichts darauf hin, also liegts (hoffentlich) nicht an mir :zwinker: . Wenn dahinter eine published Property steckt, wäre die nächste Frage, warum sie published ist. Denn Left wird ja schon in FControl serialisiert, einmal reicht.

[DGL-luke]

published property ist es deswegen, weil ich sie veröffentlichen will ;)

Ich will es im jedi-runtime-OI drin haben(TJvInspector, imo), allerdings nicht das komplette Control, sondern eben nur ausgewählte über diesen Umweg.

Ich werde wohl einfach noch irgendwie eine Weiche einbauen, die mir sagt, dass gerade deserialisiert wird. dann muss ich nicht die exception werfen...

[Khabarakh]

Hab ich doch glatt vergessen, dass in Delphi OI-Binding und Serialization dämlicherweise verbunden sind :duck: .
Da du also nicht die Serialisierung von Left verhindern kannst, musst du - wie du schon selbst erkannt hast - stattdessen die Property beim Deserialisieren ignorieren -> TComponentState.csReading.

[r2c2]

Das Problem ist IMHO, dass du - wo wies aussieht das Control zur Designtime erstellst und dann der property zuweist. Wenn das Objekt dann wieder deserialisiert wird, is der Pointer noch nil ==> AV.

Du müsstest also sicherstellen, dass zum Zeitpunkt des Zugriffs - am besten schon im Konstruktor - der Property n Control zugewiesen wurde. Also entweder im Konstruktor das Control zuweisen oder gleich dort erstellen...

mfg

Christian

[Khabarakh]

Zitat:

Zitat von r2c2

Das Problem ist IMHO, dass du - wo wies aussieht das Control zur Designtime erstellst und dann der property zuweist. Wenn das Objekt dann wieder deserialisiert wird, is der Pointer noch nil ==> AV.

Genau diesen Fall fängt er doch im Setter schon längst ab :gruebel: .

Zitat:

Du müsstest also sicherstellen, dass zum Zeitpunkt des Zugriffs - am besten schon im Konstruktor - der Property n Control zugewiesen wurde. Also entweder im Konstruktor das Control zuweisen oder gleich dort erstellen...

Wozu sollte man ein leeres Control erstellen, wenn es eine Zehntelsekunde danach vom Deserialisierer überschrieben wird?

[r2c2]

Zitat:

Zitat von Khabarakh

Zitat:

Zitat von r2c2

Das Problem ist IMHO, dass du - wo wies aussieht das Control zur Designtime erstellst und dann der property zuweist. Wenn das Objekt dann wieder deserialisiert wird, is der Pointer noch nil ==> AV.

Genau diesen Fall fängt er doch im Setter schon längst ab :gruebel: .

Indem er eine weitere Exception auslöst... jo...

Zitat:

Zitat:

Du müsstest also sicherstellen, dass zum Zeitpunkt des Zugriffs - am besten schon im Konstruktor - der Property n Control zugewiesen wurde. Also entweder im Konstruktor das Control zuweisen oder gleich dort erstellen...

Wozu sollte man ein leeres Control erstellen, wenn es eine Zehntelsekunde danach vom Deserialisierer überschrieben wird?

Ähm... zu viel .NET gemacht? Da wird man verwöhnt, nicht? Is jetzt nur geraten. Ich könnt mir aber vorstellen, dass das in .NET geht(Hab in .NET bisher noch nicht viel gemacht. Serialisierung steht noch auf der Liste...). In Delphi muss man sich aber um so manches noch selber kümmern...

Spaß beiseite: IMHO wird durch ReadComponent nur das serialisierte Objekt *ohne* Unterobjekte created. Für das Createn der Unterobjekte is das Objekt selbst verantwortlich. Wenn also das Control nicht im Konstruktor erstellt wird und auch sonst nirgendwo, dann produziert ReadComponent eine Exception, weil es ein bereits erstelltes Objekt erwartet, aber nicht findet...

mfg

Christian

[DGL-luke]

SetSubComponent sollte doch eigentlich genau das machen...

Wie bereits gesagt, ich werde jetzt eine globale variable "IsUnserializing" einführen, die in der initialization auf false, beim laden auf true setzen und das ganze entsprechend behandeln.

[r2c2]

Zitat:

Zitat von DGL-luke

SetSubComponent sollte doch eigentlich genau das machen...

Dann hast du entweder ne andere Hilfe, als ich oder sie nicht richtig gelesen. SetSubComponent regelt ob eine Komponente serialisiert wird. Mit dem Deserialisieren hat das nix zu tun. Dass es damit auch nicht klappt is also kein Wunder...

Zitat:

Wie bereits gesagt, ich werde jetzt eine globale variable "IsUnserializing" einführen, die in der initialization auf false, beim laden auf true setzen und das ganze entsprechend behandeln.

Probiers aus. Ich vermute, dass das auch nix hilft, da das Control immer noch nicht existiert. Außer du Createst aufgrund des Flags das Control bzw. setzt den Pointer entsprechend. Alleine das raisen deiner Exception zu verhindern wird IMHO nicht funktionieren. Kann mich aber auch irren...

mfg

Christian

[DGL-luke]

lol?
Serialisierung hat mit Deserialisierung nix zu tun? Das ist doch... bescheuert... aber leider hast du anscheinend recht.

Also muss ich die doch extra speichern :wall:

Pfff... nervig...

Ich will .Net :cry:

[r2c2]

Zitat:

Zitat von DGL-luke

lol?
Serialisierung hat mit Deserialisierung nix zu tun? Das ist doch... bescheuert... aber leider hast du anscheinend recht.

Mit SetSubComponent legst du nur fest, ob das Objekt serialisiert wird. Das wird es auch nur dann wenn der Owner entsprechend gesetzt ist. Ergo: Owner auf deine Komponente, SetSubComponent nicht anfassen oder von mir aus auch mit true ausführen. Dann serialisieren. Bei Deserialisieren zuerst sicherstellen, dass das Control erstellt wird(am besten im Konstruktor deiner Komponente) und deserialisieren. Das sollte dann auch funktionieren. Du musst eben nur gucken, dass das Control auch existiert bzw. erstellt wird...

Zitat:

Also muss ich die doch extra speichern :wall:

Das is die zweite Möglichkeit.

Zitat:

Ich will .Net :cry:

Wie gesagt: Ich bin mir nicht sicher, ob es in .NET so funktioniert. Da müsstest du Khabarakh, Elvis und Co fragen. Die kennen sich da bedeutend besser aus...

mfg

Christian

P.S.: ggf. könnte es auch Helfen zu wissen, was genau du amchen willst. Wird das Control von deiner Komponente erstellt? Übergibst du n Pointer zur Laufzeit...?

[DGL-luke]

OK... ich werd mich malö noch ein bisschen ausbreiten, da jetzt ein anderes Problem auftaucht.

.Net? Also unter .Net 2.0 mit VC# Express muss ich nur [(Serializable)] als attribut zu meiner Klasse hinzufügen und kann das ganze mit z.B. einem BinarySerializer (oder so ähnlich, wie die Klasse genau heisst, weiß ich grade nicht) serialisieren und genau so einfach wieder deserialisieren. :)

Und hier hab ich jetzt das problem, dass ich einen Owner brauche.
Und zwar läuft das ganze so ab:

- Ich erstelle das Managerobjekt (über einen Index in einer Klassenliste; ich weiß nicht mehr, als dass es von einer Basisklase abstammt)
- Ich rufe die Methode CreateElement des Managerobjektes auf, dann wird ein Control erstellt, mit dem Owner(!) auf dem Managerobjekt.

Dann serialisiere ich sowohl managerobjekt als auch Control (einzeln) und deserialisiere das auch wieder. Dabei geht der owner verloren - den ich aber unbedingt brauche. Und den ich nciht wieder zuweisen kann.

Ich bräuchte also eine Lösung, die sowohl managerobjekt als auch Control kompakt serialisiert und wieder deserialisiert.

[r2c2]

Ich hoffe ich hab dich richtig verstanden. Versuch mal das(wenn du das noch nicht gemacht hast):

Delphi-Quellcode:

//Pseudocode:

procedure Start;
var
  ManagerObj: TManager;
begin
  ManagerObj := TButtonManager.Create;  // ManagerObjekt erzeugen dabei wird automatisch ein Button erstellt
  Serialize(ManagerObj);
  ...
  ManagerObj.Free; // Manager und Button werden freigegeben
  ...
  DeSerialize(ManagerObj);
end;

constructor TButtonManager.Create;
begin
  inherited Create;
  // FButton is n privates Feld Button eine publishes Property
  FButton := TButton.Ceate(self); // owner zuweisen
end;

procedure Serialize(AManager: TManager); 
begin
  ...
  FileStream.WriteComponent(AManager); // ggf. könnte hier n TypeCast erforderlich sein, dass die RTTI weiß, dass es sich um einen TButtonManager handelt. Bin mir da aber nicht sicher(ich glaubs aber eigentlich nicht). Kenn mich dazu mit RTII noch zu wenig aus
  ...
end;

procedure DeSerialize(out AManager: TManager);
begin
  ...
  FileStream.ReadComponent(AManager);
  ...
end;

Du könntest dir auch mal die erzeugte Datei angucken. Dann merkt man zuerst mal obs Serialisieren richtig geklappt hat...

mfg

Christian

[DGL-luke]

Naja... ich hatte das so ungefähr schon mal. Es sieht so aus:

1. Ich serialisiere nur den Manager -> dann bekommt der Manager keinen Pointer auf das Control, und ich auch nicht
2. Ich serialisiere beides getrennt und weise danach alles wieder zu -> Ich kann den Owner des Controls nicht zuweisen

[r2c2]

Zitat:

Zitat von DGL-luke

1. Ich serialisiere nur den Manager -> dann bekommt der Manager keinen Pointer auf das Control, und ich auch nicht

Warum denn das? In meinem Beispiel hab ich ne Button-Property, die auf n FButton-Feld verweist. Da is doch der Pointer...

mfg

Christian

P.S.: Hhast du dir mal die serialisierte Klasse als Datei angeguckt?

[DGL-luke]

Ja, ich habs mir angesehen....

sieht eigentlich ganz gut aus... Ich werd das jetzt (mal wieder^^) umstellen, so dass nur der Manager gespeichert wird, und dann mal gründlich debuggen, vielleicht liegts ja ganz woanders.

EDIT: ah ja richtig... entsprechende property hab ich nicht... :gruebel:
EDIT: jetzt kommt "ungültiger pfad für eigenschaft" :shock: was ist das denn?
EDIT: EReadError wollte ich sagen. hmm... "formulardatei beschädigt" sagt die OH.. soso... kann ich nix von sehen...

EDIT: :shock:

Das muss der auslöser sein:

Delphi-Quellcode:

if not (PropValue is TPersistent) then PropPathError;

aber das kann ja gar nicht sein... und in die classes.pas kann ich natürlich keinen haltepunkt setzen...

[r2c2]

Zitat:

Zitat von DGL-luke

Ja, ich habs mir angesehen....

sieht eigentlich ganz gut aus... I

Was heißt "sieht ganz gut aus"? Is dein Control mitserialisiert worden? Die Datei müsste ja in etwa so aussehen, wie ne DFM-datei...

Zitat:

EDIT: ah ja richtig... entsprechende property hab ich nicht... :gruebel:

Die brauchst du natürlich zum Serialisieren...

Zitat:

EDIT: jetzt kommt "ungültiger pfad für eigenschaft" :shock: was ist das denn?

Das bekommt man IMHO, wenn das Objekt(in diesem Beispiel der Button) (noch) nicht erstellt ist. Hast du den Button(oder was auch immer) im Konstruktor erstellt?

Zitat:

EDIT: :shock:

Das muss der auslöser sein:

Delphi-Quellcode:

if not (PropValue is TPersistent) then PropPathError;

N TControl is aber ein TPersistent. Definitiv... Wie gesagt: Wenn das Control im Konstruktor nicht erstellt wurde, dann liefert is Persistent auch false, da der Pointer noch auf nil zeigt...

mfg

Christian

[DGL-luke]

öhm.... ich muss das im konstruktor erstellen?! ich dachte, der zweck vom deserialisieren ist, dass mans eben nicht erstellt.... :stupid:

hab das mal geändert... und es hat sich nix geändert^^

Aber nach DFM sieht das nicht aus :gruebel:

Code:

‘   TPF0
TFormPanel Control.Left¨ Control.Topš 
Control.Width
Control.Height
Control.TabOrder LeftPx¨ TopPxš HeightPx
WidthPx

[r2c2]

Zitat:

Zitat von DGL-luke

öhm.... ich muss das im konstruktor erstellen?! ich dachte, der zweck vom deserialisieren ist, dass mans eben nicht erstellt.... :stupid:

Ich hab schon oben mal angedeutet, dass beim Deserialisieren nur folgendes passiert:
- Der entsprechende Konstruktor wird aufgerufen
- die published Properties werden einzeln aus der Datei geparst und per RTTI dem gerade erstellten Objekt zugewiesen.

Was aber passiert, wenn das Unterobjekt(dein Control) nicht im Konstruktor erstellt wird? Richtig es gibt ne exception, weil kein weiterer Konstruktor mehr aufgerufen wird. Warum is das aber so? Angenommen es würde wirklich der Konstruktor des Unterobjekts aufgerufen werden. Dann wird dieses neu erstellt. Angenommen du hast sowas im Konstruktor deiner manager-Klasse:

Delphi-Quellcode:

constructor TButtonManager.Create;
begin
  inherited Create;
  FButton := TButton.Create;
  AndererPointer := FButton;
  ...
end;

Und dann such mal den Fehler, wenn du dich wunderst, dass es beim Zugriff auf AndererPointer ne AV gibt...

Zitat:

Aber nach DFM sieht das nicht aus :gruebel:

Code:

‘   TPF0
TFormPanel Control.Left¨ Control.Topš 
Control.Width
Control.Height
Control.TabOrder LeftPx¨ TopPxš HeightPx
WidthPx

Sieht für mich nach ner Binär-DFM aus. Da gibts 2 Möglichkeiten: a) au öffnest die Datei mit nem Editor der das lesen kann(z.B. Delphi) oder b) du serialisierst in Text-DFMs: ObjectBinaryToText. Wenn du n funktionierendes Beispiel brauchst: TOptions

mfg

Christian

[DGL-luke]

soo... hab jetzt das text-dfm:

Code:

object TPanel
  Left = 16
  Top = 68
  Width = 207
  Height = 186
  TabOrder = 0
end

das ist das, was geschrieben werden sollte. ich paste jetzt einfach noch mal meinen code:

Delphi-Quellcode:

procedure TFormElementSupplier.Load(FileName: string; Parent: TWinControl; Add: Boolean);
var Manager: TBaseFormElementManager;
    ManagerClass: TBaseFormElementManagerClass;
    ms,msc: TMemoryStream;
    size: Integer;
    Index: Integer;
begin
  IsUnSerializing := True;
  if not Add then
    Elements.Clear;

  ms := TMemoryStream.Create;
  msc := TMemoryStream.Create;
  try
    ms.LoadFromFile(FileName);
    ms.Position := 0;
    while ms.Position < ms.Size do
    begin
      //read class and size of element
      ms.Read(ManagerClass,sizeof(ManagerClass));
      ms.Read(size,SizeOf(size));

      //copy element into temporary stream to isolate it
      msc.Clear;
      msc.CopyFrom(ms,size);

      //create manager
      Manager := ManagerClass.Create;
      //create element
      Manager.FControl := ManagerClass.ElementClass.Create(Manager);
      //unserialize element
      msc.ReadComponent(Manager.FControl); //<--- knallt hier... "Stream-Lesefehler"
      Manager.InitElement(Parent);
    end;
  finally
    ms.Free;
    msc.Free;
  end;
  IsUnSerializing := False;
end;

procedure TFormElementSupplier.Save(FileName: string);
var i,size: Integer;
    ms,msc,textstream: TMemoryStream;
    ManagerClass: TClass;
    s: string;
begin
  ms := TMemoryStream.Create;
  msc := TMemoryStream.Create;
  textstream := TMemoryStream.Create;
  try
    for i := 0 to Elements.Count -1 do
    begin
      //write the control
      msc.Clear;
      msc.WriteComponent(Elements[i].FControl);
      msc.Position := 0;

      size := msc.Size;
      ObjectBinaryToText(msc,textstream);
      msc.Position := 0;

      //write the manager's class
      ManagerClass := Elements[i].ClassType;
      ms.Write(ManagerClass, SizeOf(ManagerClass));

      //write the size of the control
      ms.Write(size,SizeOf(size));
      //write the control
      ms.CopyFrom(msc, msc.Size);
    end;
    ms.Position := 0;
    ms.SaveToFile(FileName);
    textstream.SaveToFile(Filename + 'txt');
  finally
    ms.Free;
    msc.Free;
    textstream.Free;
  end;
end;

Nicht, weil ich zu faul bin zum debuggen, sondern weil ich einfach schon alles versucht habe. "knallt hier" ist markiert in der load-procedure... :cry:

[r2c2]

Nur ne Vermutung: Vor dem ReadComponent fehlt evtl. n Position := 0;

BTW:

Delphi-Quellcode:

Manager.FControl

Du greifst doch nicht etwa von außen auf ein Feld zu oder? :?

mfg

Christian

[oki]

Hi jungs,

als ich das hier gelesen habe hab ich mich daran erinnert, dass ich ähnliches auch mal am Wickel hatte. das aber unter D5.

Bei mir war es so, dass beim Lesen der Serialisierung die Instanz der Komponente existieren mußte. Also bei nil ging es sowiso in die Hose. es reichte aus einfach erst mal ein Create auszuführen.

Ich geb euch hier mal meinen code für das Schreiben und Lesen der Serialisierung. Ich hoffe es hilft. Bei mir war es dann eigentlich kein Problem mehr.

Schreiben:

Delphi-Quellcode:

procedure TSercheThread.WriteListToFile;
var Stream : TFileStream;
begin
  IF not Assigned(FMahnListView) then Exit;
  Stream := TFileStream.Create(MahnFileName, fmCreate or fmShareDenyNone);
  try
    Stream.WriteComponent(FMahnListView);
  finally
    Stream.Free;
  end;
end;

Lesen:

Delphi-Quellcode:

procedure TSercheThread.ReadListFromFile;
var Stream : TFileStream;
begin
  IF not Assigned(FMahnListView) then Exit;

  IF not FileExists(ExtractFilePath(Application.ExeName) + MahnFileName) then
    Stream := TFileStream.Create(MahnFileName, fmCreate or fmShareDenyNone)
  else
    Stream := TFileStream.Create(MahnFileName, fmOpenReadWrite or fmShareDenyNone);

  try
    IF Stream.Size = 0 then Exit;
    FMahnListView := TListView(Stream.ReadComponent(FMahnListView));
  finally
    Stream.Free;
  end;
end;

Das war dann auch wirklich ein TListView. Ob das alles so mit TControl funzt wage ich zu bezweifeln. Ich hoffe ich konnte euch einen Hinweis geben der hilft (bin grad knapp in der Zeit und habe diesen Thread nur diagonal gelesen).

gruß oki

[DGL-luke]

Hmmm...

Zitat:

Nur ne Vermutung: Vor dem ReadComponent fehlt evtl. n Position := 0;

:wall: :wall: :wall: :wall: :wall: :wall: :wall: :wall: :wall: :wall:

Zitat:

Du greifst doch nicht etwa von außen auf ein Feld zu oder? :?

Tu ich. Sollte aber funktionieren, ich initialisiere alles was nötig ist.

[r2c2]

Zitat:

Zitat von DGL-luke

Tu ich. Sollte aber funktionieren, ich initialisiere alles was nötig ist.

Für sowas gibts eigentlich properties... Warum man properties nehmen sollte und keine public fields? Wart ma ich hab da vor einiger Zeit n lustigen Text dazu gelesen... *sucht* Ah da haben wirs: http://tut.php-q.net/klassen.html Interessant is hier das Kapitel "6. Vererbung in PHP und typische Fallen". Der Rest dürfte Kalter Kaffee sein... Is zwar für PHP und da gibts leider keine properties(komischerweise nennen die da Felder Eigenschaften, aber was solls). Anhand der Evolution der Meerschweinchen sieht man da ganz gut, warum öffentliche Felder böse sind... *g*

mfg

Christian

[DGL-luke]

Properties? Ja, da muss ich nur das "F" aus dem aufrufenden Source entfernen :mrgreen:

[r2c2]

Zitat:

Zitat von DGL-luke

Properties? Ja, da muss ich nur das "F" aus dem aufrufenden Source entfernen :mrgreen:

:roll:

mfg

Christian