Objektorientiertes TIniFile-Replacement mit Unicode-Fähigkeit

[himitsu]

Dein Ini.UpdateFile gehört aber eigentlich noch vor das Finally

Zitat:

Dadurch sollte der Code auch relativ leicht zu Lazarus portierbar sein.

Lazazus sollte eigentlich auch in der Lage sein, auf die WinAPI zuzugreifen.


Ich würde dir empfehlen keine lokalen Sprachinformationen zu nutzen, also kein DateToStr oder FloatToStr usw.
Ich weiß grde nicht, ob man im D7 bei diesen Funktionen ein FormtSettings angeben kann, aber wenn, dann solltest du dieses verwenden und dann für Fließkommazahlen und Zeit-/Datumswerte ein einheitliches Format verwenden.
Sonst gibt es das bekannte Problem, daß man die INI eventuell nicht wieder auslesen kann, wenn jemand die Sprache umstellt oder man sie auf einem anderem Rechner auslesen will.

z.B. Dezimaltrenner als "Punkt" und für's Datum macht sich "yyyy-mm-dd", bzw. "yyyy/mm/dd" und "hh:mm:ss" recht gut



Nein, es müssen nicht immer #13#10 als Zeilenumbruch vorkommen.
Was mag wohl passieren, wenn z.b. nur eine #10 vorkommt?

Nja, im Grunde müßtest du eigentlich nochwas abfangen, denn was passiert wohl, wenn ein \n als Text in AValue drinsteht?
wie z.B. ein "ja\nein"

So, der nachfolgende Code normalisiert alle "bekannten" Zeilenumbrüche Windows/Linux/Mac.
Oder du behandelst alle Steuerzeichen, wie #10, #13, #0 einzeln.
#0 = \0
\ = \\
#9 = \t
#10 = \n
#13 = \r
...

Delphi-Quellcode:

procedure TUniObjectIniValue.SetString(AValue: TUniObjectIniString);
begin
  SL:= TUniObjectIniStringList.Create;
  try
    SL.Text:= AValue;
    {$IFDEF UNICODE}
      Value:= UnicodeStringReplace(SL.Text, sLineBreak, '\n', [rfReplaceAll]);
    {$ELSE}
      Value:= StringReplace(SL.Text, sLineBreak, '\n', [rfReplaceAll]);
    {$ENDIF}
  finally
    SL.Free;
  end;
end;

function TUniObjectIniValue.GetString: TUniObjectIniString;
begin
  {$IFDEF UNICODE}
  result:= UnicodeStringReplace(FValue, '\n', sLineBreak, [rfReplaceAll]);
  {$ELSE}
  result:= StringReplace(FValue, '\n', sLineBreak, [rfReplaceAll]);
  {$ENDIF}
end;