Hallo DPler

habt ihr nich auch manchmal das Bedürfnis, Programmeinstellungen zu speichern? Jo, denke ich, hat jeder mal gemacht. Nun gibts dafür aber unterschiedliche Möglichkeiten, wie man das realisieren kann. Nur um mal n paar aufzuzählen:
- Typisierte Dateien
- Streams
- Registry
- Ini-Dateien
- StringList
- ...

Irgendwie haben die aber alle den Nachteil, dass man entweder bei den Daten eingeschränkt ist, oder, dass man die selbe Arbeit immer wieder machen muss. Da der (Hobby-)Programmierer im Allgeimeinen faul ist, hab ich mir mit der dpCollection, was gebastelt, was das Speichern von Optionen etwas vereinfacht.

Das Ganze besteht aus 2 Units: Options_class.pas und MyOptions_class.pas. Options_class.pas definiert die Klasse TOptions und MyOptions_class.pas die Klasse TMyOptions. In TMyOptions stehen die Daten, die gespeichert werden sollen als published properties. TOptions definiert Methoden zum speichern und laden.

Benutzung:
1. MyOptions anpassen:

zusammenfalten · markieren

Delphi-Quellcode:

  TMyOptions = class(TComponent)
  private
    { Felder für published properties }
  public
    constructor Create;
    destructor Destroy; override;
  published
    { hier einfach published properties erstellen }
  end;

implementation

constructor TMyOptions.Create;
begin
  inherited Create(nil);
  { hier Objekte(z.B. StringListen) erstellen }
end;

destructor TMyOptions.Destroy;
begin
  { hier erstellte Objekte freigeben }
  inherited Destroy;
end;

2. Optionen speichern:

zusammenfalten · markieren

Delphi-Quellcode:

Options: TOptions;
...
Options := TOptions.Create;
Options.AppDataDir := 'MyProg'; // Legt den Namen für einen Ordner in AppData fest; Wird in AppData gespeichert/daraus geladen, so geschieht das in diesem Unterordner
...

// Werte zuweisen:
Options.Data.Wert1Int := 5;
Options.Data.Wert2Str := 'Hallo DP';
Options.Data.StringList.Text := Memo1.Lines.Text;
...

// Speichern:
Options.SaveToFile('C:\MyOptionsFile.dat'); // speichert an einem bestimmten Pfad
Options.SaveToFile(odExePath, 'MyOptionsFile.dat'); // Speichert im Ordner, in dem die Exe liegt
Options.SaveToFile(odHomeDir, 'MyOptionsFile.dat'); // Speichert in "Dokumente und Einstellungen\<UserName>\Anwendungsdaten\<AppdataDir>\"
Options.SaveToFile(odExeHome, 'C:\MyOptionsFile.dat'); // speichert, wenn möglich, im Ordner der Exe; ansonsten in AppData
Options.SaveToFile(odHomeExe, 'C:\MyOptionsFile.dat'); // speichert, wenn möglich in AppData, ansonsten im Order der Exe
...

//Laden:
Options.LoadFromFile('C:\MyOptionsFile.dat');
Options.LoadFromFile(odExePath, 'MyOptionsFile.dat');
Options.LoadFromFile(odHomeDir, 'MyOptionsFile.dat');
Options.LoadFromFile(odExeHome, 'MyOptionsFile.dat');
Options.LoadFromFile(odHomeExe, 'MyOptionsFile.dat');
...

// Werte benutzen:
SpinEdit1.Value := Options.Data.Wert1Int;
Edit1.Text := Options.Data.Wert2Str;
Memo1.Lines.Text := Options.Data.StringList.Text;

...
Options.Free;

Vorteil:
- Egal, wie viele Werte welchen Datentyps und ob mit der Zeit noch welche dazukommen, der Anpassungsaufwand beschränkt sich darauf, published properties zu erstellen ==> an den Methoden, die speichern/laden muss nix geändert werden.
- Durch den Parameter odExeHome kann man die Einstellungen so speichern, dass sie, wenn möglich, im selben Ordner wie die Exe liegen(sinnvoll, wenn sich das Prog einfach durch löschen deinstallieren lassen soll --> Weitergabe als Archiv) und ansonsten in den Anwendungsdaten(Damits auch keine Progleme mit Usern ohne Admin-Rechte gibt --> Weitergabe als Setup). Und zwar funktioniert das ohne was am code zu ändern oder auch nur neu kompilieren zu müssen. ==> Die selbe exe für Archiv- und Setup-Distribution(siehe hierzu Freeware- und OS-Sparte)...

Bisher getestet unter:
- WinXP Home SP2
- Win2000 Prof. SP4
- Win98 SE

Benötigt wird:
- dpCollection.pas(klick)
- dpCollection_tmpl.pas(klick)
- jedi.inc(klick)
--> jetzt gar nix mehr

Im Anhang:
- Options_class.pas
- MyOptions_class.pas
- BeispielProjekt(Source+Exe)

rfc

Christian

Hi,

tolle Sache, das funktioniert ja dann so, wie ich's von Cocoa auf Mac kenne .
Ich hab's noch nicht ausprobiert, werde das aber nachholen, sobald ich Zeit dazu finde, vielen Dank schonmal...

cu

Sorry, aber irgendwie sind deine Klassen ziemlich sinnlos.
Wenn ich ein einziges Objekt streamen will, nehme ich doch keine Collection - erst recht keine typisierte, für die ich erst 5 Units runterladen muss - , sondern tippe in höchstens 30 Sekunden:

zusammenfalten · markieren

Delphi-Quellcode:

type
  TSettings = class(TComponent) // wer unbedingt TPersistent will, kann immer noch bspw. per Class-Hack TWriter.WriteProperties benutzen
  ...
  published
    BotherUser: Boolean;
  end;

...

WriteComponentResFile(ParamStr(0) + 'Settings.dat', MySettings);

...

MySettings := ReadComponentResFile(ParamStr(0) + 'Settings.dat', null);

Das soll kein Vorwurf sein, wahrscheinlich hast du dich mit der RTTI einfach noch nicht beschäftigt.
Du könntest statt deiner Collection allerdings einen kleinen Wrapper um meinem Bleistiftcode bauen, soll heißen mit deinen Load/Save-Overloads, einer Binary-Property, ...

Zitat von Khabarakh:

Das soll kein Vorwurf sein, wahrscheinlich hast du dich mit der RTTI einfach noch nicht beschäftigt.

Jo, RTTI steht noch auf der Liste, die schneller wächst, als abgearbeitet wird...

*F1 drückt* Ui, sieht ja sehr interessant aus! Danke, für den Hinweis auf RTTI!

Zitat:

Du könntest statt deiner Collection allerdings einen kleinen Wrapper um meinem Bleistiftcode bauen, soll heißen mit deinen Load/Save-Overloads, einer Binary-Property, ...

Hab meinen Code nun entsprechend geändert. Benötigt wird jetzt weder dpCollection noch jedi.inc.
Geändert hat sich im Prinzip nur Save, Load und Binary...

//Nachtrag:
An der Benutzungh hat sich trotzdem nix geändert.

aktuelle Version, samt neuem Beispiel im ersten Post.

mfg

Christian