Delphi 2010 INI oder mitgelieferte Alternative?

[DeddyH]

Siehe #2

[OrNEC]

Zitat von DeddyH:

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

[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 von OrNEC:

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...

[cookie22]

Zitat von Bernhard Geyer:

...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.