Anwendungseinstellungen abspeichern

Lies diesen Artikel und viele weitere mit einem kostenlosen, einwöchigen Testzugang.

Sie haben eine umfangreiche Datenbank entwickelt und möchten Ihren Anwendern die Möglichkeit bieten bestimmte Einstellungen etwa der Benutzeroberfläche selbst festlegen zu können – so, wie sie das in anderen Anwendungen von den Einstellungen- und Optionen-Menüs her kennen. Damit lassen sich etwa das Erscheinungsbild steuern oder Pfade für Auswahldialoge vorgeben. Wie sich das sinnvoll per VBA umsetzen lässt möchten wir in diesem Beitrag beleuchten.

Beispieldatenbank

Die Beispiele dieses Artikels finden Sie in der Datenbank 1408_Einstellungen.mdb.

Benutzerdefinierte Einstellungen der Datenbank

Viele Einstellungen einer Datenbank verwaltet Access selbst. Sie können bei der Entwicklung etwa über das Optionen-Menü verschiedene Einstellungen fest vorgeben. Dort finden sich etwa Vorgaben für das Layout von Datenblättern, die Darstellung von Menüs oder die Ansicht von Steuerelementen, aber auch technische Vorgaben, wie das Verhalten bei Datensatzsperrung.

Unter Access 2003 war noch nicht ersichtlich, ob sich diese Vorgaben auf den Arbeitsplatz, also Access generell, beziehen, oder auf die eben geöffnete Datenbank. Unter Access 2007 wurde im Optionen-Dialog dann der Bereich Aktuelle Datenbank eingeführt, der deutlich macht, was genau in der geöffneten Datenbank festgelegt wird und nur in dieser.

Doch auch der Anwender kann manche änderungen dauerhaft abspeichern. änderungen an Spaltenbreiten von Datenblättern oder an der Größe von Formularen werden verewigt, wenn anschließend über Menü oder Symbolleiste die Speichern-Aktion ausgeführt wird. Die Schriftart der Steuerelemente eines Formulars etwa kann er hingegen nicht beeinflussen.

Wollten Sie dem Anwender diese Möglichkeit einräumen, so müssten neben dem Code, der die Schriften der Textfelder beim Laden des Formulars steuert, und einem Dialog, der die Schriften anböte, auch noch das Feature hinzukommen, die Schrifteinstellungen irgendwo abzuspeichern, damit sie beim nächsten Laden wieder zur Anwendung gelangten. Oft ist die Aufgabe jedoch trivialer. Besteht beispielsweise in der Anwendung die Notwendigkeit, öfter Dateien per Auswahldialog auszuwählen, dann ist es sicher nützlich, wenn man jeweils im zuvor geöffneten Ordner landet und nicht immer neu dorthin navigieren muss.

Der zuletzt ausgewählte Pfad könnte hier abgespeichert und bei erneutem öffnen des Auswahldialogs gleich angeboten werden. Oder nehmen wir den selbstgebauten Drucker-Dialog aus dem Artikel Access-Berichte drucken: Günstig wäre, wenn hier der zuletzt verwendete Drucker im Kombinationsfeld voreingestellt wäre und nicht jedes Mal neu in der Liste gesucht werden müsste.

Nun stellt sich die Frage, wo genau die Parameter dieser Einstellungen abgespeichert werden sollten

Entwicklereinstellungen und Anwendereinstellungen

Diese beiden Bereiche wären zu trennen. Es gibt Einstellungen, die der Anwender nicht beeinflussen können sollte. Nehmen wir an, sie hätten eine Schnittstelle zu einem Webservice in Ihrer Datenbank implementiert. Die URL zu diesem Webservice kann sich ändern. Statt die URL als String hart in ein VBA-Modul zu kodieren, eignet sich eine benutzerdefinierte abspeicherbare Variable für diesem Zweck besser. So müssen Sie nur den Wert der Speicherstelle ändern und kein Modul modifizieren. Der Anwender sollte von alledem nichts mitbekommen.

Umgekehrt braucht Sie als Entwickler nicht zu interessieren, welchen Drucker der Anwender verwendet oder einstellt. Je nach Anwender- oder Entwicklerbereich unterscheiden sich dann auch die Speicherorte für die Einstellungsvariablen. Ein gewichtiger Grund dafür : Wenn Sie ein Update Ihrer Datenbank verteilen, die Einstellungen aber in der Datenbank selbst gespeichert sind, so gehen alle vom Anwender vorgenommenen änderungen flöten und er wird mit Ihren Entwicklereinstellungen konfrontiert. Deshalb müssen Anwendereinstellungen zwingend extern abgespeichert werden.

Speicherorte für Einstellungen

Möglichkeiten bieten sich dafür viele an. Früher gab es einmal INI-Dateien, die Einstellungen aufnahmen. Heute verwendet man stattdessen die Registry – dazu mehr in einem anderen Beitrag dieser Ausgabe. Statt INI-Dateien kommen auch einfache Textdateien infrage, in die per VBA und dessen Open-Anweisung Variablenwerte geschrieben würden.

Doch was liegt in einer Datenbank näher, als solche Daten in Tabellen zu schreiben Für die Entwicklereinstellungen nimmt man eine Tabelle in der Anwendungsdatenbank selbst, für die Anwender eine externe verknüpfte Datenbank, die nur die eine Tabelle mit den Einstellungen enthält. Als weitere Alternative kämen auch andere Datenbanksysteme infrage, wie etwa SQLite, das für diesen Zweck von diversen Applikationen verwendet wird – der Firefox Browser ist ein Beispiel dafür. Doch warum in die Ferne schweifen… Schließlich gibt es noch eine weitere Alternative, derer sich auch Access selbst bedient: Die Datenbank-Properties.

Datenbank-Properties

Access speichert die ganzen Optionen, die Sie über das entsprechende Menü öffnen, in den Properties der Datenbank. über VBA und DAO erhalten Sie Zugriff auf die Datenbank über das Zauberwort CurrentDb. Dessen Eigenschaften sind die

CurrentDB.Properties

Es handelt sich dabei um ein Auflistungsobjekt, das, wie so oft, entweder über eine Ordinalzahl oder einen String abgefragt werden kann.

Ende des frei verfügbaren Teil. Wenn Du mehr lesen möchtest, hole Dir ...

Testzugang

eine Woche kostenlosen Zugriff auf diesen und mehr als 1.000 weitere Artikel

diesen und alle anderen Artikel mit dem Jahresabo