Verwaltung von Einstellungen

[Neutral General]

Hi,

Ich habe im Moment sowas in der Art wie

Delphi-Quellcode:

TAuto = class
  Name: String;
  Hoechstgeschwindigkeit: Word;
  Farbe: TColor;
end;

Aber halt etwas komplexer und mit Methoden und halt Properties statt Variablen.

Dann gibt es Programm A, den Autoeditor, mit dem man Autos erstellen kann.
Alle Autos sind dann in einer Datei gespeichert. Also z.B. so:

----------------
Blauer Opel-Corsa
----------------
Roter VW-Golf
----------------
...
----------------

Das Hauptprogramm liest dann bei Programmstart die Autos aus, erhält also eine Liste, aller verfügbaren Autos.
Die Frage ist nur, wie man diese Liste verwaltet, bzw wie diese aussieht.

Macht man sich da in eine Unit ne globale Variable

Delphi-Quellcode:

var
  Autos: TObjectlist;

, erstellt diese bei der Initialization und gibt sie bei Finalization wieder frei?

Es wäre zumindest eine Möglichkeit, aber ich habe irgendwie nicht das Gefühl, dass sie besonders schön ist..

Was gibts denn da für Möglichkeiten?

Gruß
Neutral General

[SirThornberry]

Ich würde es wie bei der ListView etc. machen. Eine Liste welche die Methoden Add, Delete etc. hat.
Und dann erstellst du nicht die Autos sondern die Liste und diese hat eine Methode LoadFromFile und Lädt die Autos.
Und warum im initialization und finalization Abschnitt etwas machen? Du hast doch sicher eine Klasse in der du die Liste verwendest. Warum instanzierst und zerstörst du die Liste nicht darin?

[Neutral General]

Zitat:

Zitat von SirThornberry

Ich würde es wie bei der ListView etc. machen. Eine Liste welche die Methoden Add, Delete etc. hat.
Und dann erstellst du nicht die Autos sondern die Liste und diese hat eine Methode LoadFromFile und Lädt die Autos.

entweder hast du mich da nicht verstanden oder ich verstehe dich nicht ;) so hatte ich es ja vor, falls ich dich richtig verstehe... Ich wollte quasi die Datei laden und dann eines dieser Autotyps jeweils instanzieren und in einer Liste speichern, damit ich sowas wie ein Muster für zukünftige Autos habe.

Zitat:

Zitat von SirThornberry

Und warum im initialization und finalization Abschnitt etwas machen? Du hast doch sicher eine Klasse in der du die Liste verwendest. Warum instanzierst und zerstörst du die Liste nicht darin?

Bisher habe ich noch gar nichts :mrgreen: Bin mir bisher nur ein paar Gedanken am machen.

Gruß
Neutral General

[Neutral General]

Sir? Bzw irgendjemand anderes? Würde schon gerne ein paar Meinungen/Vorschläge hören, falls möglich ;)

[Die Muhkuh]

Was spricht gegen sowas:

Delphi-Quellcode:

Auto := TAuto.Create;
Auto.LoadFromFile('bla.auto');
AutoListe.Add(Auto);

?

[stahli]

Gibt es nur die Klasse TAuto oder auch abgeleitete Klassen mit weiteren Eigenschaften?
In dem Fall musst Du den Klassennamen mit abspeichern und beim Laden eine entsprechende Klasse erzeugen.

MyComponentNew := TMyComponentClass(GetClass(ClassNameAusDatei)).Cre ate(Self);

[Neutral General]

Ah Leute bitte versteht mal was ich vorhabe :?

Ok ich erkläre es euch vielleicht mal ein bisschen genauer...
Einige von euch kennen bestimmt den RPG Maker 2000. Mein Programm könnte man in etwa mit dem RPG Maker vergleichen.
Es soll so sein das es einen Editor gibt, in dem der Benutzer Graphiken, Sounds, Handlung, Skripte, etc festlegt und erstellen kann, die dann alle in mehreren Archiven gespeichert werden (eins für Graphiken, eins für Sounds, eins für Gameplay, etc) und eine sehr abstrakte Exe, die diese Daten lädt und interpretiert.

Das heißt, ich habe z.B. eine "abstrakte" Klasse TKreatur (es wird kein RPG-Maker aber egal :P).
Dann kann der Benutzer ja alle möglichen Kreaturen im Editor erstellen. Die einen können Zaubern, die anderen nicht, die einen haben die Spezialattacken, etc.
Naja und das heißt ich muss eben diese TKreaturen in meine abstrakte Exe laden.

Bisher dachte ich eben, dass ich eine Objektliste benutze und dann beim laden der Archive von jeder Kreatur, von jedem Item, etc eine Instanz erstelle und in eine Objektliste packe. Jede Kreatur hat eben auch einen Index, der von anderen Objekten, die diese Kreatur in irgendeiner Weise "brauchen", benutzt wird um an die Werte und Daten der Kreatur zu kommen. Eine Kreatur mit dem Index 3 würde dann auch in der Objektliste an 4. Stelle stehn.

Ich finde diese Lösung jedoch etwas unschön. Deshalb frage ich hier, ob es alternative Möglichkeiten gibt :)

[freak4fun]

Wie soll denn mit den Objekten (Autos) umgegangen werden? Sollen sie ständig in gebrauch sein, also Vergleiche oder Ähnliches, oder ein Objekt ausgesucht und dann damit gearbeitet werden? Je nach Häufigkeit der Zugriffe würde ich einzelne Objekte laden, oder die kmplette Liste. Bei häufigen zugriffen spricht aus meiner Sicht nichts gegen die Objektliste.

[Edit] Du könntest die List am Anfang leer erstellen und dann die benutzten Objekte darin ablegen und wenn die Liste eine bestimmte Anzahl an Objekten enthält, die Objekte die zuerst geladen wurden raus schmeißen. Dabei muss man aber drauf achten, das die Elemente nicht verwechselt werden. :gruebel:

[Neutral General]

Hi,

Also in der Liste werden ja quasi nur Muster gespeichert. Also im Prinzip nur die "Klassen". Auf diese Liste zugegriffen wird eben wenn das Spiel auf einmal merkt: "Ich muss jetzt hierhin ein Monster mit der ID 3 platzieren"

Dann sucht sich das Programm aus der Monster-Liste den 4. Eintrag und klont quasi das Objekt aus der Liste und setzt es ins Spiel.

Das heißt auch das sich diese Muster-Liste während des Spiels nicht veändert.

[stahli]

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