Unterschied TMemIniFile 10.2 Tokyo / 10.3 Rio

[Bernhard Geyer]

Zitat:

Zitat von hoika (Beitrag 1422504)

Hallo,

Zitat:

Dann hast du dich bisher auf eine fehlerhafte Implementierung verlassen.

Naja, diese Aussage lasse ich mal unkommentiert.

Ich erinnere an die Einführung von TStringList.StrictDelimiter,
um die alte, "fehlerhafte" (?) Implementierung und vor allem die Anwendungen nicht zu brechen.

Wenn TMemIniFile früher falsch implementiert war, gut (oder auch nicht).
Aber das Verhalten einer Komponente, was sie seit Äonen (*übertreib*) hat, einfach zu ändern, tztz.

Wenn man nicht davon ausgeht das sich irgendjemand auf diese fehlerhafte Implementierung verlässt, dann kann man diese m.E. Problemlos einfach so korrigieren.
Es steht ja auch an genügend Stellen das Sektionen Eindeutig sein müssen.

[Schokohase]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1422551)

Zitat:

Zitat von hoika (Beitrag 1422504)

Hallo,

Zitat:

Dann hast du dich bisher auf eine fehlerhafte Implementierung verlassen.

Naja, diese Aussage lasse ich mal unkommentiert.

Ich erinnere an die Einführung von TStringList.StrictDelimiter,
um die alte, "fehlerhafte" (?) Implementierung und vor allem die Anwendungen nicht zu brechen.

Wenn TMemIniFile früher falsch implementiert war, gut (oder auch nicht).
Aber das Verhalten einer Komponente, was sie seit Äonen (*übertreib*) hat, einfach zu ändern, tztz.

Wenn man nicht davon ausgeht das sich irgendjemand auf diese fehlerhafte Implementierung verlässt, dann kann man diese m.E. Problemlos einfach so korrigieren.
Es steht ja auch an genügend Stellen das Sektionen Eindeutig sein müssen.

Man muss aber noch dazu anmerken, dass

Delphi-Quellcode:

TIniFile

(ein reiner Wrapper der Windows-API-Aufrufe) exakt so funktioniert, wie der TE das wünscht. Diese "fehlerhafte" Implementierung wird also vom OS vorgegeben. Richtiger ist die Rio Implementierung von

Delphi-Quellcode:

TMemIniFile

, allerdings funktioniert diese eben anders als

Delphi-Quellcode:

TMemIniFile

.

[freimatz]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1422551)

Es steht ja auch an genügend Stellen das Sektionen Eindeutig sein müssen.

Wo denn?

Hier steht aber: Note: On Windows, a related object, TMemIniFile, works the same way as TIniFile, but buffers writes in memory to minimize disk access.

[Schokohase]

Zitat:

Zitat von freimatz (Beitrag 1422553)

Hier steht aber: Note: On Windows, a related object, TMemIniFile, works the same way as TIniFile, but buffers writes in memory to minimize disk access.

Für Delphi Rio solltest du in der Dokumentation zu Delphi Rio nachschlagen und da steht das nicht mehr drin.
http://docwiki.embarcadero.com/Libra...es.TMemIniFile

[freimatz]

Dann ist es also doch eine Verhaltensänderung und die ist sogar dokumentiert
Ich finde ein Update sollte kompatibel sein.

[Bernhard Geyer]

Zitat:

Zitat von freimatz (Beitrag 1422553)

Zitat:

Zitat von Bernhard Geyer (Beitrag 1422551)

Es steht ja auch an genügend Stellen das Sektionen Eindeutig sein müssen.

Wo denn?

https://github.com/SemaiCZE/inicpp/w...-specification

Wie würdest du mit WinAPI-Mitteln eine Ini-Datei mit mehreren gleichen Sektionen auslesen können?
AFAIK gibt es da keine APIs welche das können würden.

[freimatz]

Hm, guter Aspekt. Allerdings habe ich das folgende so verstanden, also ob das ginge.

Zitat:

Zitat von Schokohase (Beitrag 1422552)

Man muss aber noch dazu anmerken, dass

Delphi-Quellcode:

TIniFile

(ein reiner Wrapper der Windows-API-Aufrufe) exakt so funktioniert, wie der TE das wünscht. Diese "fehlerhafte" Implementierung wird also vom OS vorgegeben. Richtiger ist die Rio Implementierung von

Delphi-Quellcode:

TMemIniFile

, allerdings funktioniert diese eben anders als

Delphi-Quellcode:

TMemIniFile

.

Zitat:

Zitat von Bernhard Geyer (Beitrag 1422557)

https://github.com/SemaiCZE/inicpp/w...-specification

Sorry. 1. Würdest Du als Delphi-Entwickler eine Spezifikation raussuchen wenn es schon seit Jahrzehnten funktionierete? 2. Warum sollte gerade die Spezifikation die richtige sein. Die ist ja um Jahrzehnte jünger.
Ich bin eh der Meinung es gibt keine offizielle Ini-Spezifikation, also eine Norm.

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

[Uwe Raabe]

Das steht in der Doku zu TIniFile und in ähnlicher Form auch noch für Rio, insofern erstmal dort keine Änderung. Da steht aber nirgendwo, daß TMemInifile die fehlerhafte Implementierung der WinApi nachbildet und Microsoft schweigt sich in diesem Punkt eh aus und verweist lieber auf die Registry, wo das schon gar nicht mehr gehen würde.

Insbesondere steht in der Delphi Doku nirgendwo, daß mehrere Sections mit gleichen Namen existieren dürfen. Wäre es so, müsste das Verhalten in diesem Fall irgendwo erläutert werden (z.B. was passiert bei ReadSectionValues? In welche Section wird geschrieben, wenn das Item in keiner existiert?), andernfalls wäre es undefiniert. Undefiniertes Verhalten kann sich allerdings schon mal in einer neuen Version ändern.

Wie Freimatz schon sagte, gibt es keine Norm für diesen Fall, und somit kann sich Delphi auch an keine halten bzw. gehalten haben. Die Änderung des Verhaltens in Rio ist also durchaus plausibel und meiner Meinung nach auch akzeptabel, da sie eine Inkonsistenz beseitigt. Jetzt muss das nur noch irgendwer mal in die Doku aufnehmen.

[Schokohase]

Die größte Überraschung bietet sich wenn man Cross-Plattform entwickelt, denn unter Windows ist

Delphi-Quellcode:

TIniFile

ein Wrapper der WinAPI und bei allen anderen Plattformen ein Alias für

Delphi-Quellcode:

TMemIniFile

.

Und da gibt es eben ab Rio jetzt Unterschiede.