<\/p>\n
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.<\/b><\/p>\n
Wie ein solches Formular aussieht, entnehmen Sie Bild 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!<\/p>\n
![\"pic001.png\"](\"..\/fileadmin\/_temp_\/2010_03\/Lookupformulare-web-images\/pic001.png\")
<\/p>\n
Bild 1: Ein typisches Lookupformular<\/span><\/b><\/p>\n 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.<\/p>\n Aus x mach 1<\/b><\/p>\n 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.<\/p>\n 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).<\/p>\n Wir zeigen, wie das mit einem Lookupformular wie aus Bild 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<\/b> übergeben werden, sodass der Aufruf unseres Formulars beispielsweise so aussieht:<\/p>\n Das aufgerufene Formular wertet diese Datenherkunft dann aus und füllt die Felder des Formulars entsprechend.<\/p>\n Hauptformular<\/b><\/p>\n Das Hauptformular übernimmt die Hauptarbeit des Lookupformulars – zumindest, was den Code angeht. Ansonsten enthält es lediglich das Unterformular sfmLookup<\/b>, das wir im Anschluss beschreiben, sowie eine Schaltfläche mit der Beschriftung OK<\/b>, die das Formular schließen soll (siehe Bild 2). Diese Schaltfläche löst die folgende Ereignisprozedur aus:<\/p>\n Bild 2: Das Formular frmLookup samt Unterformular in der Entwurfsansicht<\/span><\/b><\/p>\n Das Unterformular enthält drei ungebundene Textfelder samt Bezeichnungsfeldern. Die Textfelder heißen txtValue1<\/b>, txtValue2 <\/b>und txtValue3<\/b>, die Bezeichnungsfelder lblValue1<\/b>, lblValue2 <\/b>und lblValue3<\/b>. Wie Sie die Felder anordnen, ist egal – hauptsache, Sie stellen die Eigenschaft Standardansicht des Unterformulars auf Datenblatt <\/b>ein.<\/p>\n Formular öffnen<\/b><\/p>\n Kommen wir zum Aufrufen des Formulars. Dies geschieht, wie bereits erwähnt, über die DoCmd-OpenForm<\/b>-Anweisung mit dem Namen der Datenherkunft als OpenArgs<\/b>-Parameter. Diesen muss das Formular beim Öffnen auswerten, was in einer Prozedur geschieht, die durch das Ereignis Beim Öffnen <\/b>geschieht.<\/p>\n Diese Prozedur prüft, ob der OpenArgs<\/b>-Parameter einen Wert enthält und bricht das Öffnen des Formulars ab, wenn dies nicht der Fall ist:<\/p>\n Dies sollten Sie bedenken, wenn Sie das Formular frmLookup<\/b> der Beispieldatenbank per Doppelklick auf den Eintrag im Datenbankfenster beziehungsweise Navigationsbereich öffnen möchten.<\/p>\n Nach dieser Prüfung geht die eigentliche Arbeit los, und zwar in der Ereignisprozedur Beim Laden <\/b>des Formulars (s. Listing 1).<\/p>\n Listing 1: Beim Laden des Formulars werden auch die Felder angepasst und gefüllt.<\/p>\n <\/p>\n Das Öffnungsargument wird hier zunächst in der Variablen strOpenArgs <\/b>zwischengespeichert und dem Unterformular über die Eigenschaft Recordsource <\/b>als Datenherkunft zugewiesen. Damit ist das Unterformular an die betroffene Tabelle oder Abfrage gebunden.<\/p>\n Danach benötigten wir ein Objekt, anhand dessen wir die Felder der Datenherkunft durchlaufen können, um die Felder des Unterformulars anpassen und füllen zu können. Da der Benutzer mit dem Öffnungsargument beliebige Datenherkünfte übergeben können soll (also Tabellen, Abfragen oder SQL-Ausdrücke), haben wir zwei Möglichkeiten:<\/p>\n Entweder wir öffnen ein Recordset<\/b>-Objekt auf Basis der angegebenen Datenherkunft und stellen dies per WHERE<\/b>-Bedingung so ein, dass es keine Datensätze zurückliefert (denn wir brauchen es ja nur zur Identifikation der Felder), oder wir verwenden eines der Datendefinitions-Objekte wie TableDef <\/b>oder QueryDef<\/b>. Diese enthalten keine Daten, sondern nur die Definition der Tabelle beziehungsweise Abfrage.<\/p>\n Die erste Variante übergehen wir diesmal, da wir erst noch prüfen müssten, ob der übergebene Ausdruck eine Tabelle, Abfrage oder ein SQL-Ausdruck ist und ob dieser gegebenenfalls schon eine WHERE-Klausel enthält – sprich: Es würden eine Reihe Zeichenkettenfunktionen aufgerufen, die wir uns diesmal einfach sparen möchten.<\/p>\n Im Falle der TableDef<\/b>-\/QueryDef<\/b>-Variante wissen wir allerdings ebenfalls nicht, ob strOpenArgs <\/b>nun eine Tabelle, eine Abfrage oder einen SQL-Ausdruck enthält. Das ist aber kein Problem, denn die nicht dokumentierte WizHook<\/b>-Klasse liefert uns mit ObjTypOfRecordSource <\/b>eine kleine Funktion, der wir den Datenherkunftsausdruck einfach übergeben können (vorherige Aktivierung durch WizHook.Key = 51488399 <\/b>nötig). Heraus kommt eine von drei Zahlen:<\/p>\n Den Verweis auf das Objekt für die spätere Abfrage der Datenherkunftsinformationen wie Feldnamen et cetera speichern wir einfach in einer Variablen des Typs Object<\/b>. Darin können wir fast alles speichern, und nach der Zuweisung des tatsächlich benötigten Objekts greifen wir auch auf dessen Elemente zu – nur ohne IntelliSense.<\/p>\n Nun weisen wir diesem in Abhängigkeit vom Ergebnis entweder ein TableDef<\/b>-Objekt, ein QueryDef<\/b>-Objekt oder das Ergebnis der CreateQueryDef<\/b>-Methode auf Basis des gegebenen SQL-Ausdrucks zu.<\/p>\n Danach ermittelt die Prozedur die Anzahl der Felder der Datenherkunft. Ist diese größer als drei, werden nur die ersten drei Felder berücksichtigt. Ist sie kleiner als drei, werden die ersten n Felder in den ersten Textfeldern angezeigt und die übrigen Textfelder samt Bezeichnungsfeldern ausgeblendet.<\/p>\n Eine Menge davon geschieht in der nun folgenden For Next<\/b>-Schleife. Sie prüft zunächst, ob der Index des aktuell behandelten Textfeldes des Unterformulars größer als die Anzahl der Felder der Datenherkunft ist und blendet das Textfeld in diesem Fall aus (dies geschieht allerdings, wenn überhaupt, in den späteren Durchläufen der Schleife).<\/p>\n Innerhalb der ersten Durchläufe sollten schon einige Textfelder anzupassen sein. Dabei weist die Prozedur dem Textfeld erstmal den Namen des Feldes als Steuerelementinhalt zu – somit ist dieses Textfeld an das entsprechende Tabellenfeld gebunden.<\/p>\n Danach schreibt die Prozedur zunächst den Namen des aktuellen Tabellenfelds in die Variable strColumnHeader<\/b>, die später dem Bezeichnungsfeld als Beschriftung zugewiesen wird. Anschließend prüft sie noch, ob das Feld gegebenenfalls einen Eintrag für die Eigenschaft Beschriftung <\/b>besitzt. Da die Abfrage von Properties("Caption") <\/b>zum Fehler führen kann, wenn diese Property <\/b>noch nicht angelegt ist, wird die Fehlerbehandlung kurz vorher ausgeschaltet. Die resultierende Beschriftung gelangt dann in die Eigenschaft Caption <\/b>des Bezeichnungsfeldes des aktuellen Textfeldes.<\/p>\n Dann folgt ein für die Ergonomie des Formulars wichtiger Schritt: Über die Funktion Spaltenbreite wird die maximal notwendige Breite für die aktuell vorliegenden Einträge der Lookuptabelle ermittelt (siehe unten) und der Eigenschaft ColumnWidth des Textfeldes zugewiesen. Diese Eigenschaft wirkt sich übrigens nur in der Datenblattansicht von Formularen aus.<\/p>\n Diese Breite wird anschließend aufsummiert, um auch die Gesamtbreite des Formulars an die Breiten der einzelnen Spalten anzupassen.<\/p>\n Dies geschieht gleich im Anschluss an die Bestückung der Textfelder mit Hilfe der Eigenschaft InsideWidth <\/b>des Hauptformulars beziehungsweise der Eigenschaft Width <\/b>des Unterformularsteuerelements. In beiden Fällen legen wir 500 Twips für die Breite des Datensatzmarkierers und ein wenig zusätzliche Luft drauf. Schließlich erhält das Formular über die Eigenschaft Caption <\/b>noch den Namen der Datenherkunft oder, falls vorhanden, den Beschreibungstext. An diesem Punkt können Sie leicht eingreifen, wenn Sie beispielsweise eine eigene Überschrift unterbringen möchten.<\/p>\n Optimale Spaltenbreite ermitteln<\/b><\/p>\n Die Funktion aus Listing 2 ermittelt die Spaltenbreite entsprechend des breitesten Eintrags der Daten, die im betroffenen Textfeld angezeigt werden sollen. Dazu öffnet diese zunächst ein Recordset-Objekt auf Basis der Datenherkunft des Formulars. Anschließend kommt wiederum eine Funktion der WizHook-Klasse zum Einsatz, die in diesem Fall TwipsFromFont heißt und die Breite des Textes in einer bestimmten Schriftart und sonstigen schriftartspezifischen Eigenschaften ermittelt. Diese Eigenschaften liefert das ebenfalls als Parameter übergebene Steuerelement, das in diesem Fall natürlich die Eigenschaften des im Entwurf sichtbaren Textfeldes liefert, aber nicht repräsentativ für die entsprechenden Eigenschaften in der Datenblattansicht ist. Sie sollten die Textfelder daher so auslegen, dass die Formatierung des enthaltenen Textes denen der Datenblattansicht entspricht.<\/p>\n Listing 2: Ermitteln der Spaltenbreite für ein Textfeld<\/p>\n Die Funktion durchläuft in einer Do While<\/b>-Schleife alle Datensätze der Datenherkunft und untersucht genau das an ctl <\/b>gebundene Steuerelement, zum Beispiel VerbrauchsartID<\/b>. Die beiden Parameter lngDX<\/b> und lngDY <\/b>liefern die Breite und Höhe zurück, den der Text wohl einnehmen wird. Innerhalb der Schleife wird der jeweils breiteste Wert gespeichert und schließlich an die aufrufende Prozedur zurückgeliefert.<\/p>\n Vor dem Durchlaufen der eigentlichen Daten ermittelt die Prozedur auch noch die Breite für den im Bezeichnungsfeld des jeweiligen Textfelds angezeigten Text, damit nicht nachher die Spalte genau der Textbreite der Daten entspricht, aber die Spaltenüberschrift nicht mehr lesbar ist (dies passiert gern bei Lookuptabellen, die nur wenige Datensätze enthalten und deren Primärschlüsselwerte daher gern kleiner als zweistellig sind und somit nur wenig Platz einnehmen).<\/p>\n Fehlerbehandlung<\/b><\/p>\n Natürlich soll das Formular auch den Fehlermeldungen von Access vorbeugen. Gerade in Lookupformularen mit vielen Daten kommt es gern vor, dass ein Benutzer einen neuen Eintrag anlegt, der schon längst vorhanden ist.<\/p>\n Wenn Sie für das entsprechende Feld der Lookuptabelle einen eindeutigen Index anlegen, meckert Access automatisch, wenn der Benutzer einen neuen Wert anlegt, der bereits vorliegt. Das gleiche gilt für den Fall, dass ein Benutzer einen Eintrag aus der Lookuptabelle löschen möchte, der bereits mit einem oder mehreren Datensätzen der verknüpften Tabelle in Beziehung steht.<\/p>\n Damit Access keine seiner Fehlermeldungen auf den Weg schickt, sondern der Benutzer eine von uns selbst festgelegte und möglcherweise verständlichere Meldung erhält, legen wir für das Unterformular eine Prozedur an, die durch das Ereignis Bei Fehler <\/b>ausgelöst wird. Die Prozedur sieht wie in Listing 3 aus.<\/p>\n Listing 3: Abfangen von Fehlern, die durch das Hinzufügen doppelter Einträge oder das Löschen verknüpfter Datensätze entstehen<\/p>\n Im Falle eines Fehlers liefert der Parameter DataErr <\/b>die Fehlernummer, die wir innerhalb einer Select Case<\/b>-Bedingung behandeln. Die Fehlernummer 3022 <\/b>steht für den Fehler, der durch das Hinzufügen bereits vorhandener Daten in eine eindeutiges Feld ausgelöst wird. Wir liefern dem Benutzer eine entsprechende Fehlermeldung und sorgen durch Rückgabe des Wertes acDataErrContinue <\/b>dafür, dass die Ausgabe der eigentlichen Fehlermeldung unterbleibt. Außerdem löschen wir mit der Undo<\/b>-Methode des Formulars die Eingabe des Benutzers.<\/p>\n Beim Versuch, bereits verknüpfte Datensätze zu löschen, löst Access Fehler 3200 <\/b>aus – zumindest dann, wenn für die Beziehung zwischen Haupt- und Lookuptabelle referentielle Integrität definiert ist. Auch diesen Fehler behandelt die Prozedur entsprechend.<\/p>\n Zusammenfassung und Ausblick<\/b><\/p>\n Mit der Lösung aus diesem Beitrag können Sie leicht eigene Lookupformulare mit Leben füllen. Wer mehr als drei Felder der Lookuptabelle bearbeiten können möchte, fügt einfach weitere Felder zum Unterformular hinzu und passt den Code entsprechend an. Eine nette Aufgabe wäre es, auch andere Steuerelementtypen wie Kombinationsfelder oder Kontrollkästchen zu realisieren.<\/p>\n Enthaltene Beispieldateien:<\/p>\n Lookupformulare.mdb<\/p>\nDoCmd.OpenForm "frmLookup", OpenArgs:="tblVerbrauchsarten"<\/pre>\n
![\"pic002.png\"](\"..\/fileadmin\/_temp_\/2010_03\/Lookupformulare-web-images\/pic002.png\")
<\/p>\nPrivate Sub cmdOK_Click()\r\n DoCmd.Close\r\nEnd Sub<\/pre>\n
Private Sub Form_Open(Cancel As Integer)\r\n If Len(Nz(Me.OpenArgs, "")) = 0 Then\r\n Cancel = True\r\n End If\r\nEnd Sub<\/pre>\n
Private Sub Form_Load()\r\n Dim db As DAO.Database\r\n Dim obj As Object\r\n Dim strColumnHeader As String\r\n Dim strOpenArgs As String\r\n Dim strCaption As String\r\n Dim i As Integer\r\n Dim intFieldcount As Integer\r\n Dim lngWidth As Long\r\n strOpenArgs = Nz(Me.OpenArgs, "")\r\n Set db = CurrentDb\r\n Me!sfmLookup.Form.Recordsource = strOpenArgs\r\n WizHook.Key = 51488399\r\n Select Case WizHook.ObjTypOfRecordSource(strOpenArgs)\r\n Case 0\r\n On Error Resume Next\r\n db.QueryDefs.Delete "qdfTemp"\r\n On Error Goto 0\r\n Set obj = db.CreateQueryDef("qdfTemp", strOpenArgs)\r\n Case 1\r\n Set obj = db.TableDefs(strOpenArgs)\r\n Case 2\r\n Set obj = db.QueryDefs(strOpenArgs)\r\n End Select\r\n intFieldcount = obj.Fields.Count\r\n If intFieldcount > 3 Then\r\n intFieldcount = 3\r\n End If\r\n For i = 1 To 3\r\n If intFieldcount < i Then\r\n Me!sfmLookup.Form.Controls("txtValue" & i).ColumnHidden = True\r\n Else\r\n Me!sfmLookup.Form.Controls("txtValue" & i).ControlSource = obj.Fields(i - 1).Name\r\n strColumnHeader = obj.Fields(i - 1).Name\r\n On Error Resume Next\r\n strColumnHeader = obj.Fields(i - 1).Properties("Caption")\r\n On Error Goto 0\r\n Me!sfmLookup.Form.Controls("lblValue" & i).Caption = strColumnHeader\r\n Me!sfmLookup.Form.Controls("txtValue" & i).ColumnWidth = (Spaltenbreite(db, _\r\n strOpenArgs, strColumnHeader, Me!sfmLookup.Form.Controls("txtValue" & i)) + 500)\r\n lngWidth = lngWidth + Me!sfmLookup.Form.Controls("txtValue" & i).ColumnWidth\r\n End If\r\n Next i\r\n Me.InsideWidth = Me.InsideWidth - Me.sfmLookup.Width + lngWidth + 500\r\n Me!sfmLookup.Width = lngWidth + 500\r\n strCaption = obj.Name\r\n On Error Resume Next\r\n strCaption = obj.Properties("Description")\r\n On Error Goto 0\r\n Me.Caption = strCaption\r\nEnd Sub<\/pre>\n\n
Public Function Spaltenbreite(db As DAO.Database, strRecordsource As String, _\r\n strColumnHeader As String, ByVal ctl As Control) As Long\r\n Dim rst As DAO.Recordset\r\n Dim lngDX As Long\r\n Dim strText As String\r\n Dim varFeldname As String\r\n Dim lngDY As Long\r\n Dim lngDXMax As Long\r\n Set rst = db.OpenRecordset(strRecordsource)\r\n varFeldname = ctl.ControlSource\r\n WizHook.Key = 51488399\r\n WizHook.TwipsFromFont ctl.FontName, ctl.FontSize, ctl.FontWeight, ctl.FontItalic, _\r\n ctl.FontUnderline, 0, strColumnHeader, 0, lngDXMax, lngDY\r\n Do While Not rst.EOF\r\n strText = Nz(rst.Fields(varFeldname).Value)\r\n WizHook.TwipsFromFont ctl.FontName, ctl.FontSize, ctl.FontWeight, ctl.FontItalic, _\r\n ctl.FontUnderline, 0, strText, 0, lngDX, lngDY\r\n If lngDX > lngDXMax Then\r\n lngDXMax = lngDX\r\n End If\r\n rst.MoveNext\r\n Loop\r\n Spaltenbreite = lngDXMax\r\nEnd Function<\/pre>\n
Private Sub Form_Error(DataErr As Integer, Response As Integer)\r\n Select Case DataErr\r\n Case 3022\r\n MsgBox "Der Wert ''" & Me.txtValue & "'' ist bereits vorhanden.", _\r\n vbOKOnly + vbExclamation, "Doppelte Eingabe"\r\n Me.Undo\r\n Response = acDataErrContinue\r\n Case 3200\r\n MsgBox "Der Wert ''" & Me.txtValue & "'' kann nicht gelöscht werden, da er bereits mit\r\n anderen Daten verknüpft ist.", vbOKOnly + vbExclamation, "Löschen nicht möglich"\r\n Response = acDataErrContinue\r\n End Select\r\nEnd Sub<\/pre>\n
Downloads zu diesem Beitrag<\/h3>\n