Speichern der Einstellungen wie umsetzen

[Sebastian Beyna]

Hallo

Mein Problem ist ich möchte die Einstellung(sprich Fenster größe, Checkboxen usw.) Userbezogen aus meinem Programm abspeichern so das diese beim erneuten Starten der Progs bestehen bleiben. Aber nicht jeder User hat das recht alle Einstehllungen zuändern sondern bei manchen hat nur der Admin dieses Recht diese zuändern und andere wiederum sind Gruppenspezifisch Einstehllungen welche bei einer bestimmten Gruppe gleich sein müssen. Bisher werden diese Einstellungen noch in der Registry gespeichert durch eine Komponente Namens oxPersist diese Komponente möchte ich aber aus dem Prog entfernen weil sie auch Einträge macht mit welchen ich nichts anfangen kann(also Müll ist). Momentan schwanke ich zwischen der Auslagerung dieser Informationen in eine INI-Datei oder in eine Datenbank. Wer kann mir dazu einen kleine Denkanstoss in die richtige Richtung geben.

Hochachtungsvoll: Sebastian Beyna

[Andreas Käding]

Hallo Sebastian!

Also ich versteh noch nicht ganz warum Du die Sachen nicht mehr in der Registry hinterlegen willst. Gerade für Probleme wie Du sie hast (unterschiedliche Rechte und Sichtbarkeit) bietet sich das eigentlich an. In meiner Anwendung hinterlege ich auch Datenbankeinstellungen, Fenstergrößen, Positionen, Fontname und den Windowstate in der Registry.
Die Fenstereinstellungen lese ich beim FormCreate aus und schreibe Sie beim Hide wieder zurück. Das klappt absolut problemlos.
Die Datenbankinformationen lese ich beim Application.Initialize. Geschrieben werden diese durch das Installationsprogramm. Durch Deinen Delphi - Code kannst Du auch steuern, ob die Informationen nur gelesen oder auch geschrieben werden können.
Bei meinen Forms habe ich es zum Beispiel so gemacht, dass die Fenster alle per Objectinspector ihre Standardeigenschaften verpasst bekommen. Den Registryzugriff habe ich dann so gemacht, dass wenn dort keine Informationen zu einem Fenster vorhanden sind die Standardwerte benutz werden. So habe ich zum Beispiel die Möglichkeit über eine DEfaultfunktion in der Anwendung den Fensterschlüssel zu löschen. Anschließend hat man wieder die Standardeigenschaften.
Ansonsten hinterlege ich aber auch noch bestimmte Informationen z.B. Schaltflächenbeschriftungen, Anzahl von Editierfeldern usw. in einer Datenbanktabelle. Diese können über einen Optionendialog in der Anwendung editiert werden.
Wenn Du zu all dem Fragen hast kann ich Dir sicher weiterhelfen.

m.f.G. Andrea

[Christian Seehase]

Hallo Zusammen,<br>
<br>
ausserdem ist es gemäß MS sogar Pflicht die Daten in der Registry<br>
abzulegen.<br>
(Vornehmlich unter HKEY_CURRENT_USER).<br>
Wenn ich den Link auf das entsprechende Whitepaper wiedergefunden habe,<br>
werde ich ihn auch noch posten.<br>
Da wird dann auch noch beschrieben, dass die Policies zu beachten sind, usw.<br>
<br>
Ciao<br>
Chri

[Wolfgang Roller]

Hallo Sebastian,<p>
obwohl ich kein Freund des in die Registry-Schreibens bin, frage ich mich warum du nicht die Klasse TRegistry verwendest. Sie soll das Lesen und Schreiben in die Registry relativ einfach machen. Ich hab's noch nicht ausprobiert, da ich der Meinung bin, daß nur Information in die Registry soll, die auch andere Applikationen betrifft. Ich verwende die Klasse TInifile um alle Informationen meiner Applikationen in einer Ini-Datei zu speichern. Ich speichere die Daten auch Benutzer-spezifisch in dem in den Section-String auch den Benutzernamen mit einbinde. Ab einer gewissen Anzahl von Benutzern ist dieses Verfahren natürlich nicht mehr tragbar, dann würde ich eine DB verwenden.<br>
Die Inifile liegt im selben Verzeichnis wie die Exe. Wird das Programm nicht mehr benötig, so genügt es das Verzeichnis mit der Exe zu löschen. Keine großartige Deinstallation und kein Schrott in einer immer größer werdenden Registry. Genauso einfach ist die Installation. Exe in ein Verzeichnis kopieren und starten. <p>
Gruß<p>
Wolfgang Rolle

[Falk Prüfer]

Hallo,

Wenn es um das Speichern Nutzerspezifischer Informationen einer DB-Anwendung geht, dann würde ich es in die "normale" Nutzerverwaltung der Applikation integrieren - also in der DB ablegen. <br>
Ein Inifile scheidet eigentlich aus, da jeder der halbwegs mit einem Computer umgehen kann in der Lage ist ein Inifile mit einem Texteditor zu bearbeiten. <br>
Die Registry ist das schon etwas günstiger, da ich dort mit Hilfe der Windows-Policies zumindest den Zugriff darauf einschräncken kann.

Gruß Fal

[Wolfgang Roller]

Hallo,<p>
Falk hat natürlich Recht. Sobald es um Daten geht, die nicht jeder sehen darf, scheidet eine Ini-Datei aus. Ich habe bei Sebastians Beitrag auch den Aspekt, daß nur der Admin bestimmte Sachen ändern können soll, übersehen. <p>
Wenn es bei einer Applikation darum geht, daß sie sich merkt welche Fenster mit welcher Größe beim Beenden geöffnet waren um sie beim Neustart genauso wieder darszustellen, dann ist die Ini-Datei die einfachste Möglichkeit. Ich habe mir inzwischen einige Formular-Klassen definiert, die ohne weiteres zutun schon mal beim Zerstören ihre Position und Größe in die Ini-Datei schreiben. Ich leite neue Formulare also nicht mehr von TForm ab, sondern von meinen eigenen Klassen, die natürlich auch auf TForm basieren.<br>
Zum Wiederherstellen beim Neustart reicht die Position und die Größe nicht aus, sondern es müssen weitere Parameter gespeichert werden. Je nach Formularinhalt ist diese Information aber ganz unterschiedlich und auch von unterschiedlichem Umfang. Mit einer Ini-Datei läßt sich das Problem leicht lösen, man erzeugt einfach eine entsprechende Section. Bei einer Datenbank muß man dafür sorgen, das man die entsprechenden Tabellen bzw. Tabellen-Spalten zur Verfügung hat.<p>
Sobald die zusätzliche Information, die die Formulare sich in der Ini-Datei merken, sicherheitsrelavant ist, geht's natürlich auch nicht mehr. Bei einem Börsenprogramm könnte sich ein Fenster die angezeigten Wertpapiere merken. Benutzer A will aber nicht, daß Benutzer B sehen kann mit welchen Wertpapieren er sich beschäftigt. Dann bleibt entweder nur eine DB oder vielleicht noch die Verschlüsselung. Bei der Verschlüsselung kann allerdings Benutzer B den Benutzer A ärgern in dem er in der Ini-Datei irgendwas ändert und beim Benutzer A kann das Programm beim Neustart den Zustand nicht korrekt herstellen. Oder noch schlimmer: Programmierer C hat diesen Umstand nicht bedacht und das Programm crashed bei jedem Start.<p>
Gruß<p>
Wolfgang Rolle

[Christian Seehase]

Hallo Zusammen,<br>
<br>
@Wolfgang:<br>
Wie Du in Deinem letzten Absatz schon so schön beschreibst, gibt es wohl doch Gründe die Registry zu benutzen.<br>
(zumal sie genau dafür gedacht ist, und als Ablösung der INI Dateien seit W95 dienen soll )<br>
Besonders das Problem mit benutzerspezifischen Einträgen bekommt man durch Nutzung von<br>
HKEY_CURRENT_USER gut in den Griff.<br>
Eine neue Section enspricht schlicht einem neuen Key.<br>
Ob ich die Datenstruktur nun auf eine Ini oder die Registry abbilde spielt also eigentlich nicht so<br>
die grosse Rolle.<br>
Nicht umsonst existiert die Komponente TRegistryIniFile.<br>
Sicher hast Du Recht damit, wenn Du sagst, dass sich ein Programm leichter entfernen lässt,
wenn nur das Verzeichnis samt INI gelöscht werden soll.<br>
<br>
@Falk:
Mit den Policies ist dass ja so eine Sache, denn wenn die Programme die<br>
man aufruft diese nicht beachten...<br>
Schliesslich kann ich mir ja einen anderen Registry Editor nehmen, der sich<br>
um die Policies nicht kümmert.<br>
<br>
@Sebastian:
Welchen Admin meinst Du eigentlich? Den Admin des Programmes oder des Rechners?<br>
<br>
Wenn u.A. solche Dinge wie Fensterposition und -grösse gespeichert werden<br>
sollen, muss man beim Restore auf jeden Fall darauf achten, dass sich <br>
die Auflösung inzwischen nicht geändert hat, bzw. ggf. die Werte anpassen.<br>
<br>
Ciao<br>
Christia

[Gesine Kuhlmann]

Hi,

1)
Die dämliche Registry ist mal wieder ein Beispiel, wie man eine eigentlich simple Sache unfassbar verkomplizieren kann. Da sie keinerlei Vorteile bietet, wird sie deshalb bis heute auch nicht konsequent genutzt.

2)
Wer sicherheitsrelevante Dinge in der Registry ablegt, dem ist kaum noch zu helfen. Da freut sich das 'Hacker'-Herz.

3)
Die Registry bringt im Gegensatz zum INI-Verfahren folgende gravierenden Nachteile mit sich:

- keine zentrale Administration möglich.

- umständliche manuelle Handhabung

- grottenlangsam

- empfindlich ( Wer lässt schon einen Nutzer gerne etwas in der Registry auch nur kontrollieren )

- erhöhter Installationsaufwand

- unlogischer und unübersichtlicher Aufbau ( geradezu ein Suchspiel )

- schöner Spass bei Neuinstallation des Systems... ( soll ja bei Windows ab und zu vorkommen )

4)
Will ich eine INI-Datei schützen, lege ich Sie auf einer Maschine ab, auf der ich die Zugriffsrechte entsprechend eingeschränkt habe. Will ich Nutzerspezifische Dinge speichern, arbeite ich mit mindestens zwei Ini-Dateien. Einer zentralen und einer die in den jeweiligen Home-verzeichnissen liegt.

Gruß
Gesin

[Hagen Reddmann]

Hi

Gut argumentiert Gesine, mir fällt nur noch eine Ergänzung ein:
Fummelt der User ohne Sinn und Verstand an der INI oder Registry rum, dann ist er selber Schuld. Stürtz die Anwendung auf Grund falscher INI Einstellung ab, dann hat wohl der Programmierer geschlampt

Gruß Hage

[Wolfgang Roller]

Hallo zusammen,<p>
@Christian: Die Sache mit der geänderten Bildschirmauflösung ist ein Aspekt, an den bisher nicht gedacht habe. Die meisten Formulare meiner Anwendungen sind frei skalierbar (Dank der Panels). Einige sind jedoch in der Größe nicht veränderbar. Bei denen gibt's dann Ärger. Ein guter Einwand also.<p>
@Gesine: Ich wollte es nicht so grass audrücken, aber du sprichst mir aus der Seele.<p>
Gruß<p>
Wolfgang Rolle

[Sebastian Beyna]

Hallo Leute

Und erst mal ein großes Dankeschön an alle die sich mit meinem Problem auseinander gesetzt haben und ihre Gedanken dazu hier niederschrieben. Ich werde die hier geäußerten Gedanken mir einmal richtig durch den Kopf gehen lassen und hoffe das ich die richtige oder zumindest eine akzeptable Lösung zur Umsetzung finden werde.

Vielen Dank noch mal : Euer Sebastia