TMemIniFile: Vorteile, Nachteile, Einschränkungen

[EWeiss]

Zitat von Luckie:

Er hat nach Vor- und Nachteilen von TMenIniFile gefragt. Warum empfehlt ihr im jetzt XML und JSON?

Das ist die Moderne Ableitung von "Wie mache ich einen Thread runter"

gruss

[OlafSt]

Habe ich nicht sogar hier gelesen, das TIniFile eine Reihe Bugs "geerbt" hat, weil es die WinAPI-Funktionen benutzt ? Und das man besser TMemIniFile benutzt, weil dies komplett neu geschrieben wurde, ohne WinAPI-Funktionen ?

Abgesehen von einem TMemIniFile.Update; , das beim Schreiben einer Ini-Datei ausgeführt werden muß, ist der Unterschied zum Original TIniFile gleich null. Meine Empfehlung ist daher klar TMemIniFile.

Man sollte es nur nicht übertreiben, manche Konfigurationen (soferm man sowas dann noch so nennen kann) gehören dann doch besser in XML oder JSON und sind dann meist auch so komplex, das der "Vertriebsmann" oder "die Sekretärin" da eh nix mehr dran ändern würde.

[bra]

Um mal meinen Senf dazuzugeben:
Ehe man den Benutzer (Endanwender) in einer Konfigurationsdatei (ob ini, xml oder sonstwas) rumpfuschen lässt, sollte man lieber eine vernünftige Oberfläche für die Einstellungen bereitstellen.

[Rollo62]

Wenn ich komplexe Strukturen brauche dann XML oder JSON,
ansonsten ist bei kleinen, simplen Speicherdaten doch nichts gegen INI Files zu sagen.
Warum dann immer mit Kanonen auf Spatzen ... ?
Muss halt jeder selber wissen.

Rollo

[Glados]

Zitat:

Er hat nach Vor- und Nachteilen von TMenIniFile gefragt. Warum empfehlt ihr im jetzt XML und JSON?

Ist doch nicht schlimm

Zitat:

Abgesehen von einem TMemIniFile.Update; , das beim Schreiben einer Ini-Datei ausgeführt werden muß, ist der Unterschied zum Original TIniFile gleich null

Eine Interposer-Klasse mit überschriebenem Destroy, wo man Update selber aufruft, hilft hier.

[freimatz]

Zitat von Luckie:

Er hat nach Vor- und Nachteilen von TMenIniFile gefragt. Warum empfehlt ihr im jetzt XML und JSON?

Nun ja ... JSON hat er selbst ins Spiel gebracht.
Und Kathinkas Law gilt auch hier.

[Uwe Raabe]

Zitat von Glados:

Zitat:

Abgesehen von einem TMemIniFile.Update; , das beim Schreiben einer Ini-Datei ausgeführt werden muß, ist der Unterschied zum Original TIniFile gleich null

Eine Interposer-Klasse mit überschriebenem Destroy, wo man Update selber aufruft, hilft hier.

Oder man setzt das AutoSave , das es seit Delphi 10.1 Berlin gibt. Zusammen mit dem ebenfalls dort eingeführten Modified schreibt es nämlich nur dann, wenn sich etwas geändert hat.

[freejay]

Also ich verwende (einen Nachfahren von) TMemIniFile beim Lesen und das "normale" TIniFIle beim Schreiben.

Warum?

TMemIniFile ist beim Lesen viel schneller (wenn man die Datei nicht für jeden zu lesenden Wert neu öffnet...).

TIniFile zerstört mir beim Schreiben nicht die Formatierungen und Kommentare in der INI-Datei, die man möglicherweise zur besseren Übersicht beim manuellen Bearbeiten angelegt hat.

Mir sonst noch bekannter Unterschied zwischen beiden:

Die beiden Units behandeln in Hochkommas gesetzte Werte unterschiedlich: TIniFile schmeißt die Hochkommas einfach weg (wenn der Wert mit " anfängt und aufhört), TMemIniFile tut das nicht.

Was die beiden sonst noch so trennt weiß ich nicht...

[greenmile]

Ich bin dieser Tage über einen üblen Bug gestolpert. Ich hatte eine INI Datei, die unlesbare Zeichen (ein Export aus einer mySQL) im Nicht-UTF8 Format enthielt. Die INI hatte ca 1000 Sektionen mit einigen Werten. Alles, was nach dem ersten vorkommen des Nicht-UTF8-Zeichens kam, wurde von TMemIni nicht mehr eingelesen, von TIniFile aber sehr wohl. Im Ergebnis konnte TMemIni nur 250 (oder so) Sektionen einlesen, während TIniFile alles eingelesen hat. Die Zeichen waren nicht im Sektionsnamen enthalten, sondern in einem der Werte.

[p80286]

Zitat von greenmile:

Ich bin dieser Tage über einen üblen Bug gestolpert. Ich hatte eine INI Datei, die unlesbare Zeichen (ein Export aus einer mySQL) im Nicht-UTF8 Format enthielt. Die INI hatte ca 1000 Sektionen mit einigen Werten. Alles, was nach dem ersten vorkommen des Nicht-UTF8-Zeichens kam, wurde von TMemIni nicht mehr eingelesen, von TIniFile aber sehr wohl. Im Ergebnis konnte TMemIni nur 250 (oder so) Sektionen einlesen, während TIniFile alles eingelesen hat. Die Zeichen waren nicht im Sektionsnamen enthalten, sondern in einem der Werte.

Was bedeutet "Nicht-UTF8-Zeichen"?

Schlußfolgerung: D10.x kann nicht mehr mit ANSI/Extended-ASCII umgehen?

Gruß
K-H