TMemIniFile: Vorteile, Nachteile, Einschränkungen

[Der schöne Günther]

Das würde mich jetzt aber auch interessieren.

Falsch kodierte Strings meinetwegen. Vielleicht Steuerzeichen im String?

[himitsu]

Was TMemIniFile kann, ist eine andere Sache ... die bassiert auf TStringList und kann beim Laden viele Encodings verstehen.

INI per se gibt es nur als ANSI oder Unicode (UTF-16).
Laut Definition der INI-API von Microsoft.

[Uwe Raabe]

Zitat:

Zitat von p80286 (Beitrag 1377078)

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

TMemInifile verwendet das beim Create angegebene Encoding oder das durch das BOM angegebene oder ANSI, wenn kein BOM vorhanden ist (zumindest unter Windows). Vermutlich war hier aber ein UTF8-BOM vorhanden, es folgten dann aber Zeichen, die im UTF8 nicht vorkommen. Das ist schlichtweg nicht erlaubt und würde vermutlich auch mit älteren Delphi-Versionen nicht richtig funktionieren.

[p80286]

Wenn das der Fall sein sollte, das kann jedem(?) mal passieren, ist das persönliches Pech. Wer ungenießbare Daten produziert, soll sich nicht wundern wenn Programme damit nicht umgehen können.

Gruß
K-H

[Michael II]

Seit Umstellung auf TMemIniFile sehe ich bei einigen Kunden [Computerspiel => Kunden wissen teilweise nix über ihren PC] einen massiven Anstieg von "...kann nicht erstellt werden. Der Prozess kann nicht auf die Datei zugreifen, da sie von einem anderen Prozess verwendet wird." Fehlern, wenn das MemIniFile geschrieben werden soll. Dies geschieht auch bei Memini-Files, welche genau einmal gelesen und einmal geschrieben werden.
Das ist natürlich kein Delphi/Emba Problem, sondern ein "AntivirusScanner-Problem" aber definitiv ein Kostenfaktor, wenn Support pauschal abgerechnet wird.

Wenn beim Schreiben was schief läuft (auch das ist nat. kein Delphi Problem), dann ist ein Teil der Daten oder der Inhalt der ganzen memini weg. (Auch das gab's schon wiederholt bei sehr wenigen Kunden.) Ich speichere deshalb jeweils vor dem Schreiben der Daten mittels SetStrings am Anfang und am Ende der Daten eine Versionsnummer ab und überprüfe beim Laden des MeminiFiles, ob diese Nummern am Anfang und am Ende vorhanden sind. Wenn die Marken vorhanden sind, dann erstelle ich ein Backup der Datei; wenn die Marken nicht vorhanden sind, dann lade ich das Backup.

Falls du die MemIni-Daten beim Beenden deines Programms speicherst, dann solltest du unbedingt daran denken, Windows möglichst am Runterfahren zu hindern, bis die MemIni-Daten auf Platte sind. [Das gilt natürlich generell, wenn du Daten speichern willst... ini-Files sind da aber natürlich toleranter...]

autosave/modified, GetStrings, SetStrings finde ich praktisch.

[cramer]

Zitat:

Zitat von Michael II (Beitrag 1377145)

Wenn beim Schreiben was schief läuft (auch das ist nat. kein Delphi Problem), dann ist ein Teil der Daten oder der Inhalt der ganzen memini weg. (Auch das gab's schon wiederholt bei sehr wenigen Kunden.) Ich speichere deshalb jeweils vor dem Schreiben der Daten mittels SetStrings am Anfang und am Ende der Daten eine Versionsnummer ab und überprüfe beim Laden des MeminiFiles, ob diese Nummern am Anfang und am Ende vorhanden sind. Wenn die Marken vorhanden sind, dann erstelle ich ein Backup der Datei; wenn die Marken nicht vorhanden sind, dann lade ich das Backup.

Falls du die MemIni-Daten beim Beenden deines Programms speicherst, dann solltest du unbedingt daran denken, Windows möglichst am Runterfahren zu hindern, bis die MemIni-Daten auf Platte sind. [Das gilt natürlich generell, wenn du Daten speichern willst... ini-Files sind da aber natürlich toleranter...]

Das ist interessant, ich habe auch ähnliche Probleme, das ein INI File meiner Programme manchmal leer oder unvollständig ist.
Es gibt zwar eine SIK Funktion, die manuell eine Sicherung erstellt aber wer macht das schon immer.
Ich hatte vermutet, dass der Prozess beim Speichern der INI von Benutzern im TM abschossen wurde oder das es bei einem Windows/Programm-Absturz passiert.

Gibt es ein kleines Beispiel für die Versionsnummern Lösung und wie man Windows am Runterfahren hindert?

[Michael II]

Datei bei Windows Shutdown speichern:

Delphi-Quellcode:

type
  TForm1 = class(TForm)
  private
    procedure WMQueryEndSession(var Msg: TWMQueryEndSession); message WM_QUERYENDSESSION;
  end;

procedure TForm1.WMQueryEndSession(var Msg: TWMQueryEndSession);
begin
  // TMemIniFile Daten speichern

  // Windows erlauben, herunterzufahren
  Msg.Result := 1;
end;

Ich speichere am Anfang und am Ende meines MemIni-Files einen Wert. Beispiel ausgabe 14 von meinem MemIniFile:
[BOF]
ausgabe=14
..... Daten ....
[EOF]
ausgabe=14

Öffnen des MemIniFiles D: Ich überprüfe unter BOF und EOF je den Wert ausgabe. Wenn OK, dann vergleiche ich den Wert von "ausgabe" mit dem Wert im aktuellsten Backupfile B. Ich nehme die neuere Version von beiden; i.a. also D (wenn D, dann erstelle ich davon ein neues Backup B).
Schreiben des MemIniFiles: Ich entferne BOF und EOF, lese via GetStrings die Daten des MemIniFiles in eine TStringList h, setze an den Anfang von h [BOF] ausgabe=... und am Ende von h [EOF] ausgabe=..., inkrementiere dabei "ausgabe", schreibe h via SetStrings zurück und speichere D ab.

D.h. erstelle
TMeinMemIniFile = class(TMemIniFile) und passe mindestens
constructor und destructor entsprechend an.
AutoSave
UpdateFile