Delphi 2010 INI oder mitgelieferte Alternative?

[OrNEC]

Ich grüße Sie,

ich habe vor einige Werte in eine Ini-Datei zu speichern, aber die IniFiles-Uses kann wohl kein Unicode und deswegen überlege ich wie ich jetzt vorgehen soll. Eine zusätzliche Komponente möchte ich meiden, daher meine Frage: was liefert Delphi 2010 mit um die ini-Lösung zu ersetzen? Oder kann man dieser doch irgendwie Unicode beibringen?

Danke!

[blackfin]

Normalerweise sollte D2010 INI-Files auch standardmäßig in Unicode erstellen und beschreiben.
Hast du evtl. versucht eine bereits bestehende ANSI-codierte INI-Datei zu verändern? Dann schreibt Delphi die Datei AFAIK auch weiterhin mit ANSI.

Ansonsten probiers doch mal mit einer TMemInifile und Angabe des Encodings:

Delphi-Quellcode:

FIniFile := TMemIniFile.create(Filename, TEncoding.UTF8);
FIniFile.WriteString(...,...);
...
FIniFile.UpdateFile();

Aber generell: was spricht gegen XML statt INI? Ist meist für komplexere Werte eleganter und auch nicht sonderlich schwer zu handeln...

[Lemmy]

Guten Morgen,

oder je nach Art der Daten macht sich auch ein TClientDataset ganz gut...

Grüße

[Bernhard Geyer]

Zitat:

Zitat von OrNEC (Beitrag 1195302)

ich habe vor einige Werte in eine Ini-Datei zu speichern, aber die IniFiles-Uses kann wohl kein Unicode und deswegen überlege ich wie ich jetzt vorgehen soll. Eine zusätzliche Komponente möchte ich meiden, daher meine Frage: was liefert Delphi 2010 mit um die ini-Lösung zu ersetzen?

Mit etwas Einarbeitung ist XML die flexibelste Alternative

[cookie22]

Für einige wenige Werte ist der Overhead von XML oder TClientDataset doch viel zu groß, noch dazu bringt es keinen Vorteil. D2010 kann Unicode-Inis, wo also ist das Problem?

[OrNEC]

Bei mir kann es leider nicht, obwohl die ini-Datei von Delphi neu erstellt wird. Liegt es vllt daran, dass ich ganz normalen String Datentyp verwende und nicht WideString und wie die da alle heißen?

[DeddyH]

Wenn ich den Code von blackfin anwende, bekomme ich eine Ini in UTF8-Kodierung. Du musst wohl irgend etwas falsch machen.

[Bernhard Geyer]

Zitat:

Zitat von cookie22 (Beitrag 1195321)

Für einige wenige Werte ist der Overhead von XML oder TClientDataset doch viel zu groß, noch dazu bringt es keinen Vorteil.

Da wir nicht wissen wie aufgebläht seine Ini-Datei ist wird das spekulation sein ob das Overhead ist oder nicht.
Gut ist wenn man sich grundsätzlich damit auseinander setzt. Wir setzten selbst bei kleinen Tools auf XML weil wir eine "XML-Ini"-Klasse haben welche den Mehraufwand gegenüber einer Ini-Datei gegen 0 streben lässt.

[Bernhard Geyer]

Zitat:

Zitat von OrNEC (Beitrag 1195323)

Bei mir kann es leider nicht, obwohl die ini-Datei von Delphi neu erstellt wird. Liegt es vllt daran, dass ich ganz normalen String Datentyp verwende und nicht WideString und wie die da alle heißen?

Der Type String = UnicodeString unter D2010.
Dein Problem ist wohl eher das die WinApi (TIniFile verwendet im Hintergrund die WinAPI) bei Neuanlegen standardmäßig erstmal mit Ansi-Dateien arbeitet und nicht bei bedarf diese nach Unicode ändern kann.
Wenn du die Inidatei hart mit Unicode (Ich denke eine Leere Ini-Datei mit einem UTF8/Unicode-BOM-Header sollte reichen) anlegst sollte Windows auch weiter mit Unicode arbeiten.

[OrNEC]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1195327)

Wenn du die Inidatei hart mit Unicode (Ich denke eine Leere Ini-Datei mit einem UTF8/Unicode-BOM-Header sollte reichen) anlegst sollte Windows auch weiter mit Unicode arbeiten.

Wie mache ich das genau? Hast du vllt ein Beispiel? Danke!

[DeddyH]

Siehe #2

[OrNEC]

Zitat:

Zitat von DeddyH (Beitrag 1195331)

Siehe #2

Soweit ich gelesen habe, wird hier die ini im Arbeitsspeicher gehalten und geändert bzw. upgedatet. Das will ich aber meiden, da beim Programmabsturz alle vorgenommenen Einstellungen verloren gehen.

[Daniel]

Das ließe sich ggf. über einen Aufruf von TMemIniFile.UpdateFile regeln:
http://docwiki.embarcadero.com/Libra...ile.UpdateFile

[DeddyH]

Wie es ja auch im verlinkten Code steht :roll:

[jaenicke]

TIniFile basiert auf seit mehr als 15 Jahren veralteten API-Funktionen aus Windows 3.x für 16-Bit (die auch z.B. Anführungszeichen nicht korrekt behandeln) und sollte daher sowieso nicht mehr benutzt werden.
Wer unbedingt heutzutage noch INIs nutzen will, für den ist TMemIniFile auf jeden Fall besser, da es nativ in Delphis RTL implementiert ist.

[OrNEC]

Ok muss ich wohl so leben. Aber ich verstehe nicht wieso embarcadero es nicht schaff ALLES, aber wirklich alles unicodefähig zu machen.

[TiGü]

Zitat:

Zitat von OrNEC (Beitrag 1195344)

Ok muss ich wohl so leben. Aber ich verstehe nicht wieso embarcadero es nicht schaff ALLES, aber wirklich alles unicodefähig zu machen.

Der Fehler sitzt vor dem Gerät!

TMemIniFile <> TIniFile!!!

TMemIniFile := Wird von der RTL behandelt (basierend auf TStringList);
TIniFile := Wrapper um die veralteten WinAPI-Funktionen (NICHT nehmen!);

Vgl. den Post von blackfin!

[OrNEC]

Thx... :thumb:

[cookie22]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1195326)

...Wir setzten selbst bei kleinen Tools auf XML weil wir eine "XML-Ini"-Klasse haben welche den Mehraufwand gegenüber einer Ini-Datei gegen 0 streben lässt.

Wir sind von XML zu Ini zurück gegangen, weil einige user nicht in der Lage waren die XML-Datei zu editieren. Ist für den User einfach übersichtlicher.

[jaenicke]

Warum sollte der User das auch machen sollen?
Entweder ist es eine gewollte Konfiguration, dann gibt es normalerweise einen Dialog dafür, oder es ist nicht gewollt, dass die Datei modifiziert wird, dann muss man das auch nicht vereinfachen. :gruebel:

[cookie22]

Weil wir für Admins versteckte Optionen und Features anbieten, die man nur über die Inis freischalten kann. Man kann damit z.B. Verschlüsselung und Internetzugriff erlauben oder eben nicht.

[Codehunter]

Anmerkung am Rande: Such doch mal mit dem Gockel nach UniObjectIni. Hab ich GENAU deswegen erfunden :-)

[Bernhard Geyer]

Zitat:

Zitat von cookie22 (Beitrag 1195355)

Wir sind von XML zu Ini zurück gegangen, weil einige user nicht in der Lage waren die XML-Datei zu editieren. Ist für den User einfach übersichtlicher.

Eigentlich haben wir für sowas Konfigurationsdialoge. Unsere Konfiguration kann aber auch mittlerweile bis zu 10 MB Dateigröße erreichen :-)

[cookie22]

Die haben wir auch, bis halt auf die versteckten Funktionen, die für normale User nicht sofort zugänglich sein sollen. :)