|  | Unser Angebot für Sie! Lesen Sie diesen Beitrag und 500 andere sofort im Onlinearchiv, und erhalten Sie alle zwei Monate brandheißes Access-Know-how auf 72 gedruckten Seiten! Plus attraktive Präsente, zum Beispiel das bald erscheinende Buch 'Access 2010 - Das Grundlagenbuch für Entwickler'! |
| | | | | |
Zusammenfassung
Verwalten Sie die Daten all Ihrer Lookuptabellen in nur einem einzigen Formular.
Techniken
Tabellen, Formulare, VBA
Voraussetzungen
Access 2000 und höher
Beispieldateien
Lookuptabellen.mdb
Shortlink
www.access-im-unternehmen.de/722
Standard-Lookupformulare
André Minhorst, Duisburg
Lookuptabellen speichern meist Werte, die zum Vermeiden von Redundanzen und Inkonsistenzen aus einer anderen Tabelle ausgelagert wurden. Die Formulare für ihre Bearbeitung sehen meist gleich aus: Ein Hauptformular mit einer OK-Schaltfläche, ein Unterformular mit den Daten - das war es. Solche Formulare braucht man nicht für jede dieser Tabellen einzurichten: Es reicht ein einziges, dem Sie nur noch mitteilen, aus welcher Tabelle oder Abfrage die angezeigten Felder stammen sollen.
Wie ein solches Formular aussieht, entnehmen Sie Abb. 1: Es zeigt lediglich die vorhandenen Einträge der Lookuptabelle an und bietet die Möglichkeit, diese zu bearbeiten. Solch ein Formular ist schnell hergestellt: Schnell ein Haupt- und ein Unterformular erstellen, Datenherkunft des Unterformulars einstellen, Felder aus der Feldliste hinzufügen, Unterformular ins Hauptformular einfügen, OK-Schaltfläche unterbringen - fertig!
Abb. 1: Ein typisches Lookupformular
Was aber, wenn man eine ganze Reihe solcher Formulare benötigt? Dann kommt schon ein wenig mehr Arbeit auf einen zu. Außerdem steigt der Aufwand für Änderungen wie etwa das Hinzufügen einer Fehlerbehandlungen oder Wartungsarbeiten proportional zur Anzahl der Formulare.
Aus x mach 1
Was tun Sie, wenn Sie die gleiche Abfolge identischer Codezeilen in einer oder mehreren VBA-Funktionen verwenden? Sie erzeugen natürlich eine Prozedur oder Funktion, welche die enthaltenen Anweisungen an nur einer Stelle versammelt und rufen diese Anweisungen dann über die entsprechende Prozedur beziehungsweise Funktion auf - gegebenenfalls unter Einbeziehung eines oder mehrerer Parameter, welche die Prozedur oder Funktion individualisieren.
Genau das gleiche machen wir jetzt mit den Lookupformularen. Wenn Sie in einer Anwendung eine Reihe ähnlich aufgebauter Formulare verwenden, denken Sie einmal darüber nach, ob Sie deren Aufbau nicht genau gleich gestalten können (oder zumindest so, dass dieser über Parameter im gewünschten Maße variiert werden kann).
Wir zeigen, wie das mit einem Lookupformular wie aus Abb. 1 funktioniert. Als einzigen Parameter verwenden wir dabei den Namen der Tabelle oder Abfrage, deren Daten angezeigt werden sollen beziehungsweise eine entsprechende SQL-Anweisung. Diese soll mit dem Parameter OpenArgs übergeben werden, sodass der Aufruf unseres Formulars beispielsweise so aussieht:
DoCmd.OpenForm "frmLookup", OpenArgs:="tblVerbrauchsarten"
Das aufgerufene Formular wertet diese Datenherkunft dann aus und füllt die Felder des Formulars entsprechend.
Hauptformular
Das Hauptformular übernimmt die Hauptarbeit des Lookupformulars - zumindest, was den Code angeht. Ansonsten enthält es lediglich das Unterformular sfmLookup, das wir im Anschluss beschreiben, sowie eine Schaltfläche mit der Beschriftung OK, die das Formular schließen soll (s. Abb. 2). Diese Schaltfläche löst die folgende Ereignisprozedur aus:
Abb. 2: Das Formular frmLookup samt Unterformular in der Entwurfsansicht
Private Sub cmdOK_Click()
DoCmd.Close
End Sub
Das Unterformular enthält drei ungebundene Textfelder samt Bezeichnungsfeldern. Die Textfelder heißen txtValue1, txtValue2 und txtValue3, die Bezeichnungsfelder lblValue1, lblValue2 und lblValue3. Wie Sie die Felder anordnen, ist egal - hauptsache, Sie stellen die Eigenschaft Standardansicht des Unterformulars auf Datenblatt ein.
Formular öffnen
Kommen wir zum Aufrufen des Formulars. Dies geschieht, wie bereits erwähnt, über die DoCmd-OpenForm-Anweisung mit dem Namen der Datenherkunft als OpenArgs-Parameter. Diesen muss das Formular beim Öffnen auswerten, was in einer Prozedur geschieht, die durch das Ereignis Beim Öffnen geschieht.
Diese Prozedur prüft, ob der OpenArgs-Parameter einen Wert enthält und bricht das Öffnen des Formulars ab, wenn dies nicht der Fall ist:
Private Sub Form_Open(Cancel As Integer)
If Len(Nz(Me.OpenArgs, "")) = 0 Then
Cancel = True
End If
End Sub
Dies sollten Sie bedenken, wenn Sie das Formular frmLookup der Beispieldatenbank per Doppelklick auf den Eintrag im Datenbankfenster beziehungsweise Navigationsbereich öffnen möchten.
Nach dieser Prüfung geht die eigentliche Arbeit los, und zwar in der Ereignisprozedur Beim Laden des Formulars (s. Listing 1).
Private Sub Form_Load()
Dim db As DAO.Database
Dim obj As Object
Dim strColumnHeader As String
Dim strOpenArgs As String
Dim strCaption As String
Dim i As Integer
Dim intFieldcount As Integer
Dim lngWidth As Long
strOpenArgs = Nz(Me.OpenArgs, "")
Set db = CurrentDb
Me!sfmLookup.Form.Recordsource = strOpenArgs
WizHook.Key = 51488399
Select Case WizHook.ObjTypOfRecordSource(strOpenArgs)
Case 0
On Error Resume Next
db.QueryDefs.Delete "qdfTemp"
On Error Goto 0
Set obj = db.CreateQueryDef("qdfTemp", strOpenArgs)
Case 1
Set obj = db.TableDefs(strOpenArgs)
Case 2
Set obj = db.QueryDefs(strOpenArgs)
End Select
intFieldcount = obj.Fields.Count
If intFieldcount > 3 Then
intFieldcount = 3
End If
For i = 1 To 3
If intFieldcount < i Then
Me!sfmLookup.Form.Controls("txtValue" & i).ColumnHidden = True
Else
Me!sfmLookup.Form.Controls("txtValue" & i).ControlSource = obj.Fields(i - 1).Name
|
