Du kannst doch auch direkt mit Objekten arbeiten, so dass Du nicht über ID´s suchen musst:
Delphi-Quellcode:
TMonster = class(TComponent)
ListWaffen: TList;
Bein1: TBein;
Bein2: TBein;
...
procedure DoGo; virtual;
procedure Paint; override;
procedure SaveToStream; virtual;
procedure LoadFromStream; virtual;
end;
TMonsterDreibein = class(TMonster)
Bein3: TBein;
Bein3Pos: TVornOderHinten;
...
procedure DoGo; override;
procedure Paint; override;
procedure SaveToStream; override;
procedure LoadFromStream; override;
end;
Die Monsterkomponente weiß dann, wie sie sich zu zeichnen hat und kann ihre Daten in einen Stream speichern und wieder laden (incl. der Waffen, die sich ebenfalls selbst speichern und laden können).
Abweichend kann das DreiBeinMonster zusätzlich mit dem dritten Bein umgehen.
Im Stream wird dazu zuerst der ClassName gespeichert und dann die zugehörigen Daten. Beim Laden aus dem Stream wird eine Klasse vom Typ ClassName erzeugt, die dann ihre Daten liest (incl. dem Anlegen und Füllen der Waffensammlung).
Dadurch kannst Du vermeiden Objekte über eine ID zu suchen. Schwierig werden direkte Beziehungen zwischen Monstern.
Jedes Monster hat z.B. einen Partner vom Typ TMonster.
Monster1.Partner := Monster9;
Hierbei werden ja Speicheradressen zugewiesen, die nach dem Laden aus dem Stream nicht mehr stimmen. Dazu habe ich mir eine Verfahrensweise entwickelt, mit der ich diese Beziehungen wieder herstellen kann.
Das funktioniert super, aber ich weiß nicht, wie´s die Profis beurteilen würden:
Komponenten speichern und laden
Dabei nutze ich temporäre ID´s, die nach dem Laden eines Projektes verworfen werden.
Die
IDE dürfte das ähnlich machen, wobei sie die Zuordnungen über die Komponentennamen regelt.
Zur Programmlaufzeit kann man ja auch leicht eine Palette und einen Designer bereitstellen. In der Palette bietet man verschiedene Objekte an. Zieht man eines davon auf den Designer wird ein neues Objekt der gleichen Klasse erzeugt.
Geht das in die richtige Richtung?
stahli