Unterschied TMemIniFile 10.2 Tokyo / 10.3 Rio

[Bernhard Geyer]

Zitat:

Zitat von Schokohase (Beitrag 1422561)

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:

Zitat von Bernhard Geyer (Beitrag 1422566)

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

Delphi-Quellcode:

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:

Zitat von Uwe Raabe (Beitrag 1422574)

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 :-D

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

[Der schöne Günther]

Zitat:

Zitat von hoika (Beitrag 1422636)

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

Wenn man ein paar mal die Erfahrung gemacht hat fängt man tatsächlich an Unit-Tests für die Embarcadero-RTL zu schreiben. Das sollte bei einem mehrere tausend Euro teuren Produkt eigentlich der Hersteller selbst übernehmen aber naja :roll:

[hoika]

Hallo,
wenn die das mit den Unit-Tests nicht machen würden, würde gar nichts nach einem Update funktionieren.
Aber auch das Schreiben von guten Unit-Tests muss gelernt sein.

Aber schön wäre auch mal das Compilieren der IDE mit FastMM4... ;)

[Uwe Raabe]

Zitat:

Zitat von hoika (Beitrag 1422636)

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

Das würde voraussetzen, daß das gewünschte Verhalten auch irgendwo beschrieben ist. Unit-Tests finden in der Regel nur Fehler, die man schon mal hatte oder von vornherein ausschließen will. Ich bin mir ziemlich sicher, daß es für TMemIniFile bereits einige Unit-Tests gibt. Allerdings wird vermutlich keiner davon mit mehreren Sections gleichen Namens arbeiten, denn dann wäre diese Problematik ja bewusst und sowohl dokumentiert als auch konsistent implementiert. In diesem Fall ist das Problem also nicht fehlende Unit-Tests, sondern eher das fehlende Bewusstsein für dieses Szenario.

Um nochmal auf das ursprüngliche Verhalten von TMemIniFile anhand des obigen Testprogramms zurückzukommen: Die zweite Section wird zwar bei ReadSections aufgelistet, an ihren Inhalt kommt man aber weder mit ReaadString noch ReadSectionValues ran (gleiches gilt auch für TIniFile). Wozu sollte das zweite Vorkommen dieser Section denn nun überhaupt gut sein? Eigentlich müsste man bei ReadSections diese Doublette doch besser gleich entfernen (oder eine Exception werfen). Dann hat man aber faktisch dasselbe Verhalten, als ob die doppelte Section gar nicht in der INI vorhanden wäre.

In Rio wird dieses Verhalten (bewusst oder unbewusst) geändert in der Art, daß zwar die doppelte Section nicht mehr aufgeführt wird, deren Werte aber jetzt zur Verfügung stehen. Als Nebeneffekt wird beim Schreiben von TMemInifile auch noch implizit eine Normalisierung durchgeführt, bei der die doppelten Sections in einer zusammengefasst werden. Ich finde dieses Verhalten wesentlich realistischer und auch sinnvoller, wobei ich ziemlich sicher bin, daß dies nicht wirklich der Grund für diese Änderung war, sondern es sich eher um einen Nebeneffekt handelt.