INI, Registry, ThaXML-Library was ist sinnvoll

[Luckie]

Zitat von sakura:

Zitat von Luckie:

Ich würde Ini-Dateien wählen, da sie keine Baumstruktur erfordern und man für die Registry wieder einen Deinstaller mitliefern müsste.

Wenn die Ini-Dateien irgendwo in den UserApp-Daten liegt, dann ist da hoffentlich auch ein Deinstaller dabei, wer will schon, dass die HDD über Zeit mit solchen Müll zugestopft wird...

Das sieht Raymond Chen aber anders: What do I do with per-user data when I uninstall?.

[Hansa]

Wer ist Raymond Chen ? Egal, ich sehe das jedenfalls anders als der. Soll etwas deinstalliert werden, dann muss auch alles weg, was VOR der Installation noch nicht da war. Wozu soll man da irgendwelchen Müll zurücklassen, den keiner mehr braucht ? Selbst wenn jemand was temporär deinstalliert, um es wieder neu zu installieren, seine Fenster wild verschoben hat und diese genauso wiederfinden möchte, dann soll er sich die INI in der das steht vorher sichern, deinstallieren/installieren und die gesicherte INI zurückkopieren und fertig. Jetzt kommen die M$-"Richtlinien" ins Spiel. Wo sollte die INI hin ? Bei mir liegt die genau in dem Odner, wo auch das Programm ist. Und das ist normalerweise einfach ein Verzeichnis. Erkläre mir mal einer, worin der Vorteil besteht, das Ganze in einem Ordner mit ellenlangem Namen zu speichern, den später eventuell keiner mehr findet. Von der Registry ganz zu schweigen. Anders siehts aus, sofern die Einstellungen Windows-benutzerdefiniert gespeichert werden sollen. Sollte dazu mal ein Bedarf entstehen, dann hätte ich immer noch eine INI beim Programm und in der wäre ein Bool-Eintrag, ob benutzerdefiniert gespeichert werden soll, oder nicht. Im ersten Fall würde ich dann im Benutzerverzeichnis speichern, im zweiten eben nicht. Ich brauche so keinen Deinstaller, weil zur Deinstallation einfach nur ein Ordner gelöscht werden muss.

Also : erkläre mir endlich mal einer den Sinn solcher Mickysoft-Vorgaben. Bei > 50 User siehts allerdings anders aus. Oder in sicherheitsrelevanten Bereichen. Aber auch da ist das Windows-Rechtesystem eher lächerlich und wird sowieso nicht richtig verwendet. Siehe Liechtenstein.

[Luckie]

Zitat von Hansa:

Aber auch da ist das Windows-Rechtesystem eher lächerlich und wird sowieso nicht richtig verwendet. Siehe Liechtenstein.

Das Windows Rechtesystem ermöglicht wesentlich feinere Rechtevergaben als es unter Lunix möglich ist. Allerdings wird es dadurch auch wesentlich komplexer, so dass nicht alle Möglichkeiten ausgeschöpft werden. Und was Liechtenstein damit zu tun hat, verschließt sich mir irgendwie.

[Hansa]

Eben, es ist IMHO viel zu kompliziert, um praxisnah eingesetzt werden zu können. Warum soll man sich an solch praxisferne "Richtlinien" denn überhaupt halten. Z.B. beim Delphi-Styleguide ist das ganz anders. Da sind die Vorteile ganz klar zu erkennen und mit etwas Disziplin (oder auch Hilfsmitteln wie GExperts etc.) auch gut umzusetzen. Der Chemiker soll jedenfalls besser bei seinen INIs bleiben. Schließlich kann man die auch schnell mal editieren. Ich sehe darin einen Vorteil und keinen sicherheitskritischen Nachteil.

[Chemiker]

Hallo Luckie,

ich sehe das genauso wie sakura und Hansa, wenn das Programm deinstalliert wird sollte auch alles aufgeräumt werden. Also ich kann Raymond Chen auch nicht beipflichten. Also ich habe es noch nie erlebt, dass ich ein Programm deinstalliert habe, dass ich anschließend noch Daten von diesem Programm brauche die irgendwo in der Regitry oder als INI – Dateien im USER – Verzeichnis nicht mit deinstalliert wurden. Im Gegenteil, es ärgert mich wenn meine Festplatte mit irgendwelchen Müll vollgestopft wird, ich vermute Dir geht es genauso.

Zitat:

ermöglicht wesentlich feinere Rechtevergaben

in Linux bin ich jetzt nicht so der Profi, aber bei Windows hängt das doch sehr stark von der jeweiligen Windows – Version ab. Ich habe z.B. erhebliche Schwierigkeiten mit XP – Home, wenn ich versuche eine Komponente unter ein eingeschränktes Benutzerkonto zu installieren.

Unter XP – Pro ist dies natürlich möglich.

Bis bald Chemiker

[Hansa]

Chemiker, das Schlimme ist, es geht mit der Registry noch schlimmer. Das Tha-XML Dingens kenne ich nicht, sieht allerdings wegen XML schon komplizierter aus als eine INI. Ein End-User hat durch XML keinerlei Vorteile, sofern aber sogar die Registry wegen Fensterpositionen etc. verwendet wird, hat er sogar Nachteile zu befürchten. Siehe die Ratschläge von Microsoft. Ja, wie Herr Chen empfiehlt, die Registry ruhig zuzumüllen. 8) Oder sowas :

habe mal bei mir geguckt in dem von Microsoft empfohlenen Verzeichnis. Wo steht da was ? Z.B. das hier :

C:\Dokumente und Einstellungen\User3\Anwendungsdaten\Free Download Manager\Update

Unter Vista sieht es zudem noch völlig anders aus. MS hat also für gewaltige Planungsunsicherheit gesorgt. Der User wird genötigt, vom Arbeitsplatz aus, mindestens 5 Schritte zu machen, um irgendeine Datei zu finden. Zuerst muss er das Laufwerk wissen und auswählen und dann noch 4 mal in ein Unterverzeichnis wechseln, um da dann endlich die richtige Datei suchen zu dürfen. Wenn solcher Schwachsinn auch noch propagiert wird, dann gute Nacht. Weitere Konsequenzen : wie soll man mit Registry, User-Verzeichnis usw. eine lauffähige CD-Demo-Version herstellen ? Eingriffe ins System (Registry, Abspeichern von Dateien an nicht klar definierten Orten usw.) ? Da spielen sogar DAUs wegen schlechter Erfahrungen mittlerweile nicht mehr mit. Die installieren im Zweifelsfall einfach nichts mehr !

[Chemiker]

Hallo Hansa,

Unter:

ThaXML-Library

ich habe das Tut. nur gelesen, kann also keine Aussage über die Qualität dieser Methode abgeben.


Bis bald Chemiker

[Hansa]

Nene, damit lockt mich keiner hinter dem Ofen hervor. Klar, dass die INIs "nur" eindimensional sind. Aber ich brauche doch keine Baumstruktur, um irgendwelche Fensterkoordinaten zu speichern, oder feste Werte. Um dann noch dafür zu sorgen, dass wirklich alles bei Deinstallation weg ist ? Nochmals : wo liegt der Vorteil ? Wann / Wo / Wofür ist es nötig, tatsächlich für einzelne Benutzer separate Einstellungen zu speichern ? Wie gesagt, ist das notwendig, dann lasse ich mir ja noch ein benutzereigenes User-Verzeichnis gefallen. So etwa kann schon Sinn machen. Die Registry niemals ! Und XML ist für den Zweck IMHO auch überdimensioniert.

Wie hat sich negaH letzens geäüßert ? Er sei verknöchert oder wie ? Tja, vielleicht trifft das auf mich ja auch zu. Ich lasse die INI selber werkeln (zumindest für Fensterkoordinaten usw.).

Delphi-Quellcode:

procedure Tfrm.FormShow(Sender: TObject);
var FensterIni : TIniFile;
begin
  inherited;
  FensterIni := TIniFile.Create(FensterDateiName);
  try
    Left   := FensterIni.ReadInteger(Name,'Left',Left);
    Top    := FensterIni.ReadInteger(Name,'Top',Top);
    Width  := FensterIni.ReadInteger(Name,'Width',Width);
    Height := FensterIni.ReadInteger(Name,'Height',Height);
  finally
    FensterIni.Free;
  end;
end;

procedure Tfrm.FormClose(Sender: TObject; var Action: TCloseAction);
var FensterIni : TIniFile;
begin
  inherited;
  if not CDStart then begin
    FensterIni := TIniFile.Create(FensterDateiName);
    try
      FensterIni.WriteInteger(Name,'Left',Left);
      FensterIni.WriteInteger(Name,'Top',Top);
      FensterIni.WriteInteger(Name,'Width',Width);
      FensterIni.WriteInteger(Name,'Height',Height);
    finally
      FensterIni.Free;
    end;
  end;
  Action := caFree;
end;

Ausgeliefert wird das Programm mit einer Standardoberfläche. Werden an den Fensterkoordinaten Änderungen vorgenommen durch verschieben etc., dann werden sie direkt beim Schließen des Formulars gespeichert. Ab dann gelten diese. Und beim erneuten Öffnen eben neu ausgelesen. An der INI-Datei selber wird nichts geändert, die eventuellen Änderungen verwaltet sie selber. Hat sich jemand total verhauen, dann wird sie eben gelöscht und der fängt neu an. Man hätte allerdings immer noch den Ausweg, das einfach zu editieren. Wo die Datei liegt ist dem Programm dabei egal (kann auch User-Verzeichnis sein). Sofern tatsächlich jede Koordinate jedes Buttons/Labels usw. gespeichert werden müsste, dann wäre eine XML wohl doch etwas übersichtlicher. Eventuell könnte man allerdings auch verschiedene INIs zu Unterscheidung verwenden. Aber so etwas würde auch den Support quasi vernichten. Wie soll man denn dann jemand erklären, dass er mal sagen soll, was die Original-CheckBox rechts unten, die mittlerweile mitten im Form, steht anzeigt ? Betrachtet die User einfach als Kinder, die erst dann hören, wenn sie sich die Finger verbrannt haben.

[Luckie]

Zitat von Hansa:

procedure Tfrm.FormShow(Sender: TObject);

schlechte Idee, das im OnShow zu machen, da dieses Ereignis jedesmal beim Anzeigen aufgerufen wird. Dein Fenster wird also, wenn es verschoben ist, beim Anzeigen immer wieder auf die Startposition zurückspringen.

[Hansa]

Wieso soll da was zurückspringen ? Das caFree im OnClose sagt fast alles. Nämlich, dass die Forms nach dem Close weg sind. Vorher werden noch die dann aktuellen Koordinaten gespeichert. Sie werden zur Laufzeit erzeugt und angezeigt. Vorher guckt sie eben im OnShow zuerst noch in INI nach, wo sie zuletzt auf dem Bildschirm zu finden war. Sie kann also unmöglich wild in der Gegend rumspringen.