@Popov:
Ich hab mir auch mal EasyIniAppExe.pas angeschaut. Du wirst lachen, ich habe lange Zeit etwas ganz ähnliches benutzt. Im Prinzip ist deine Lösung recht einfach und macht den Code im Hauptprogramm ähnlich schlank wie meine Lösung. Der große Unterschied dürfte meiner Ansicht nach darin liegen, daß bei deinem Code bei jedem Lese- und Schreibzugriff eine neue Instanz TIniFile erzeugt wird. Wenn die Konfiguration recht umfangreich ist dürfte das irgendwann zu Dateikuddelmuddel führen, Stichwort Schreibcache.
Ich wollte vorallem eine Konfiguration, die ausschließlich im Speicher vorgehalten wird und nur bei einem UpdateFile oder SaveToFile wieder in strukturierte Textdaten umgewandelt wird.
@Himitsu: Danke für den Hinweis mit den lokalen Spracheinstellungen. Das halte ich auch für wichtig. Ich habe schlichtweg nicht daran gedacht. TFormatSettings gibt man da einfach als zusätzlichen Parameter an, sind overloaded Funktionen.
Das mit den codierten Zeilenumbrüchen ist vollkommen richtig, war mir schon bewusst, aber noch nicht dazu gekommen.
Mir ging es bei der
Unit bzw. Klasse vorallem um das Prinzip, eine völlig eigenständige Implementierung von TIniFile mit neuem Designkonzept. Schließlich ist die originale Implementierung vom Ansatz her seit Delphi 1 nicht großartig verändert worden.
Man stelle sich ein Programm vor, das ein paar Hundert oder Tausend Settings speichert und lädt. Das ist mit meinem Konzept, denke ich, effizienter und man kann den Zeitpunkt des Dateischreibens auf Platte steuern, was mit der
Unit von Popov nicht geht.
Mir ist auch irgendwann mal aufgefallen, das selbst bei einer einzigen TIniFile-Instanz bei vielen Random-Read-Write-Zugriffen irgendwann der Speicherinhalt durcheinander kam wenn man zwischenzeitlich ein Flush gemacht hat. Das ist mir bei meiner
Unit noch nicht passiert.