Globale Vriablen, Record´s oder Objecte Konfigurationsdaten

[Chemiker]

Hallo Jens,

das Du die Daten in eine Datenbank ablegst ist ja erst mal OK, aber bevor Du Zugriff auf die Datenbank herstellen kannst sind ja gewisse Daten notwendig und diese Daten lege ich in eine INI-Datei ab.

Bis bald Chemiker

[Jens Hartmann]

Zitat:

Zitat von Chemiker

das Du die Daten in eine Datenbank ablegst ist ja erst mal OK, aber bevor Du Zugriff auf die Datenbank herstellen kannst sind ja gewisse Daten notwendig und diese Daten lege ich in eine INI-Datei ab.

Was für Daten meinst Du?

Z.B. den Speicherort der Datenbank. Den habe ich über einen Alias realisiert, der in der Aliases.conf von Firebird abgelegt ist. Ansonsten, habe ich eigendlich keine Daten die ich vorher benötige.

Gruß Jens

[Christian Seehase]

Moin Jens,

also ich mache das, i.d.R., so ähnlich wie Reinhard.
Jedes Programm hat ein Settings-Objekt, dass dann im Hauptform erzeugt und von da aus dann zur Nutzung an andere Formulare/Funktionen/Objekte weitergegeben wird (so ähnlich wie Luckie es beschrieben hat).
Wo die Daten dann tatsächlich liegen, spielt dann keine Rolle mehr, da es für das Programm völlig transparent ist.
Man kann eine Datenbank, eine ini, die Registry oder was einem sonst noch so einfällt verwenden.
Unter Verwendung eines Parameters (ggf. auch mehrere), die angeben, wo die Konfiguration liegt, kann man dann auch problemlos verschiedene Konfigurationen ermöglichen (z.B. Userspezifisch)
Ob man die Daten dann einmal einliest, oder immer jeweils direkt aus der Konfiguration ausliest hängt auch davon ab, ob nach dem Programmstart Änderungen erlauben will oder darf.
Analog ist es dann auch mit dem Ändern der Konfigurationsdaten.
Es hängt vom Zusammenhang ab, ob man solche Änderungen erst beim Programmende, oder gleich bei jeder Änderung wegschreibt.

[Jens Hartmann]

Hallo Christian,

also momentan, schreibe ich die Konfiguationen sofort, weil ich ja, je nach Hardware andere Parameter benötige.
Die Parameterabfrage, mache ich momentan, dann bei jedem Ablauf, allerings, direkt aus den Konfigurationskomponenten.

z.b. so..

Delphi-Quellcode:

            case Hardwareanbindung.RGZentralentyp.ItemIndex of
              0 : DatenverarbeitungMB24;
              1 : DatenverarbeitungMB48;
              2 : DatenverarbeitungMB100;
              3 : DatenverarbeitungMB256;
              4 : DatenverarbeitungUEZ2000;
              5 : DatenverarbeitungBMC1024;
            end;

die case Anweisung fragt eine RadioGroup ab, diese wird bei Programmstart über eine IniDatei, Sorry mittlerweile über die DB geladen, und nach einer Änderung auch sofort in der DB gespeichert.

Bei dem Programmablauf, frag ich halt nicht die DB ab, sondern direkt die Komponenten. Wenn das ja so OK wäre, muss ich das ja eigendlich nur noch alles von INI auf DB umstellen, und fertig. Die frage, die ich mir gestellt habe, war allrdigs, ob das so in Ordnung ist.

Gruß Jens

[Reinhard Kern]

Zitat:

Zitat von Jens Hartmann

Bei dem Programmablauf, frag ich halt nicht die DB ab, sondern direkt die Komponenten. Wenn das ja so OK wäre, muss ich das ja eigendlich nur noch alles von INI auf DB umstellen, und fertig. Die frage, die ich mir gestellt habe, war allrdigs, ob das so in Ordnung ist.

warum sollte das nicht ok sein, ich mache das genauso, bei mir steht die Settingsklasse mit den einzelnen Settings zwischen der INI-Datei/Registry und der Anwendung, die Anwendung sollte garnicht direkt auf eine Datei zugreifen. Wenn ich dann noch beim Create angebe, welches TEdit zuständig ist, brauche ich das Konfigurations-GUI nur noch zu zeichnen, die Werte stehen dann beim Start automatisch drin und werden auch dort wieder geholt und zurückgespeichert. Allerdings habe ich beim Lesen noch einen Mode-Parameter eingeführt, der angibt, ob der Wert direkt aus dem Setting genommen wird, ob vorher der neueste Wert aus der INI geholt wird und ob der geholte Wert ins TEdit übernommen werden soll. Braucht man aber nicht oft, weil das Setting-Objekt immer den aktuellen Wert hat und sich an der INI eigentlich nichts ändern kann, es sei denn, jemand schreibt hintenrum manuell was rein und es muss sofort übernommen werden - finde ich eher sinnlos.

Wo das Zeug physikalisch gespeichert wird, sollte man so flexibel wie möglich handhaben (ich unterstütze z.B. auch unixartige Home-Verzeichnisse), weil sich das abschliessend sowieso nicht entscheiden lässt: wer MS-hörig ist MUSS die Registry verwenden, INI-Dateien sind transparenter, werden aber vom MS abgelehnt. Datenbanken sind eigentlich zu aufwendig dafür und XML biete auch keine besonderen Vorteile. Ich finde die Tatsache, dass bei Datenbanken die Feldgrösse i.a. festgelegt ist, eher hinderlich, und man muss wohl boolean, integer, real usw. als Strings speichern, wenn man nicht gleich alles als Variant deklarieren will. Das ist allerdings in einer INI auch nicht anders, nur mit freier Stringlänge.

Gruss Reinhard

[Jens Hartmann]

Naja, hört sich doch für mich alles gar nicht so schlecht an. Dann habe ich ja doch irgendwo aufgepasste. Gut aber eins würde mich mal interessieren. Ist es wichtig z.B. nur die Registry oder nur eine INI oder Datenbank zu nehmen. Oder ist es egal, wenn ich diese Daten verteilen tue.

Meiner Meinung nach, sollten die Daten schon alle an einer gemeinsamen Stelle liegen. Wie soll ich sonst noch als USER einen Überblick behalten.

Gut der ein oder andere mag ja jetzt sagen, damit hat der USER ja nichts zu tun. Mag auch stimmen. Aber bei meiner Software z.B. ist es so, das manche USER schon gewisse Kenntnisse mitbringen, und gegebenenfall´s solche Sache wünschen, um solche Einstellung vor dem Programmstart zu realisieren, oder um z.B. bei gemeinsamen Objekten die INI Datei oder so, kopieren zu können, um beim nächsten Objekt diese wieder nutzen zu können.

Daher würde mich Euere Meinung mal interesieren.

Gruß Jens

[Reinhard Kern]

Zitat:

Zitat von Jens Hartmann

...Gut der ein oder andere mag ja jetzt sagen, damit hat der USER ja nichts zu tun. Mag auch stimmen. Aber bei meiner Software z.B. ist es so, das manche USER schon gewisse Kenntnisse mitbringen, und gegebenenfall´s solche Sache wünschen, um solche Einstellung vor dem Programmstart zu realisieren, oder um z.B. bei gemeinsamen Objekten die INI Datei oder so, kopieren zu können, um beim nächsten Objekt diese wieder nutzen zu können.
...

Hallo Jens,

das ist nicht nur Auffassungssache, sondern hängt auch von Zweck und Einsatz der Software ab. Für mich ist ein PC mit meiner Software ein technisches Gerät in einer chemischen Fabrik, und jeder Bediener sollte die gleiche Oberfläche sehen. Fräsmaschinen lassen sich ja auch nicht userspezifisch konfigurieren. Ausserdem habe ich als Netzwerkverwalter genügend schreckliche Erfahrungen gemacht, etwa wenn manche User unbedingt violette Schrift auf grünem Hintergrund einstellen müssen.

Daher musst du dich erstmal entscheiden, ob du Parameter unter HKEY_CURRENT_USER abspeicherst oder HKEY_LOCAL_MACHINE oder teils-teils, und für INI-Dateien, DBs und XML ist das ähnlich: "Eigene Dateien" oder ein gemeinsames Verzeichnis.

Ich halte das schon deswegen flexibel, weil in Grossfirmen mit zehntausenden PCs im Netz ganz wesentlich die Admins entscheiden, wo ich was speichern darf. Die müssen mir dann natürlich auch die Rechte dafür einrichten.

In unserer eigenen Firma habe ich sowieso local und public INIs eingerichtet - die Fensterposition etwa ist lokal, Einstellungen für Drucker dagegen auf einem zentralen Server, schliesslich sollen Rechnungen ja überall gleich rauskommen.

Gruss Reinhard

[Christian Seehase]

Moin Jens,

also ich für meinen Teil bevorzuge für die Konfiguration schlicht Textdateien, meist in der Form von INI-Dateien.
Für anwendungsspezifische Daten kommen diese in ein Verzeichnis unter \Dokumente und Einstellungen\All Users\Anwendungsdaten\ (ggf. noch eine Ebene mehr), für userspezifsche Daten in ein Verzeichnis unter \Dokumente und Einstellungen\<USERNAME>\Anwendungsdaten.

[Jens Hartmann]

Das hört sich doch ganz gut an.

Also, fasse ich mal zusammen,

Ich schreibe meine ganzen Einstelllungsparameter in meine DB, die ja über einen Alias angebunden ist. Wenn ich das so realisierte habe, lese ich die Daten nach Programmstart ein, und habe diese dann somit zur Verfügung.

Nehme ich Änderungen während des Programmablaufes vor, Speicher ich diese in der DB, aber dadurch das ich im Programm den direkten Zusand der Komponente abfrage,kann ich diese Funktion auch sofort nutzen.

Für Sinnvoll halte ich dann eigendlich nur, meine Datenbank zu teilen. Momentan steht ja alles in einer DB, wenn ich aber die Möglichkeit geben will, diese zu kopieren, um diese Einstellungen auf anderen Rechner nutzen zu können, so will ich ja nur die USER Einstellungen oder Grafik-Einstellungen kopieren, und nicht die Datensätze aus Object XY.

Dann werde ich mich jetzt mal damit beschäftigen.

Also schon mal vielen Dank an alle und schöne Ostertage. :thumb:

Gruß Jens

[Chemiker]

Hallo Jens,

die Zugangsdaten sollten meiner Meinung nach, außerhalb der Datenbank anlegen werden. Zum Beispiel der Path der Datenbank, sonst hast Du nach Änderungen des Systems (Path-Änderungen am Server zum Beispiel) keine Möglichkeit aus Deinem Programm heraus diese Änderungen nachzuvollziehen.

Bis bald Chemiker