Lies diesen Artikel und viele weitere mit einem kostenlosen, einwöchigen Testzugang.
Im Beitrag „Suchformulare für die Datenblattansicht“ haben Sie ein einfach zu erstellendes Suchformular kennengelernt. Dieses ist so praktisch, dass Sie es hoffentlich gleich in Ihre Datenbanken einbauen. Damit ist allerdings immer noch ein wenig Arbeit verbunden: Immerhin müssen Sie noch die Steuerelemente für die Eingabe der Suchbegriffe anlegen. Das ist eigentlich nicht allzuviel Arbeit, aber warum selbst Hand anlegen, wenn man dies einfach per Assistent erledigen können
Mit dem Suchformular aus dem Beitrag Suchformular für die Datenblattansicht (www.access-im-unternehmen.de/724) haben wir eine solide Basis für die flexible Neuerstellung eines Suchformulars in Abhängigkeit von der jeweils zu filternden Datenherkunft. Den Code dieses Formulars brauchen Sie quasi gar nicht anzufassen, Sie müssen lediglich die Steuerelemente zum Eingeben der Suchkriterien hineinschreiben.
Im Beitrag Formulare generieren (www.access-im-unternehmen.de/709) haben Sie bereits einige Techniken zum Erstellen von Formularen und zum Hinzufügen von Steuerelementen kennengelernt. Für den nachfolgend beschriebenen Assistenten brauchen wir allerdings gar nicht von Grund auf zu beginnen: Die Basis des Suchformulars (siehe Bild 1) besteht ja schon, das Bezeichnungsfeld für die Überschrift und die drei Schaltflächen Suchen, Leeren und Abbrechen können wir auch beibehalten – genauso wie den kompletten Code des Formulars. Wir brauchen also nur ein solches Formular in der Rohfassung zu verwenden, die benötigten Steuerelemente zu konfigurieren und einzubauen und die Abmessungen des Formulars an die vorhandenen Steuerelemente anzupassen.
Bild 1: Solch ein Suchformular möchten wir für beleibige Datenherkünfte nachbauen können.
Arbeitstier Assistent
Als Grundgerüst für unseren Assistenten zur Erstellung von Suchformularen dient die Beispieldatenbank zum Beitrag Formular-Assistenten (www.access-im-unternehmen.de/726). Diese Beispieldatenbank passen wir nun für unseren konkreten Einsatzzweck an, indem wir eine Kopie davon erstellen und den Namen in Suchformularassistent.mda ändern. Danach stellen Sie in den Datenbankeigenschaften die Werte ein, die im Add-In-Manager angezeigt werden (siehe Bild 2). Danach bearbeiten wir die Tabelle USysRegInfo, die ja die Einträge für die Registry enthält (siehe Bild 3). Im Wesentlichen ändern wir dort den Namen des neu anzulegenden Schlüssels (hier Suchformularassistent), den Beschreibungstext und die Library-Datei. Außerdem können Sie durch Einstellen von Datasource Required auf den Wert 1 sicherstellen, dass der Benutzer eine Datenherkunft auswählen muss. Vielleicht möchten Sie dem Benutzer aber auch später im der Benutzeroberfläche des Add-Ins noch die Möglichkeit geben, eine andere Datenherkunft auszuwählen – in dem Fall stellen Sie den Wert 0 ein und überlassen es den Gepflogenheiten des Benutzers, ob dieser die Datenherkunft gleich im Dialog Neues Formular auswählen möchte. Die im VBA-Modul mdlWizard enthaltene Funktion StartFormWizard können wir zunächst beibehalten.
Bild 2: Einstellen der Eigenschaften für die Anzeige im Add-In-Manager
Bild 3: Einstellen der Werte der Tabelle USysRegInfo
Aufgaben des Suchformularassistenten aus Benutzersicht
Der Suchformularassistent soll ein Suchformular wie in Bild 1 erstellen, wobei die verwendete Datenherkunft und somit die Felder variieren können. Die Datenherkunft wählt der Benutzer schon vor dem Start aus. Es bleibt also lediglich die Anforderung, die Felder abzufragen, die im Suchformular erscheinen sollen, und deren Aussehen einzustellen. Großartige Varianten soll der Assistent hier nicht bieten: Ein einfaches Textfeld der Datenherkunft soll in der Regel durch ein Textfeld im Suchformular abgebildet werden. Alternativ könnte man hier ein Kombinationsfeld verwenden, das alle im Textfeld vorkommenden Einträge anzeigt.
Bei Nachschlagefeldern soll einfach ein Kombinationsfeld mit der Datensatzherkunft des Nachschlagefelds zur Auswahl der enthaltenen Datensätze im Suchformular erscheinen. Und für Ja/Nein-Felder wird ebenfalls ein Kombinationsfeld angezeigt, dass die Werte Ja und Nein zur Auswahl anbietet.
Zusammengefasst muss der Benutzer neben der eigentlichen Auswahl der zu verwendenden Felder nur noch für Textfelder festlegen, ob die Suche per Textfeld oder per Kombinationsfeld erfolgen soll.
Um den Assistenten möglichst einfach und intuitiv zu gestalten, soll ein Listenfeld alle möglichen Suchfelder anzeigen (inklusive der Varianten für Textfelder) und ein weiteres alle durch den Benutzer ausgewählten Einträge.
Zum Hinzufügen eines Feldes muss der Benutzer dieses lediglich im Listenfeld aller Suchfelder markieren und etwa per Doppelklick zum Listenfeld der hinzuzufügenden Suchfelder hinzufügen.
Das Geschehen wird sich also weitgehend in einem einzigen Formular abspielen, dass wir frmSuchformularassistent nennen und dem wir die Bezeichnung Suchformular-Assistent verpassen.
Da wir darin auch nicht durch Datensätze navigieren möchten, stellen wir die Eigenschaften Navigationsleisten, Datensatzmarkierer, Trennlinien und Bildlaufleisten auf Nein und Zentrieren auf Ja ein. Für ein erstes Erfolgserlebnis schreiben wir außerdem die Funktion StartFormWizard wie folgt um:
Function StartFormWizard(strRecordSource As String) As Variant
DoCmd.OpenForm "frmSuchformularassistent", OpenArgs:=strRecordSource, WindowsMode:=acDialog
End Function
Diese Variante öffnet nach dem Aufrufen des Assistenten gleich das Formular frmSuchformularassistent und übergibt diesem mit dem Öffnungsargument den Namen der vom Benutzer ausgewählten Datenherkunft. Sie können das Add-In nun bereits testweise mithilfe des Add-In-Managers installieren und ausprobieren.
Tipps für die Add-In-Entwicklung
Sobald Sie das Add-In während der Entwicklung einmal installiert haben, befindet sich eine Kopie der .mda-Datei im Add-In-Verzeichnis des aktuellen Benutzers. Sie sollten sich an dieser Stelle entscheiden, welche Version des Add-Ins Sie weiterentwickeln möchten – die ursprüngliche Version oder die im Add-In-Verzeichnis. Wir empfehlen letzteres, da Sie das Add-In so nicht ständig erneut installieren oder zumindest vom Entwicklungsordner in das Add-In-Verzeichnis kopieren müssen.
Eines müssen Sie dabei allerdings beachten: Wenn Sie zum Testen eine Access-Instanz samt Anwendung geöffnet und das Add-In gestartet haben, müssen Sie diese Instanz vor der Weiterbearbeitung der Add-In-Datenbank komplett schließen. Anderenfalls beschwert sich Access beim Wechsel in die Entwurfsansicht eines Objekts, weil kein exklusiver Zugriff möglich ist. Eine andere Beobachtung: Formulare, die beim Testen des Add-Ins in der Zieldatenbank geöffnet werden sollen, müssen in einer parallel für die Entwicklung geöffneten Add-In-Datenbank geschlossen sein. Dies gilt auch für geänderte, aber noch nicht gespeicherte VBA-Module: Diese müssen Sie vor dem Testen des Add-Ins zwar nicht schließen, aber zumindest speichern.
Und noch ein Tipp: Wenn Sie eine für Tests vorgesehene Datenbank immer ganz schnell öffnen möchten, legen Sie doch einfach eine Tastenkombination in der Add-In-Datenbank selbst an. Dazu erstellen Sie ein Makro namens AutoKeys, das Sie wie in Bild 4 ausstatten. Dieses Makro reagiert auf die Tastenkombination Strg + Umschalt + T. Die dadurch aufgerufene Funktion bringen Sie dann in einem eigenen Standardmodul namens mdlTools unter:
Bild 4: Dieses Makro ruft bei Strg + Umschalt + T eine Funktion auf, die eine Beispieldatenbank öffnet.
Public Function OeffneTestdatenbank()
Shell """c:\Programme\Microsoft Office\Office12\MSAccess.exe"" """ &
& CurrentProject.Path & "\test.mdb"""
End Function
In dieser Prozedur müssen Sie gegebenenfalls den Pfad zur Datei MSAccess.exe und zur Beispieldatenbank anpassen.
Konfigurieren des Suchformulars
Das Suchformular enthält ein Kombinationsfeld zur Auswahl der Datenherkunft, die durch die Auswahl im Dialog Neues Formular voreinstellt werden kann. Das Kombinationsfeld soll alle Tabellen und Abfragen der Zieldatenbank anzeigen, was von einem Add-In aus nicht ganz trivial ist. Normalerweise würde man hier einfach auf die Einträge der Systemtabelle MSysObjects zugreifen und eine Abfrage wie die folgende als Datensatzherkunft des Kombinationsfeldes angeben:
SELECT Name, Type FROM MSysObjects WHERE Type=1 Or Type=5 ORDER BY Name;
Wenn Sie diese Abfrage in der Add-In-Datenbank selbst testen, liefert sie auch die gewünschten Daten. Wenn Sie das Add-In allerdings in der Zieldatenbank öffnen, zeigt es nicht die Tabellen und Abfragen der Zieltabelle, sondern die des Add-Ins an. Glücklicherweise bietet Access-SQL aber die IN-Klausel, mit der man nicht nur auf Unterabfragen zugreifen, sondern auch eine alternative Datenbank als Quelle einer SELECT-Abfrage festlegen kann. Wenn wir also die obige SQL-Anweisung wie folgt ändern, können wir auch vom Add-In-Formular auf die Tabellen der Datenbank zugreifen, in der das Add-In gestartet wurde:
SELECT Name, Type FROM MSysObjects IN ''<Datenbankname>'' WHERE Type = 1 Or Type = 5 ORDER BY Name
Natürlich kennen wir den Datenbanknamen der Zieldatenbank beim Entwickeln des Add-Ins noch nicht, daher müssen wir diesen zur Laufzeit ermitteln. Pfad und Namen dieser Datenbank erhalten wir ganz einfach über die Funktion CurrentDB.Name.
Diesen bauen wir per VBA in die SQL-Abfrage ein und weisen diesen dann dem Kombinationsfeld als Datensatzherkunft zu. Dies erledigen wir gleich beim Öffnen des Formulars in der Prozedur, die durch das Ereignis Beim Öffnen ausgelöst wird:
Private Sub Form_Open(Cancel As Integer)
Dim strSQL As String
strSQL = "SELECT Name,
Type FROM MSysObjects IN ''"
& CurrentDb.Name & "''
WHERE Type = 1 Or Type = 5 ORDER BY Name"
Me!cboDatenherkunft.RowSource = strSQL
Me!cboDatenherkunft = Me.OpenArgs
End Sub
Gleichzeitig wertet diese Routine das Öffnungsargument des Formulars aus, das gegebenenfalls den Namen der zuvor im Dialog Neues Formular ausgewählten Datenherkunft (siehe Bild 5) enthält, und weist es dem Kombinationsfeld cboDatenherkunft zu. Das Formular zur Auswahl der Suchfelder sieht im Entwurf wie in Bild 6 aus. Das Kombinationsfeld cboDatenherkunft haben Sie ja bereits kennengelernt.
Bild 5: Die Auswahl der Datenherkunftfür das Suchformular kann gleich in diesem Dialog erfolgen.
Bild 6: Entwurf des Formulars zur Definition der Suchfelder
Die beiden Listenfelder sollen die ausgewählten und alle für die Suche einsetzbaren Felder der Datenherkunft anzeigen. Wir könnten nun einfach eine Feldliste auf Basis der in cboDatenherkunft ausgewählten Tabelle oder Abfrage anzeigen, aber dies genügt leider nicht den Ansprüchen des geplanten Assistenten: Dieser soll ja beispielsweise bei Textfeldern nicht nur den Einbau eines Text-Suchfelds, sondern auch eines Auswahl-Suchfelds zur Auswahl aller im entsprechenden Feld der Datenherkunft enthaltenen Werte anbieten.
Daten für die Listenfelder
Das rechte Listenfeld lstAlle soll alle möglichen Suchfelder anzeigen, die der Entwickler dem Suchformular hinzufügen kann. Wie bereits erwähnt, sind dies zumindest alle Felder der im Kombinationsfeld cboDatenherkunft plus die Kombinationsfeldvariante zum Durchsuchen von Textfeldern durch Auswahl eines der darin enthaltenen Einträge. Das linke Listenfeld lstAusgewaehlt soll alle Einträg enthalten, die der Benutzer aus dem rechten Listenfeld ausgewählt hat. Für die Gestaltung der Datensatzherkunft der beiden Listenfelder gibt es wie üblich verschiedene Möglichkeiten. Der Einfachheit halber verwenden wir an dieser Stelle einfach zwei Tabellen. Die Tabelle tblSuchfelder sieht wie in Bild 7 aus und enthält die Datensatzherkunft für das rechte Listenfeld lstAlle. Neben dem Primärschlüsselfeld gibt es drei weitere Felder. Suchfeld ist das Feld, dass im Listenfeld angezeigt werden soll und dem Benutzer mitteilt, auf welches Feld der Datenherkunft sich das potenzielle Suchfeld beziehen wird und welches Steuerelement für die Eingabe des Suchbegriffs verwendet wird. Die letzten beiden Felder werden für die eigentliche Erstellung des Suchformulars benötigt. Neben dem Feldnamen ist hier der Feldtyp interessant. Der Feldtyp wird im Code des Formularmoduls durch eine Enumeration definiert, die wie folgt aussieht:
Bild 7: Die Datenherkunft des Listenfelds lstAlle enthält alle möglichen Suchfelder.
Public Enum eSearchFieldType
eText = 0
eTextCombo = 1
eCombo = 2
eBoolean = 3
End Enum
Diese Enumeration kommt in der Prozedur zum Einsatz, welche aus der Datenherkunft die Datensätze der Tabelle tblSuchfelder erzeugt. Diese Prozedur heißt SuchfelderSpeichern und erwartet den Namen der Datenherkunft als Parameter. Hierbei ist es egal, ob der Name einer Tabelle oder einer Abfrage übergeben wird (s. Listing 1).
Listing 1: Füllen der Tabelle tblSuchfelder mit allen möglichen Suchfeldern
Private Sub SuchfelderSpeichern(strDatenherkunft As String)
''Deklaration ...
Set db = CurrentDb
Set dbc = CodeDb
Set rst = db.OpenRecordset("SELECT * FROM " & strDatenherkunft & " WHERE 1 = 2", dbOpenDynaset)
dbc.Execute "DELETE FROM tblSuchfelder", dbFailOnError
For Each fld In rst.Fields
intControltype = acTextBox
On Error Resume Next
intControltype = fld.Properties("DisplayControl")
On Error GoTo 0
Select Case intControltype
Case acCheckBox
dbc.Execute "INSERT INTO tblSuchfelder(Feldname, Feldtyp, Suchfeld) VALUES(''" & fld.Name & "'', " _
& eSearchFieldType.eBoolean & ", ''" & fld.Name & " (Auswahlsuchfeld)'')", dbFailOnError
Case acTextBox
dbc.Execute "INSERT INTO tblSuchfelder(Feldname, Feldtyp, Suchfeld) VALUES(''" & fld.Name & "'', " _
& eSearchFieldType.eText & ", ''" & fld.Name & " (Textsuchfeld)'')", dbFailOnError
dbc.Execute "INSERT INTO tblSuchfelder(Feldname, Feldtyp, Suchfeld) VALUES(''" & fld.Name & "'', " _
& eSearchFieldType.eTextCombo & ", ''" & fld.Name & " (Auswahlsuchfeld)'')", dbFailOnError
Case acComboBox
dbc.Execute "INSERT INTO tblSuchfelder(Feldname, Feldtyp, Suchfeld) VALUES(''" & fld.Name & "'', " _
& eSearchFieldType.eCombo & ", ''" & fld.Name & " (Auswahlsuchfeld)'')", dbFailOnError
Case Else
Debug.Print fld.Name, intControltype
End Select
Next fld
Me!lstAlle.Requery
End Sub
Die Prozedur erstellt durch Hinzufügen der WHERE-Bedingung 1=2 ein leeres Recordset auf Basis der angegebenen Datenherkunft. Es löscht alle bereits in der Tabelle tblSuchfelder enthaltenen Datensätze und durchläuft dann mit einer For Each-Schleife und der Laufvariablen fld alle Felder des Recordset-Objekts. Innerhalb der Schleife ermittelt die Prozedur zunächst den Steuerelementtyp des Feldes, wobei nur Textfelder, Kombinationsfelder und Ja/Nein-Felder berücksichtigt werden. In Abhängigkeit vom Steuerelementtyp werden innerhalb der folgenden Select Case-Struktur verschiedene SQL-Abfragen ausgeführt, um einen oder mehrere Datensätze je Feld zur Tabelle tblSuchfelder hinzuzufügen. Mehrere deshalb, weil der Entwickler ja für Textfelder entweder ein Text- oder ein Kombinationsfeld als Suchfeld verwenden kann (oder auch beide). Nach Eintragen aller Datensätze für die angegebene Datenherkunft wird das Listenfeld lstAlle aktualisiert. Damit dieses die Daten wie in Bild 8 anzeigt, stellen Sie die Datensatzherkunft des Listenfeldes auf tblAlle ein und setzen die beiden Eigenschaften Spaltenanzahl und Spaltenbreiten auf 2 beziehungsweise 0cm.
Bild 8: Das Listenfeld wird nach Aktualisierung der Datenherkunft gefüllt.
Suchfelder gleich beim Öffnen eintragen
Da der Benutzer gleich im Dialog Neues Formular eine Datenherkunft angeben kann, stellt man das Kombinationsfeld cboDatenherkunft gleich auf die angegebene Datenherkunft ein und füllt im gleichen Zuge das Listenfeld lstAlle. Dies geschieht in der angepassten Version der Ereignisprozedur Form_Open aus Listing 2. Diese Prozedur ruft zunächst eine weitere Routine auf, welche die Inhalte der Datensatzherkünfte der beiden Listenfelder löscht:
Listing 2: Füllen von Kombinations- und Listenfelder beim Öffnen des Formulars
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