Unterschied TMemIniFile 10.2 Tokyo / 10.3 Rio

[AJ_Oldendorf]

Hallo zusammen,
einige Funktionen in TMemIniFile laufen unterschiedlich zwischen 10.2 Tokyo und 10.3 Rio.

z.B. ReadSectionValues und EraseSection

In 10.2 wird immer nur eine Section eingelesen und zurückgeliefert (ReadSectionValues), bei 10.3 Rio wird die komplette IniDatei mit allen Sections zurückgeliefert. EraseSection löscht in 10.2 auch nur eine Section, in 10.3 alle Sections in der Ini Datei.
Problem ist, dass in meiner Ini Datei der Section-Name mehrmals vorkommt. Also mehrere Sections mit dem gleichen Namen.
Gibt es dafür in 10.3 irgendwelche Funktionen, die das gleiche Verhalten wie unter 10.2 liefern oder muss ich mein QT jetzt überall anpassen? Gefunden habe ich so schnell nichts im Sourcecode von 10.3.

[Bernhard Geyer]

Dann hast du dich bisher auf eine fehlerhafte Implementierung verlassen.

Bei Inidateien gibt es die Regel:

- Jede Sektion darf nur einmal vorkommen.

[AJ_Oldendorf]

ok danke. Dann werde ich das entsprechend anpassen.

[jaenicke]

In 10.3 wurde die Performance deutlich gesteigert. Es wird nun ein Dictionary für die Sektionen usw. benutzt (was die Eindeutigkeit voraussetzt).

Windows selbst hat damals zu Zeiten der massenhaften INI-Dateien dann solche Sektionen mit Indizes versehen, z.B. [Section1], [Section2], ... und dazu gab es zumindest teilweise eine Verwaltungssektion mit der Anzahl.

[Bernhard Geyer]

Zitat:

Zitat von jaenicke (Beitrag 1422453)

In 10.3 wurde die Performance deutlich gesteigert. Es wird nun ein Dictionary für die Sektionen usw. benutzt (was die Eindeutigkeit voraussetzt).

Da diese eigentlich notwendig ist fallen jetzt manche Nutzungen "auf die Nase"

Zitat:

Zitat von jaenicke (Beitrag 1422453)

Windows selbst hat damals zu Zeiten der massenhaften INI-Dateien dann solche Sektionen mit Indizes versehen, z.B. [Section1], [Section2], ... und dazu gab es zumindest teilweise eine Verwaltungssektion mit der Anzahl.

Wenns so viele Einträge werden sollte man eh XML nehmen.

[Der schöne Günther]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1422451)

Dann hast du dich bisher auf eine fehlerhafte Implementierung verlassen.

Bei Inidateien gibt es die Regel:

- Jede Sektion darf nur einmal vorkommen.

Gibt es diese Regel wirklich? Ich konnte nie irgendwelche Regeln von Irgendjemand finden. Wikipedia sagt bspw:

Zitat:

Duplicate names
Most implementations only support having one property with a given name in a section. The second occurrence of a property name may cause an abort, it may be ignored (and the value discarded), or it may override the first occurrence (with the first value discarded). Some programs use duplicate property names to implement multi-valued properties.

Interpretation of multiple section declarations with the same name also varies. In some implementations, duplicate sections simply merge their properties, as if they occurred contiguously. Others may abort, or ignore some aspect of the INI file.

Quelle
(Hervorhebung durch mich)


Demnach wäre eine Ini-Datei mit mehreren gleichnamigen Sektionen nicht fehlerhaft. Und die Änderung von 10.2 auf 10.3 wäre eine Verhaltensänderung.

[Bernhard Geyer]

Die deutsche Wikipedia sagt das

https://de.wikipedia.org/wiki/Initialisierungsdatei

[Schokohase]

Grundsätzlich geht es (wie fast immer) um die Eindeutigkeit.

Eindeutig muss hier die Kombination aus Sektion und Schlüssel sein, oder welchen Wert würde man von dieser INI erwarten

Code:

[Sektion1]
Schlüssel1=Wert1

[Sektion2]
Schlüssel1=Wert2

[Sektion1]
Schlüssel1=Wert3

wenn man Sektion1 und Schlüssel1 abfragt?

Allerdings sehe ich (logisch) kein Problem, wenn eine Sektion doppelt auftaucht

Code:

[Sektion1]
Schlüssel1=Wert1

[Sektion2]
Schlüssel1=Wert2

[Sektion1]
Schlüssel2=Wert3

ist halt nur unübersichtlich für den menschlichen Betrachter und wäre so schöner und kompakter

Code:

[Sektion1]
Schlüssel1=Wert1
Schlüssel2=Wert3

[Sektion2]
Schlüssel1=Wert2

IMHO Könnte man beim Lesen diese zerfledderten Sektionen berücksichtigen/zulassen.

[Delphi.Narium]

Es gibt viele Implementierungen, die auch mit fehlerhaften INI-Dateien zurecht kommen oder auch fehlerhafte erstellen.

Die Definition dessen, was in INI-Dateien (für gewöhnlich) zulässig ist und was nicht, kann man hier ganz gut nachlesen:

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

https://mozilla-services.readthedocs.../confspec.html

https://tech-insider.org/windows/res...0221/1INIW.pdf

[hoika]

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.