Unterschied TMemIniFile 10.2 Tokyo / 10.3 Rio

[Schokohase]

Also damit wir alle über die gleiche Problematik sprechen:

Delphi-Quellcode:

program MemIniTest;

{$APPTYPE CONSOLE}
{$R *.res}

uses
  System.Classes,
  System.SysUtils,
  System.IniFiles,
  System.IOUtils;

procedure CheckIniClass(AIniFactory: TFunc<string, TCustomIniFile>);
const
  C_CONTENT = '' + //
    '[S1]' + sLineBreak + //
    'k1=v1' + sLineBreak + //
    '[S2]' + sLineBreak + //
    'k2=v2' + sLineBreak + //
    '[S1]' + sLineBreak + //
    'k3=v3' + sLineBreak + //
    '';
var
  lIni: TCustomIniFile;
  lSectionStrings, lValueStrings: TStrings;
  lKeyIdx: Integer;
  lSection, lKey, lValue: string;
begin
  TFile.WriteAllText('.\test.ini', C_CONTENT);

  lIni := AIniFactory('.\test.ini');
  try
    lValueStrings := TStringList.Create();
    try
      lSectionStrings := TStringList.Create();
      try
        lIni.ReadSections(lSectionStrings);
        for lSection in lSectionStrings do
        begin
          Writeln(lSection, ':');
          lValueStrings.Clear();
          lIni.ReadSectionValues(lSection, lValueStrings);
          for lKeyIdx := 0 to lValueStrings.Count - 1 do
          begin
            lKey := lValueStrings.Names[lKeyIdx];
            lValue := lValueStrings.ValueFromIndex[lKeyIdx];
            Writeln('- ', lKey, ' = ', lValue);
          end;
        end;
      finally
        lSectionStrings.Free();
      end;
    finally
      lValueStrings.Free();
    end;
    Writeln('<EOF>');
  finally
    lIni.Free();
  end;
end;

procedure Main();
begin
  Writeln('TMemIniFile:');
  Writeln;
  CheckIniClass(
    function(AFilename: string): TCustomIniFile
    begin
      Result := TMemIniFile.Create(AFilename);
    end);
  Writeln;
  Writeln('TIniFile:');
  Writeln;
  CheckIniClass(
    function(AFilename: string): TCustomIniFile
    begin
      Result := TIniFile.Create(AFilename);
    end);
end;

begin
  try
    Main();
  except
    on E: Exception do
      Writeln(E.ClassName, ': ', E.Message);
  end;
  Readln;

end.

Unter Tokyo

Code:

TMemIniFile:

S1:
- k1 = v1
S2:
- k2 = v2
S1:
- k1 = v1
<EOF>

TIniFile:

S1:
- k1 = v1
S2:
- k2 = v2
S1:
- k1 = v1
<EOF>

Unter Rio

Code:

TMemIniFile:

S1:
- k1 = v1
- k3 = v3
S2:
- k2 = v2
<EOF>

TIniFile:

S1:
- k1 = v1
S2:
- k2 = v2
S1:
- k1 = v1
<EOF>

[Bernhard Geyer]

Zitat von Schokohase:

Also damit wir alle über die gleiche Problematik sprechen:

Kannst du den Fall und dein Testprogramm auf quality.embarcader.com hochlanden/Melden?

[Uwe Raabe]

Zitat von Bernhard Geyer:

Kannst du den Fall und dein Testprogramm auf quality.embarcader.com hochlanden/Melden?

Dazu müsste aber auch eine Aussage zu dem gewünschten Verhalten gehören. Insbesondere gibt das Programm ja weder mit TIniFile noch mit TMemIniFile unter Tokyo den eigentlichen Dateiinhalt korrekt wieder. Die dritte Section (die zweite S1) wird zwar ausgegeben, aber mit dem Inhalt der ersten S1 (warum dann überhaupt), während TMemInifile unter Rio die beiden Sections zusammenfasst. Auch lässt sich in Rio mit TMemIniFile der Wert für ReadString('S1', 'k3', '') auslesen. Das Verhalten von TIniFile und das von TMemIniFile unter Tokyo erscheint mir gerade an diesem Beispiel eher zweifelhaft.

Um das Verhalten zu konsolidieren, würde ich eher eine konsistente Implementierung von TIniFile als Spezialisierung von TMemIniFile auch unter Windows vorziehen.

[Schokohase]

Für das Verhalten von TIniFile unter Windows kann Delphi nicht wirklich etwas, das ist das Verhalten der WinAPI.

Aber wie Uwe schon sagte, es bleibt zu klären, wie es denn jetzt funktionieren soll.

[jaenicke]

Zitat von Uwe Raabe:

Um das Verhalten zu konsolidieren, würde ich eher eine konsistente Implementierung von TIniFile als Spezialisierung von TMemIniFile auch unter Windows vorziehen.

Das hätte auch den Vorteil, dass TIniFile noch funktioniert, falls Microsoft die veralteten Windows 3.x APIs dafür doch mal rauswirft...

Noch sinnvoller wäre aber wohl ein optionaler XML-Adapter oder so um das ganze leicht in ein moderneres Format zu bringen...

[AJ_Oldendorf]

Da habe ich ja eine Diskussion losgetreten
Ich nutze meine Konstruktion mit TMemIniFile nur zum lesen der Datei, ich speichere darin nichts ab, habe ich mir jetzt einfach die "alte" Variante von TMemIniFile (< 10.3 Rio) nachgebaut und nutze diese Klasse. Damit geht alles wie vorher auch. Übrigens war das Verhalten von TMemIniFile in Tokyo auch das gleiche Verhalten wie in allen Versionen davor auch. Also nicht Tokyo hatte die "falsche" Implementierung sondern Rio ist die erste Version, die es "richtig" macht.
Ob richtig oder nicht, kann sich jeder selber überlegen bzw. es nutzen wie man es eben braucht

[Rollo62]

TMemIniFile basierte auf TStringList (zumindest noch vor Rio).
Hab jetzt nicht gecheckt was genau da in Rio wohl umgebaut worden ist.

Zitat:

Anmerkung: Beim Parameter Name wird nicht zwischen Groß- und Kleinschreibung unterschieden. Die Eigenschaft Values liefert also den Wert des ersten gefundenen Strings, dessen Zeichenkombination (ohne Berücksichtigung der Schreibweise) dem angegebenen Name entspricht.

Wenn ich eine Implementierung einsetze schaue ich auch immer mal kurz unter die Haube, um zu verstehen was da wohl abgeht.
Das mehrere gleiche Sections Probleme machen können sollte auch vom Einsatz der ursprünglichen TStringList als Basis klar gewesen sein.

Wenn das nun unbedingt gebraucht wird, würde ich versuchen das alte Verhalten mit TStringLists in einer eigenen Klasse oder Ableitung nachzubilden.

Rollo

[hoika]

Hallo,

Zitat:

Wenn ich eine Implementierung einsetze schaue ich auch immer mal kurz unter die Haube, um zu verstehen was da wohl abgeht.

Ich benutze OpenSSL, schaue aber nicht unter die Haube, weil es mir zu kompliziert ist

Aber Unit-Tests sollten sowas finden (wenn man überhaupt davon ausgeht, das das was schiefgehen kann...)