ini-Datei, Registry, oder???

[AlterMann]

Hallo

Eine allgemeine Frage:
Wenn ihr in einem Programm einige (wenige) Daten (zuletzt geladene Dateien, Pfade, Einstellungen) für den nächsten Aufruf konservieren wollt, wo tut ihr das?

In einem (ini-)File, in der Registry (mißfällt mir eher, ich liebe Programme ohne Installation und ohne Registryeinträge)?

Was seht ihr für Vor- und Nachteile?
Falls File, welches Format? Text? typisierte Datei?

Grüße
Christian

[af0815]

in einem XML File, dazu gibt es in Lazarus Unterstützung. Ist vergleichbar mit den ini Files. Ist auch vom BS unabhängig, nur der Ort wo hingespeichert ist, hängt sinnvollerweise vom BS ab.

[Socke]

in einem XML File, dazu gibt es in Lazarus Unterstützung. Ist vergleichbar mit den ini Files. Ist auch vom BS unabhängig, nur der Ort wo hingespeichert ist, hängt sinnvollerweise vom BS ab.

Der Ort der Datei ist nicht betriebssystemabhängig! Nur die Standardpfade sind unterschiedlich.

Für solche GUI-Eigenschaften sind die TPropstorage-Abkommlinge TXMLPropStorage und TIniPropStorage ganz gut geeignet (Komponenten-Reiter "Misc"). Diese stellen beim Laden alle in TForm.SessionProperties aufgeführten Werte wieder her bzw. speichern sie beim Schließen in entsprechenden Dateien. Ob man XML oder INI wählt ist mehr oder weniger Geschmackssache.
Natürlich kann man damit auch selbst definierte Eigenschaften laden und speichern.

In GTK2 speichert werden die zuletzt genutzten Dateien von GTK2 verwaltet (was niemanden daran hindert, das zu umgehen).

[erka]

Hallo!
Als entwickler und auch Anwender kann ich nur bekräftigen: entweder ini (etwas alt und bieder aber simpel) oder xml (modern)!
In zunehmend extrem gesicherten Netzen ist die registry eh`kaum noch erreichbar...
Ob XML für Lazarus das einfachste und beste ist kann ich noch nicht sagen, da ich gerade einsteige....
Aber im Delphi würde ich das so machen...

[Socke]

In zunehmend extrem gesicherten Netzen ist die registry eh`kaum noch erreichbar...

Zumindest auf HKEY_CURRENT_USER sollte man doch immer zugreifen können; Je nach Einsatzgebiet müsste man auch beachten, dass die gesamte Festplatte evtl. wieder zurückgesetzt wird, aber auf einem Heimcomputer ist das eher unwahrscheinlich.

Ob XML für Lazarus das einfachste und beste ist kann ich noch nicht sagen, da ich gerade einsteige....
Aber im Delphi würde ich das so machen...

Die Klassen TRegistry und TIniFile (oder so ähnlich) sind sehr einfach zu benutzen. Wenn man direkt auf die XML-Struktur zugreifen will, bietet TXMLConf aus der Unit xmlconf (es gibt die Klasse auch noch in einer anderen Unit) ein ähnliche Abstraktion (vom Pfad direkt zum Wert). Die Arbeit mit den XML/DOM-Objekten dürfte ähnlich umständlich wie in Delphi sein.

Aber wie ich schon sagte, es ist Geschmackssache und viele Wege führen zum Ziel.

[mschnell]

Von Registry halte ich nichts .

Ini-Dateien (ini-file oder XML-Format) sollten an der richtigen Stelle stehen:

a) Generelle Einstellungen: Nur von root / Administrator änderbar, sonst schreibgeschützt (nicht User-Spezifisch meist bei der Installation erzeugt und dann nicht mehr verädert)
b) User-Einstellungen: Vom jeweiligen User veränderbar, sonst schreib- und lese-geschützt (User-Spezifisch (eine Datei pro User).
c) zur Kommunikation zwischen mehreren Usern (selten benötigtes Feature): eine Datei allgemein zugreifbar.

Für alle Typen gibt es in Windows und in Linux passende Speicherorte und Dateinamen. In Windows kann man die mit einem API Call auslesen. In Linux sind sie vermutlich statisch.

Für Windows / Delphi habe ich vor langer Zeit 'mal ein TIniFile - Derivat gebastelt, bei dem man die drei Varianten mit einer Property auswählen kann.

-Michael

[Hitman]

Für alle Typen gibt es in Windows und in Linux passende Speicherorte und Dateinamen. In Windows kann man die mit einem API Call auslesen. In Linux sind sie vermutlich statisch.l

Und zum Glück haben wir in FPC dafür GetAppConfigDir und GetAppConfigFile.

[felix96]

Ich lege einfach immer eine Textdatei im gleichen Verzeichnis an.
Wenn man der dann noch einen aussagekräftigen Namen gibt, weiß jeder Anwender was gemeint ist(relativ)

[mschnell]

Und zum Glück haben wir in FPC dafür GetAppConfigDir und GetAppConfigFile.

Gut ! Aber das ist ja nur eine der (mindestens) drei (halbwegs) sinnvollen Varianten.

-Michael

[mschnell]

Ich lege einfach immer eine Textdatei im gleichen Verzeichnis an. Wenn man der dann noch einen aussagekräftigen Namen gibt, weiß jeder Anwender was gemeint ist(relativ)

Das ist für eine (professionelle) Anwendung ganz schlecht.

Die Executables sollten (z.B. wegen Viren-Schutz) für den normal-Benutzer schreibgeschützt sein. Das geht am besten durch schreibgeschützte Directories. Windows Vista führt - glaube ich - Executable in "normalen" Directories gar nicht aus. (Windows 7: keine Ahnung). In Linux werden Executables meist in /user/bin, /user/local/bin oder anderen schreibgeschützen Directories installiert. Dort liegende INI-Dateien können also nur bei Installation beschrieben werden, nicht beim normalen Lauf des Programms. In Linux werden programmspezifische Konfigurations--Dateien allerdings meist in /etc abgelegt. Das ist ebenfalls schreibgeschützt. Veränderbare Konfigurations-Dateien liegen in Windows immer im Spezial-Directory-Tree des laufenden Users (es gibt aber auch einen für "alle User" für die dritte Variante.) In Linux werden sie im Home-Directory des Users (normalerweise /home/username) abgelegt und beginnen mit einem Punkt (Datei oder Verzeichnis) (und sind damit bei vielen Auflistungen unsichtbar). An den Punkt wird üblicher Weise der Name des Executables angehängt.

-Michael

[theo]

Das ist für eine (professionelle) Anwendung ganz schlecht.

Stimmt, deshalb gibt es, wie Hitman schon sagte:
http://www.freepascal.org/docs-html/rtl ... gfile.html" onclick="window.open(this.href);return false;
http://www.freepascal.org/docs-html/rtl ... igdir.html" onclick="window.open(this.href);return false;

[felix96]

Weine Anwendungen sind noch nicht Proffesionel

[Scotty]

Eine Ini-Datei kann von jedem unbedarften Benutzer mit jedem Editor gelesen und bearbeitet werden. Dass das manchmal nicht sinnvoll ist, mag sein. Was aber ist der Vorteil eines "modernen" XML Formats? Kann man da gleichzeitig lesen und schreiben? Kann man Binärinformationen leichter ablegen? Für den Benutzer ist XML meiner Meinung nach weniger schön, insbesondere da diese Dateien üblicher Weise auch noch im Internet Browser geöffnet werden.

[Euklid]

In einem (ini-)File, in der Registry (mißfällt mir eher, ich liebe Programme ohne Installation und ohne Registryeinträge)?

Promathika ist ja ein Programm, welches ohne Installation läuft und wir regeln das Speichern von Settings in der Tat über ini-Files. Bisher hat sich noch niemand beschwert. Bei den Hauptvorteilen dieser ini-Dateien bin ich der Meinung von Scotty: Die Speicherung der Daten wird transparent. Insbesondere auch für den Benutzer. Das ist denke ich viel wert.

Viele Grüße, Euklid

[AlterMann]

Das bestätigt mich in meiner Meinung, daß ein ini-File (für meine Zwecke) wohl das geeignetste sein dürfte.
Der Vorteil von XML erschließt sich mir einstweilen nicht, denn nur "moderner" ist mir zu wenig.
Da lob ich mir die Einfachheit und Transparenz einer ini-Datei schon mehr.

Hab's jetzt auch probiert, aber anscheinend begreif ichs noch nicht ganz.
Ich speichere in der FormClose-Routine so:

Code: Alles auswählen

procedure TForm1.FormClose(Sender: TObject; var CloseAction: TCloseAction);
begin
 IniPropStorage1.StoredValue['LastFile1'] := Last5Files[1];
 IniPropStorage1.StoredValue['LastFile2'] := Last5Files[2];
 IniPropStorage1.StoredValue['LastFile3'] := Last5Files[3];
 IniPropStorage1.StoredValue['LastFile4'] := Last5Files[4];
 IniPropStorage1.StoredValue['LastFile5'] := Last5Files[5];
end;

funktioniert auch prächtig, nach Beenden des Programms steht alles otrdentlich in der Ini-Datei.

Dann möcht ich es so wieder laden:

Code: Alles auswählen

procedure TForm1.FormShow(Sender: TObject);//OnShow
begin
 AddToLast5Files(IniPropStorage1.StoredValue['LastFile1']);
 AddToLast5Files(IniPropStorage1.StoredValue['LastFile2']);
 AddToLast5Files(IniPropStorage1.StoredValue['LastFile3']);
 AddToLast5Files(IniPropStorage1.StoredValue['LastFile4']);
 AddToLast5Files(IniPropStorage1.StoredValue['LastFile5']);
end;

Die OnShow-Methode wird auch aufgerufen, aber es kommen lauter leere Strings zurück.
Was kann da wohl wieder sein?

Grüße
Christian