Objektorientiertes TIniFile-Replacement mit Unicode-Fähigkeit

[Codehunter]

Hallöche...

Ich verwende als Konfiguration in meinen Projekten am liebsten Ini-Dateien statt der Registry. Dabei hat mich eigentlich immer gestört, dass TIniFile

1. keinen direkten Zuriff auf Einträge in der Ini bietet sondern mehr oder weniger nur eine in eine Klasse verpackte prozedurale Programmierung hat
2. Nicht wirklich eine Streaming-Fähigkeit hat, man kann nicht direkt aus Streams lesen oder in Streams speichern.
3. (zumindest in D7) nicht Unicode-fähig ist
4. Keine umkonfigurierbaren Kommentar-Einleit-Zeichen hat
5. Keine Zeilenumbrüche innerhalb von Variablenwerten unterstützt
6. Keine Funktion zum regelmäßigen automatischen Speichern hat

Darum hab ich mal ein bissi was gebastelt. Herausgekommen ist eine Klasse, die einen Großteil der Properties und Methoden von TIniFile bietet (also zu 99% kompatibel sein sollte), per Compilerschalter zwischen einer Unicode- und einer ANSI-Version umschaltbar ist und auf die einzelnen Sections und Idents direkt zugreifen kann. Ein Beispiel:

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
var
  Ini: TUniObjectIni;
begin
  Ini:= TUniObjectIni.Create('C:\Test.txt');
  try
    Ini['Section1']['Ident1'].Str:= 'Test 1';
    Ini['Section2']['Ident1'].Str:= 'Zeile 1' + #13#10 + 'Zeile 2';
    Ini['Section2']['Number'].Int:= 1234;
    Ini['Section2']['Float'].Float:= 12.34;
    Ini['Section2']['Timestamp'].DateTime:= Now;
  finally
    Ini.UpdateFile;
    Ini.Free;
  end;
end;

Am Rande bemerkt verwendet TUniObjectIni nicht das Windows-API für die Dateigeschichten (Stichwort WritePrivateProfileString) sondern arbeitet komplett mit einer StringList. Dadurch sollte der Code auch relativ leicht zu Lazarus portierbar sein. Es wird aber nur beim Laden und Speichern von Dateien auf der StringList rumfuhrwerkt, alles andere passiert komplett im Speicher.

Als Unicode-Backend verwende ich in dem Fall SynUnicode (siehe SynEdit-Komponenten bei Sourceforge), man könnte aber genausogut jede andere Implementierung einer Unicode-fähigen StringList verbauen. Die jetzige ist jedenfalls schlau genug, um sowohl ANSI- als auch Unicode-codierte Dateien zu laden. Einmal als ANSI geladene Dateien bleiben auch beim Speichern ANSI, es sei denn man fügt Unicode ein.

Schauts euch mal an und gebt mal ein bisschen Feedback dazu.

Greets
Cody

[himitsu]

Dein Ini.UpdateFile gehört aber eigentlich noch vor das Finally :zwinker:

Zitat:

Dadurch sollte der Code auch relativ leicht zu Lazarus portierbar sein.

Lazazus sollte eigentlich auch in der Lage sein, auf die WinAPI zuzugreifen. :stupid:


Ich würde dir empfehlen keine lokalen Sprachinformationen zu nutzen, also kein DateToStr oder FloatToStr usw.
Ich weiß grde nicht, ob man im D7 bei diesen Funktionen ein FormtSettings angeben kann, aber wenn, dann solltest du dieses verwenden und dann für Fließkommazahlen und Zeit-/Datumswerte ein einheitliches Format verwenden.
Sonst gibt es das bekannte Problem, daß man die INI eventuell nicht wieder auslesen kann, wenn jemand die Sprache umstellt oder man sie auf einem anderem Rechner auslesen will.

z.B. Dezimaltrenner als "Punkt" und für's Datum macht sich "yyyy-mm-dd", bzw. "yyyy/mm/dd" und "hh:mm:ss" recht gut



Nein, es müssen nicht immer #13#10 als Zeilenumbruch vorkommen.
Was mag wohl passieren, wenn z.b. nur eine #10 vorkommt?

Nja, im Grunde müßtest du eigentlich nochwas abfangen, denn was passiert wohl, wenn ein \n als Text in AValue drinsteht?
wie z.B. ein "ja\nein"

So, der nachfolgende Code normalisiert alle "bekannten" Zeilenumbrüche Windows/Linux/Mac.
Oder du behandelst alle Steuerzeichen, wie #10, #13, #0 einzeln.
#0 = \0
\ = \\
#9 = \t
#10 = \n
#13 = \r
...

Delphi-Quellcode:

procedure TUniObjectIniValue.SetString(AValue: TUniObjectIniString);
begin
  SL:= TUniObjectIniStringList.Create;
  try
    SL.Text:= AValue;
    {$IFDEF UNICODE}
      Value:= UnicodeStringReplace(SL.Text, sLineBreak, '\n', [rfReplaceAll]);
    {$ELSE}
      Value:= StringReplace(SL.Text, sLineBreak, '\n', [rfReplaceAll]);
    {$ENDIF}
  finally
    SL.Free;
  end;
end;

function TUniObjectIniValue.GetString: TUniObjectIniString;
begin
  {$IFDEF UNICODE}
  result:= UnicodeStringReplace(FValue, '\n', sLineBreak, [rfReplaceAll]);
  {$ELSE}
  result:= StringReplace(FValue, '\n', sLineBreak, [rfReplaceAll]);
  {$ENDIF}
end;

[Popov]

Zitat:

Zitat von Codehunter (Beitrag 1187627)

Hallöche...

Ich verwende als Konfiguration in meinen Projekten am liebsten Ini-Dateien statt der Registry. Dabei hat mich eigentlich immer gestört, dass TIniFile

1. keinen direkten Zuriff auf Einträge in der Ini bietet sondern mehr oder weniger nur eine in eine Klasse verpackte prozedurale Programmierung hat
   ...

...

Was dein erstes Problem angeht, so läßt es sich insoweit umgehen, als dass du dir eine eigene Unit mit vereinfachtem INI Zugang schreibst. Das habe ich auch mal vor Jahren gemacht und eine Unit geschrieben die mir einen sehr simplen Zugriff ermöglicht. Was nicht bedeuten soll, dass TIniFile kompliziert ist, aber ich hab mich des Drumherum entledigt. Wenn es dich interessiert, such mal im Internet nach EasyIniAppExe.pas. Ist die Unit eingebunden, liefert sie ein Dutzend Funktionen mit denen ich meine Daten direkt speichern kann. Der besondere Vorteil ist eine zweite Unit mit gleichen Funktionen. Tausche ich die, speichert das Programm die Daten nun in der Registry. Ein einfacher Unit-Tausch reicht.

Worauf ich hinaus will, wenn du ein permanentes Problem hast, dann löse es. So unscheinbar meine Unit auch ist, fast jedes meiner Programme enthält sie um meine Einstellungen zu speichern. Das entspannt.

[himitsu]

Ich würde aber nicht die Unit direkt austauschen.

Es gibt eine Unit/Klasse mit den Basisfunktionen.
Davon wird dann z.B. jeweils Einie für die INI und eine für die Registry abgeleitet.

Alles was nun auf diese Funktionen zugreifen will, bekommt ein Property vom Baisityp.

Nun wird man beim Erstellen/Laden des Programms die Instanz (INI oder Regisrty) erstellt und allen anderen Teilen zugewiesen, welche sie benötigen.
So kann man auch noch beim Laden entscheiden und z.B. so sein Programm entweder für eine portable oder eine lokale Speicherung einstellen.

Im Notfall gibt es eben irgendwo ein "globales" Singleton mit den Basisfunktionen, bei Welchem später eine Instanz mir der entgültigen Funktion (INI oder Registry) registriert wird und an das alle Zugriffe weitergeleitet werden.


Wenn ich eine Funktion

Delphi-Quellcode:

procedure LoadData(data: TStream);

habe, dann kann ich der geben was ich will, aber ich komm doch nicht auf die Idee in den Sourcen die Unit auszutauschen, wo TStream implementiert ist und dafür "hart" ein TStream (mit der Funktion von TFileStream) einzubauen oder eben ein TStream (mit der Funktion fon TMemoryStream) oder ....

[Codehunter]

@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.

[himitsu]

Das mit der neuen Instanz von TIniFile macht eigentlich keine großen Probleme.
Vorallem da der Speichermanager in Delphi (und vorallem FastMM seit Delphi 2006) das kompensiert.
Aber der Hauptgrund ist, daß die INI-API von Windows etwas unpracktisch ist, da sie bei jedem einezelnem Zugriff (Lesen oder Schreiben) die Datei komplett neu einlies und parst und dann wieder freigibt, da kommt es auf die Objektverwaltung von delphi nicht wirklich drauf an. :angle2:

[Popov]

@Codehunter

Meine Ini war/ist auch nie dazu gedacht gewesen bei Massenzugriffen tätig zu sein. Es spricht zwar nichts dagegen ein Objekt in einer Schleife paar hundert mal zu erstellen und wieder freizugeben, bei TIniFile wird das aber mit einem Zugriff auf eine Datei kombiniert. Sollte auch nicht das Problem sein, aber wozu dann die Datei paar hundert mal auch öffnen und schließen. Für so was war das ja auch nicht gedacht.

Trotzdem, es geht hier eher um das Konzept wie man sich das alles leichter machen kann.

PS:

Du bist nicht zufällig der Codehunter aus Spotlight.de?

[Codehunter]

Also mir ging es um meine Projekte, die konfigurationstechnisch recht umfangreich sind. Weniger die Usersettings als Daten, die temporär anfallen oder Persistenz über Programmsitzungen hinaus usw. Da kommen stellenweise sehr viele Random-Zugriffe zusammen. Selbst TRegistry scheint da zeitweise ins Straucheln zu kommen. Daher mein Ansatz, die INI komplett im RAM zu halten.

Das TUniObjectIni kann theoretisch (und sollte praktisch) als globale Instanz während der ganzen Runtime mitlaufen und nur z.B. alle 5 Minuten mal auf Platte schreiben. Was ich noch einbauen will ist Unterstützung für Namespaces innerhalb des Ini-Files und threaded Dateioperationen. Und natürlich die Vorschläge eurerseits.

Der Denkansatz ist in meinem Fall einfach komplett anders als bei der gewöhnlichen INI. Das Konzept wurde ja vor Urzeiten erfunden als PCs noch mit 640 kB RAM auskommen mussten und CPUs kaum ein Millionstel der heutigen Rechenleistung hatten. Insofern kann man heute mit dem RAM ein bisschen verschwenderischer sein und sich auch häufigere Multibyte-Stringvergleiche leisten. Ich wollte eben etwas komplett objektorientiertes. Der prozedurale Anteil ist ja eigentlich nur als Rückwärtskompatibilität zum alten TIniFile gedacht.

@Popov: Jo ich bin immernoch der selbe Codehunter wie in Spotlight. Bist du noch der selbe Popov? :)

[Popov]

Das mit dem Halten im RAM ist eine gute Idee und erhöht die Performance je nachdem ungemein, es gibt aber auch Schattenseiten. So habe ich Programme bei denen ich im laufe der Sitzung vieles einstelle usw. Beende ich das Programm regulär, ist alle gespeichert, stürzt das Programm oder ich kille es über den TM, ist alles weg.

PS: Ja, es gibt nur einen Popov. Schön sich wiedergesehen zu haben ;) Schade um Spotlight.

[Codehunter]

Über das Absturzproblem habe ich auch viel nachgedacht. Zumal ich hin und wieder wilde Experimente mit multithreaded Programmen mache, die grad am Anfang recht absturzfreudig sind. Aber sagen wir mal so: Im Vergleich zu TIniFile ist das nicht so grundlegend anders. Auch da hat der Windows-Schreibcache kackfrech alles verworfen was das zwischenzeitlich abgestürzte Programm noch hinterlassen hat. Wollte man sich da absichern, ist mir bisher nur eine halbwegs gute Lösung eingefallen: Den Teil mit der INI in einen Systemdienst verlegen und die ganzen Speichereien per Inter-Prozess-Kommunikation transportieren. Geht die Anwendung den Bach runter, dann kann der Dienst noch alles speichern. Aber machen wir uns nichts vor, dieser Weg dürfte performancetechnisch ein Krückstock sein.

Tja Spotlight, das war noch eine schöne Zeit. Irgendwie war das auch ein Relikt aus längst vergangenen Zeiten. Denn mir ist heute keine Plattform mehr bekannt, wo so ein bunt gewürfelter Haufen so locker und höflich miteinander umgehen täte. Wäre Peter damals gesundheitsmäßig nicht auf dem Zahnfleisch gegangen, dann wäre das wohl noch bis heute so. Aber schaltet man so eine Plattform einmal ab, dann erholt sich das nicht mehr. Was Delphi angeht hat die DP hier mehr als nur einen Ersatz geschaffen. Ich glaub Luckie war doch auch Spotlightianer bevor er die DP aufgezogen hat, oder? Aber was mir persönlich am meisten fehlt ist die Haustier- und Heimwerker-Abteilung gleich beim Delphiforum um die Ecke ;) Was mir auch noch gut in Erinnerung geblieben ist: Als Spotlight damals endgültig abgeschaltet wurde hatte ich 9.993 Posts auf dem Zähler. Peter hat damals glaub ich den 10.000er Club kleine Geschenkchen gemacht...

[Popov]

Nun ja, INI ist eigentlich sowieso schon veraltet, aber ich hab den Schritt zu XML auch noch nicht geschafft. Dazu ist INI einfach zu einfach.

Was Spotlight angeht, lag das Problem vor allem an Peter. Als er mit dem Forum anfing, hat man Forensoftware genutzt, zuletzt hat sich die Boardsoftware durchgesetzt. Und da stand er mit einer proprietären Software die anfing Geld für Pflege zu kosten. Er hätte den nächsten Schritt wagen und mit einem vBulletin Forum neu anfangen sollen. Das alte Forum Readonly. Die Leute wären schon geblieben. Auch bei einem anderen Punkt hat er nicht den Sprung in die Neuzeit geschafft: einfach Moderatoren bestimmen die nach dem Rechten gucken und das Forum wäre ein Selbstläufer. Dazu hat er den Leuten wohl nicht genug vertraut. Nicht alles selbst kontrollieren müssen, bzw. einen Angestellten dafür abstellen. Das hätte er auch aus einem Krankenbett managen können. Zuletzt hat er sich mehr Arbeit gemacht als nötig war. Geendet hat es mit eine Art Burnout.

[Codehunter]

Ich habe sogar einige Zeit XML zur Konfiguration genutzt. Für Client-Server-Kommunikation nutze ich bis heute SOAP, was ja eine Unterart von XML ist. Doch dann bin ich zu der Meinung gekommen (wird jetzt ein bisschen weltfremd klingen) dass sich XML langfristig gar nicht durchsetzen wird.

Warum? Zum einen ist die Parserei zu aufwendig. Klar gibt es MSXML aber das will einerseits nicht jeder nutzen, aus verschiedensten Gründen (Lizenzpolitik, nicht X-Plattform etc.). Eigene Parser schreiben ist irgendwie hirnrissig. Third-Party-Parser sind meist kostenpflichtig und teuer.

Zum zweiten produziert XML Unmengen Overhead. Es kommt ja nicht von Ungefähr dass die großen Softwareschmieden ihre XML-Metadaten nochmal in ZIP umverpacken. Ich nenne da nur OOXML und Corel CDR als Beispiele. Microsoft hat fast 10 Jahre gebraucht bis sie in ihrem eigenen Office den hauseigenen Standard OOXML vollständig unterstützt haben. Das spricht in meinen Augen Bände.

Drittens zeigt sich schon langsam ein Trend gegen XML. Da wäre z.B. das W3C, das sich zuletzt bei HTML5 gegen eine Weiterentwicklung von XHTML und für ein Superset von HTML4 entschieden hat. Dann hat SOAP mit REST einen Konkurrenten bekommen, der technisch näher an INI als an XML dran ist. Auch erschließt sich mir nicht, warum man für seine Konfigurationsdaten ein Austauschformat wie XML verwenden sollte. Außer der eigenen wird sich in den meisten Fällen keine andere Software mit den Daten befassen.

Daher denke ich, kann man ruhig bei INI bleiben für Konfig-Zwecke. XML sollte man in neuen Projekten unter Umständen schon gar nicht mehr einsetzen.

Tja und Spotlight... Ich fand Spotlight gerade wegen der Baumstruktur gut. Das war auch sowas wie eine Hausmarke. vBulletins und phpBBs findet man wie Sand am Meer, die meisten sind auch noch schludrig aufgesetzt und nie über das Standard-Theme hinaus gekommen. Möglicherweise war die Baumstruktur in mancherlei Punkten sogar übersichtlicher als die Brettstruktur.

Was ich nie verstand: Peter hatte auf der SL-Startseite ein wirklich ansprechendes Layout, doch kaum dass man in die Unterseiten ging kam der dicke Stilbruch und man fühlte sich optisch zu Netscape-Browser und HTML3 zurückversetzt.

Problematisch war wohl die proprietäre Perl-Software mit der hoffnungslos und ersatzlos veralteten Datenbank - Sybase wenn ich mich recht erinnere. Peter war wohl irgendwann der Programmierer abhanden gekommen der das Ding aus einer gekauften Lösung weiter entwickelt hatte und so musste er sich notgedrungen selbst damit befassen.

Ich hatte ihm sogar mal angeboten, die Software kostenlos in PHP und MySQL neu zu schreiben, aber das kam wohl zu spät, da war der Burnout schon in vollem Gange. Oder er hat nicht geglaubt dass man das in 4 Wochen machen kann mit heutigen Frameworks. Obwohl er gesehen hatte dass ich mit "Twilight SL" damals schon einen moderneren Reader für sein veraltetes Forum geschrieben hatte - in anderthalb Wochen.

Die Sache mit den Moderatoren hab ich genauso gesehen und ihm auch mehrfach vorgeschlagen. Aber er hat es nie als ernsthafte Möglichkeit in Erwägung gezogen. Ich denke, weil er die Nase viel zu tief in Gesetzen und Paragraphen stecken hatte und überall nur noch Abmahnungen und Anwälte gesehen hat. Vermutlich hatte er selbst keinen guten, internet-fähigen Hausanwalt, sodass ihm zwei oder drei Abmahnungen richtig viel Geld gekostet haben. Tatsächlich war es aber schon damals so dass er höchstens als Mitstörer haftbar gmacht werden konnte da die Inhalte ja nachweislich nicht von ihm selbst stammten.

Und so ist die vielleicht beste deutschsprachige Community ganz jämmerlich zum Teufel gegangen. Denn die Leute die da waren, das war ein unschätzbares Kapital und Peter hats nach meiner Ansicht nicht erkannt.

[Codehunter]

So, Version 1.0.1 ist fertig. Ich hab mal eure Anregungen mit einfließen lassen. Steuerzeichen im String werden jetzt besser escaped und für die Typkonvertierungen wird jetzt TFormatSettings verwendet. Eine neue Idee von mir ist noch dazu gekommen: Die FormatSettings können jetzt als Metadaten mit in die INI gespeichert werden. So kann man sicher sein dass die Datei auf jedem System wieder richtig ausgelesen wird, egal welche Regionaleinstellungen man gemacht hat. Kleinere Bugfixes hab ich auch noch gemacht, das eine oder andere Memleak raus und einige Inkonsistenzen beim Thema Unicode.

Um die Metadaten zu verwenden kann man entweder den optionalen boolschen Parameter im Konstruktor angeben (TUniObjectIni.Create(Filename, UseMetadata) oder aber nachträglich die Eigenschaft HandleMetaData:= TRUE setzen. Letzteres wirkt sich aber logischerweise nicht auf den Dateiinhalt aus, der bereits durch den Konstruktor geladen wurde, sondern erst beim Speichern.

[Codehunter]

Update: Bugfix für das wilde Duplizieren von Sections in der INI.

[Codehunter]

Update: Property Section.Ident.Default hinzugefügt.

[himitsu]

Du solltest den Thread mal verschieben lassen. (einfach auf den Meldebutton bei einem der Posts hier klicken und 'nen Mod darum bitten)

z.B. ins Projekte-Forum
Dort darfst du deinen ersten Post unbegrenzt editieren und kannst somit immer die aktuelle Version/Datei gleich (übersichtlich) am Anfang positionieren.

[Codehunter]

Mal schauen... Ich denke ein richtiges Projekt ist es noch nicht. Es gibt noch Bugs und konzeptionelle Ungereimtheiten. Außerdem fehlt noch ein richtiges Demo-Projekt. Wenns soweit ist kann ich ja einen neuen Eintrag bei den Projekten machen und den Thread hier schließen. Bis dahin wäre ich über das ein oder andere Feedback hier dankbar.

[TiGü]

Zitat:

Zitat von Codehunter (Beitrag 1187627)

Dabei hat mich eigentlich immer gestört, dass TIniFile[LIST=3][*] keinen direkten Zuriff auf Einträge in der Ini bietet sondern mehr oder weniger nur eine in eine Klasse verpackte prozedurale Programmierung hat

Am Rande bemerkt verwendet TUniObjectIni nicht das Windows-API für die Dateigeschichten (Stichwort WritePrivateProfileString) sondern arbeitet komplett mit einer StringList. Dadurch sollte der Code auch relativ leicht zu Lazarus portierbar sein. Es wird aber nur beim Laden und Speichern von Dateien auf der StringList rumfuhrwerkt, alles andere passiert komplett im Speicher.

Gab es TMemIniFile in Delphi 7 noch nicht?
http://docwiki.embarcadero.com/Libra...es.TMemIniFile

[Popov]

Ich hab mir den Code zwar nicht näher angeguckt, aber ich glaube Codehunter geht es im speziellen um Unicode-Fähigkeit.

[Codehunter]

Ja Unicode und echte Objektorientierung ohne Abhängigkeit vom WinAPI. Prozedurale Programmierung schön und gut, aber ist auch nicht mehr das gelbe vom Ei...

Darüber hinaus haben sich inzwischen ein paar Features ergeben, die über T(Mem)IniFile hinaus gehen. In meiner aktuellen Beta z.B. ein Changed-Property sodass man erkennen kann ob der Inhalt modifiziert wurde.

[TiGü]

Zitat:

Zitat von Codehunter (Beitrag 1189028)

Ja Unicode und echte Objektorientierung ohne Abhängigkeit vom WinAPI.

Was heißt denn jetzt Unicode-Fähigkeit?
Das Unicode-Strings ins Ini-File abgespeichert werden?
Das ist in TMemIniFile (ab Delphi 2009) gegeben, es wird mit den Typ String gearbeitet.

Auch verwendet TMemIniFile nicht die WinAPI-Funktionen GetPrivateProfileString/WritePrivateProfileString sondern setzt auf hierarchische String-Listen.

Bitte bei Gelegenheit einen Blick auf die Doku und/oder Code werfen.

Vielleicht reicht es schon wenn du deine Klasse davon ableitest?!

[Codehunter]

Das mag ja alles richtig sein. Aber zum ersten solltest du mal einen Blick auf meine Delphi-Version werfen und zum zweiten den ganzen Thread durchlesen. Ich halte T(Mem)IniFile für strukturell in manchen Szenarien schlichtweg ungeeignet.

Unter ähnlichen Voraussetzungen ist damals auch TVirtualTreeView entstanden. Da gabs bestimmt auch einige, die der Ansicht waren, der Standard-VCL-Treeview wäre vollkommen ausreichend. Es gibt aber immer Anwndungsfälle, wo TVirtualTreeview dem TTreeView haushoch überlegen ist.

Schaut euch den Quelltext wirklich mal praktisch an und vorallem nicht den Teil den ich nur zur Kompatibilität mit TIniFile eingebaut habe sondern den objektorientierten Teil.

Delphi-Quellcode:

with TUniObjectIni.Create('C:\Test.ini') do begin
  try
    Sections['TheSection']['TheIdent'].Str:= 'ABC';
    Sections['TheSection']['TheIdent'].Int:= 123;
    Sections['TheSection']['TheIdent'].DateTime:= Now;
    {....}
  finally
    Free.
  end;
end;

[Popov]

Man sollte nie fragen wozu etwas gut ist.

Ich hatte mit einem anderen Delphianer mal vor eine Datenbank auf Grundlage der Ini zu entwickeln, so just4fun. Es ist natürlich klar, dass die Ini dazu nicht taugt, aber es wäre schon lustig gewesen mit den Datenbankkomponenten auf eine Ini zuzugreifen. Die Verwaltung hätte ich schon hinbekommen, aber mir fehlte das Wissen bezüglich der Schnittstelle, was ich vor allem für ein anderes Projekt brauchte.

Damals, als kein Schwein noch etwas von PHP oder MySQL hörte, bzw. man seine Seiten statisch ins Web stellte, hat mich einer gebeten mir was für statische Seiten auszudenken. Ich hab das auch in einem Projekt umgesetzt und es klappte sehr gut, nur eben ohne die Datenbankkomponenten. Die Begeisterung anderer Programmierer hielt sich in Grenzen: die vorhandenen Datenbanken sehr gut sind und zurzeit besteht kein Bedarf an etwas neuem.

Übrigens, was ich da programmiert habe sah in etwa so aus:

Code:

<db=name>Anna</db> <db=nachname>Wegener</db>

Browser ignorieren Tags die sie nicht kennen. Jede Html-Seite ein Datensatz. Die Ausgabe wäre

Code:

Anna Wegener

. Die Daten sind in der Webseite versteckt und man könnte sie jederzeit auslesen und ändern. Heute ist das nichts, aber damals wurden damit paar hundert Artikel verwaltet.

[Codehunter]

Sagen wir mal so: Wenn man es mal auf die Basics runterbricht, dann ist eine INI jetzt schon eine Datenbank. Theoretisch könnte man auf Basis meiner Klasse sogar jetzt schon transaktionale Zugriffe realisieren denke ich. Aber ganz ehrlich: Eine INI halte ich nicht für eine gute Basis für eine Datenbank.

Aber wenn ich eines gelernt habe: Es ist nicht immer schlecht, wenn man gelegentlich ein Rad neu erfindet. Denn nur weil die Mehrheit das alte Rad schon für perfekt hält, warum nicht überlegen ob es tatsächlich so ist. Man kann sich dabei auch irren. So oder so lernt man was dabei :-)

[Codehunter]

Update: Bösen bösen Bug entfernt, wodurch es nicht möglich war, Boolsche Werte als FALSE (="OFF") zu speichern, es kam immer ein "ON" in der Ini an. Genauer gesagt war der Fehler im Parsing der Metadaten zu finden.

[Codehunter]

Update: Noch so einen Bösling entfernt, der bei Strings mit Zeilenumbrüchen endlose Backslash-Ketten produzierte.

[Codehunter]

Update: Verbesserungen bei Values mit Steuerzeichen (Zeilenumbrüche etc.)