{"id":55000256,"date":"2015-04-01T00:00:00","date_gmt":"2020-01-24T15:59:15","guid":{"rendered":"http:\/\/access-im-unternehmen.aix-dev.de\/aiu\/?p=256"},"modified":"-0001-11-30T00:00:00","modified_gmt":"-0001-11-30T00:00:00","slug":"Anwendungseinstellungen_abspeichern","status":"publish","type":"post","link":"https:\/\/access-basics.de\/index.php\/Anwendungseinstellungen_abspeichern.html","title":{"rendered":"Anwendungseinstellungen abspeichern"},"content":{"rendered":"

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.<\/p>\n

Beispieldatenbank<\/h2>\n

Die Beispiele dieses Artikels finden Sie in der Datenbank 1408_Einstellungen.mdb<\/b>.<\/p>\n

Benutzerdefinierte Einstellungen der Datenbank<\/h2>\n

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.<\/p>\n

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<\/b> eingeführt, der deutlich macht, was genau in der geöffneten Datenbank festgelegt wird und nur in dieser.<\/p>\n

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.<\/p>\n

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.<\/p>\n

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<\/b>: 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.<\/p>\n

Nun stellt sich die Frage, wo genau die Parameter dieser Einstellungen abgespeichert werden sollten<\/p>\n

Entwicklereinstellungen und Anwendereinstellungen<\/h2>\n

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.<\/p>\n

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.<\/p>\n

Speicherorte für Einstellungen<\/h2>\n

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.<\/p>\n

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. <\/p>\n

Datenbank-Properties<\/h2>\n

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<\/b>. Dessen Eigenschaften sind die<\/p>\n

CurrentDB.Properties<\/pre>\n
Es handelt sich dabei um ein Auflistungsobjekt, das, wie so oft, entweder über eine Ordinalzahl oder einen String abgefragt werden kann.<\/p>\n
CurrentDb.Properties(33).Value<\/pre>\n
und<\/p>\n
CurrentDb.Properties             (\"AllowSpecialKeys\").Value <\/pre>\n
sind dasselbe und stellen den Wert der Eigenschaft „Access-Spezialtasten zulassen“ dar. Diese Auflistung ist nicht statisch, sondern kann selbst erweitert werden. Heißt: Neue Elemente können hinzugefügt, geändert, oder gelöscht werden. So auch Variablen für die eigenen Einstellungen. <\/p>\n
übrigens speichert Access diese Properties auch wieder in einer Tabelle – wo auch sonst In diesem Fall ist es die ausgeblendete Systemtabelle MSysObjects<\/b> und dort das Feld LvProp<\/b> des Datensatzes MSysDb<\/b> (siehe Ausschnitt in Bild 1). Die Binärdaten darin haben einen proprietären Aufbau. <\/p>\n
\"Properties<\/a><\/p>\n
Bild 1: Properties in der Tabelle MSysObjects<\/p>\n
Sie können sich alle Datenbank-Properties ansehen, indem Sie eine Routine wie in Listing 1 aus dem Modul mdlProperties<\/b> verwenden. In dieser werden alle Properties ausgelesen und die Namen, Datentypen und Werte im VBA-Direktfenster ausgegeben. Komfortabler geht es mit dem Formular frmProps<\/b> der Beispieldatenbank, die eine ähnliche Prozedur nutzt, um die Properties in einem Listenfeld darzustellen (siehe Bild 2).<\/p>\n
\"Eigenschaften<\/a><\/p>\n
Bild 2: Eigenschaften der Datenbank im Formula frmProps der Beispieldatenbank<\/p>\n
Die Prozedur durchläuft alle Elemente der Properties<\/b>-Auflistung in einer Schleife, und setzt sie jeweils auf oPrp<\/b>, eine DAO.Property<\/b>-Variable. Dieser Objekttyp hat die wesentlichen Eigenschaften Name<\/b>, Type<\/b> und Value<\/b>. Als Value kann ein beliebiger Variant-Wert gesetzt sein, Type ist auf den Datentyp der Eigenschaft eingestellt. Die Schleife einhält eine Ausnahme: Die Standardeigenschaft Connection<\/b> muss außen vor bleiben, weil sie einen Datentyp aufweist, den VBA nicht verarbeiten kann. Wundern Sie sich nicht, dass die Routine an manchen Stellen stockt. Für das Auslesen mancher eingebauter Eigenschaften braucht Access offenbar etwas Bedenkzeit.<\/p>\n
Mehr, als das Auslesen, interessiert uns die Anlage neuer Properties. Auch hierzu finden Sie eine allgemeinverwendbare Routine in der Beispieldatenbank, die Prozedur SetProperty<\/b> (Listing 2). Als Parameter übergeben Sie ihr den Namen der Eigenschaft sowie ihren Wert. Es spielt dabei keine Rolle, ob die Eigenschaft bereits existiert oder nicht. Denn zunächst versucht die Prozedur das Property<\/b>-Objekt auf eine existierende Eigenschaft zu setzen. Gibt es diese unter dem übergebenen Namen nicht, so löst dies normal einen Fehler aus. Die Fehlerbehandlung wurde jedoch außer Kraft gesetzt. Bei Erfolg ist das Property-Objekt gültig, bei Misserfolg entspricht es Nothing<\/b>. Davon hängt ab, wie der Code weiter verzweigt. Ist das Objekt leer, so fährt er mit dem Erzeugen der Eigenschaft per CreateProperty<\/b> fort. Dieser Methode der Properties-Auflistung ist neben dem Namen und Wert der Eigenschaft auch noch der Datentyp in Form einer Konstanten zu übergeben.<\/p>\n
Sub <\/span>SetProperty(sName, Value As Variant<\/span>)\r\n     Dim <\/span>dbs As <\/span>Database\r\n     Dim <\/span>oPrp As <\/span>DAO.Property\r\n     Set<\/span> dbs = CurrentDb\r\n     On Error Resume Next<\/span>\r\n     Set<\/span> oPrp = dbs.Properties(sName)\r\n     If <\/span>oPrp Is Nothing Then<\/span>\r\n         On Error GoTo<\/span> 0\r\n         Set<\/span> oPrp = dbs.CreateProperty(sName, VbTypeToDAO(Value), Value)\r\n         dbs.Properties.Append oPrp\r\n     Else<\/span>\r\n         On Error GoTo<\/span> 0\r\n         oPrp.Value = Value\r\n     End If<\/span>\r\nEnd Sub<\/span><\/pre>\n
Listing 2: Code zum Anlegen neuer Properties<\/p>\n
Möchten Sie weiterlesen? Dann lösen Sie Ihr Ticket!<\/span>
\nHier geht es zur Bestellung des Jahresabonnements des Magazins Access [basics]<\/strong>:<\/span>
\nZur Bestellung ...<\/a><\/span>
\nDanach greifen Sie sofort auf alle rund 400 Artikel<\/strong> unseres Angebots zu - auch auf diesen hier!<\/span>
\nOder haben Sie bereits Zugangsdaten? Dann loggen Sie sich gleich hier ein:<\/span><\/p>\n<\/div>\n\n\t\n\t
\n\n\t\t\n\t\t