Suche Komponente um Settings in Datei zu speichern

[Shark99]

Ich bin dabei eine neue Win32 App mit Delphi zu entwickeln und wollte diesmal keine Registry mehr benutzen um die Einstellungen/Programmdaten zu speichern. Statt dessen wäre mir eine Datei im User Verzeichnis viel lieber (easy Backup etc). Ich wollte aber flexibler sein als es mit einer Ini-Datei möglich ist. Es wäre nett wenn ich verschiedene Datensätze, z.b. Bilder und Unicode Texte abspeichern könnte. Alles sollte aber in einer Datei sein, also irgendwas in der Art von XML. Es sollte leicht zu benutzen sein (will nicht manuell Daten parsen müssen).

Kann mir jemand bitte hier was empfehlen? Darf auch eine kostenpflichtige Komponente sein.

[himitsu]

'ne fertige Komponente (wegen der Bilder und der großen Daten) kenn ich jetzt nicht,

Aber XML mit XPath muß nicht umständlich sein, ohne viel zu parsen.
Zusätzlich gibt es für XML auch Möglichkeit dieses über Datenobjekte zu verwalten.
Ich vergeß immer den Namen, aber vor wenigen Tagen wurde hier darüber gesprochen. (läßt sich bestimmt finden, wenn man nach XML sucht)

[Ralf Kaiser]

Eventuell OmniXML?

[Popov]

Eventuell (MyBase) TClientDataSet (bei Delphi 7 im Register Datenzugriff). Ist eine Clientdatenbank und speichert laut OH Binär und XML. Ich selbst habe zwar noch nie damit gearbeitet, bis auf ein mal angetestet, aber es sollte genau das bieten was du brauchst.

[schlecki]

was ich in letzter Zeit immer gerne mache, ist Settings und so Zeugs im json-Format zu speichern. Das ist nicht so gesprächig (im Sinne von doppelten Tags) wie XML und lässt auch alle möglichen Arten von Daten zu. Und der Zugriff ist mit TSuperObject (einfach googlen - liegt glaube ich auch direkt bei google) super-easy

Delphi-Quellcode:

var
  cfg: ISuperObject; // ist sogar ein Interface - braucht also nicht freigegeben werden :)
begin
  cfg := SO('{Settings: {Value1: "Hallo", Value2: 5}}');
  Writeln(cfg.S['Settings.Value1']); // Eigenschaften sind Case-Sensitiv!
  cfg.I['Settings.NewValue'] := 10;
  
  Writeln(cfg.AsJson(true));
end;

Es gibt iirc auch direkt ParseFile und SaveToFile - hier habe ich aber die Parameter und genauen Namen nicht im Kopf...

Viel Spaß
schlecki

[Wishmaster]

NativeXml

Features

Read XML directly from string, stream or file with fast parser (1Mb/sec on 1.5GHz P3), writes to string, stream and file even faster.

Import of all common tags, including comments, CDATA, XML declarations and stylesheets.

Load from streaming media is supported; you can set up events to work with the node data while it comes in. See example 1. No need to keep the whole XML document in memory! Works well for huge documents. This is the SAX-like approach.

Save to file, string or stream in readable, preserve or compact format. Readable format will add linefeeds and indents to make the file readable in a text editor. Compact format sticks to the Xml specification and adds minimal control characters. Preserve format keeps the markup of the document exactly as it was.

Directly add blobs or streams in the XML file, they will be encoded as Binhex or Base64 (but you don't have to worry about that).

Many native Delphi types can be stored directly to the nodes, making this code very suitable to use while writing storage methods. Store and load boolean, single, double, word, integer, string, TFont, TColor, TPen, TBrush, TDateTime. You don't have to worry about escaping the strings; this is done automatically.

Loads and saves ANSI, UTF-8 as well as Unicode (UTF-16) documents and implements proper conversion warnings. Recognises streams even without byte order marks. NativeXml works internally with UTF8 encoded strings to preserve extended characters, and supports widestrings.

Unique feature: Store, read and create any TPersistent object to/from XML directly (see Example5). This is done by iterating through all of the objects' published properties by use of RTTI (runtime type information). This feature is only available for D5 and up.
New! Now you can use the binary format of NativeXml. This avoids the expensive parsing process to get the textual xml data into the document (DOM). And even better, the binary file size is much smaller, ~50% of file size with uncompressed binary files, and ~15% of the file size in zlib-compressed files. And you can use AES encryption to keep your sensitive files safe from prying eyes.
The interface is the same whether textual xml or binary xml files are used, so you can work with binary files for speed and size purposes, then always send them to the public as normal xml files.

[BMI]

Zitat von Shark99:

Es wäre nett wenn ich verschiedene Datensätze, z.b. Bilder und Unicode Texte abspeichern könnte.

mhh, Du hast aber nicht zuvor irgendwie BMP oder gar AVI oder .flv/mp4 in der Registry abgespeichert?


So Experten gab es schon mal.
Die haben auch regelmäßig Bitmap-Grafiken in der Registry abgespeichert .... weil sie gehört hatten, daß kleine Dateien die Festplatte so fragmentieren.

Speichere doch Bilder extern als BMP, PNG oder Tif und nicht in ner Settings-Datei.

reicht schon, wenn eingebettete Videofilme die Powerpointdateien so aufblähen.

[Shark99]

Nein, hab bis jetzt einen Mix aus Registry und Dateien im User Verzeichnis genommen. Will aber nun am besten nur eine Datei haben, von der die Benutzer leicht ein Backup machen könnten. Waren paar gute Vorschläge dabei. Danke!

[Steku]

Dann denk' doch mal darüber nach es so zu machen, wie Microsoft
mit seinen .Docx / .Xlsx Formaten.

Das sind letztlich Zip-Dateien, die eine Ordner-Struktur beinhalten
in denen dann die Infos als XML Datei und die originalen Dateien/Bilder
abgelegt sind.

Vielleicht reicht dir ja schon eine Zip-Datei als
Container + eine Ini in der du die entsprechenden Settings reinschreibst.

Gruß
Steku

[NickelM]

Naja wenn du eine Zip-Datei in Binär mal anschaust, sind im Endeffekt nur Pfade gespeichert.
WinRar zerlegt nur die Pfade in Ordner.
Es gibt Komponenten dafür, für leichtes Packen/Entpacken von Zip-Dateien (z.b. "Abbrevia 5.0" das geht glaub ich auch für 64bit, da es reiner Code ist).

ICH, wie gesagt musst du wissen, finde es doof, dass man mit WinRar dann die Einstellungen bearbeiten könnte.

Wenn du hingegen, ein "eigenes" Format machst, kann nur dein Programm lesen. Was natürlich auch ein Nachteil sein kann.

Gruß
NickelM