![\"Bisher](\"..\/fileadmin\/_temp_\/2026_04\/pic_1610_001.png\")
<\/p>\nIn den ersten beiden Teilen dieser Beitragsreihe haben wir ein universell einsetzbares Filterformular vorgestellt und seine Programmierung beleuchtet. Bisher bietet das Formular für Vergleichswerte schlicht ein Textfeld an. Bei einem Feld wie „AnredeID“ oder „KategorieID“<\/b>, das im aufrufenden Formular über ein Kombinationsfeld dargestellt wird, muss der Benutzer aber die nackte Zahl kennen, nach der er filtern will – wenig komfortabel. In diesem Teil erweitern wir das Filterformular so, dass es solche Lookup-Felder erkennt und im Vergleichsfeld dieselbe Auswahlliste anbietet wie das Originalformular.<\/b><\/p>\nDie Ausgangslage<\/h2>\n
Viele Tabellen arbeiten mit Fremdschlüsseln. In der Kundentabelle aus den ersten Teilen könnte etwa ein Feld AnredeID<\/b> stehen, das auf eine Tabelle tblAnreden<\/b> verweist. Im Datenformular zeigt ein gebundenes Kombinationsfeld dann nicht die ID, sondern den sprechenden Namen an – also „Herr“ statt „1“. Das Filterformular kennt diese Zuordnung jedoch nicht: Es liest nur das Recordset aus und stellt für ein Zahlenfeld ein Texteingabefeld bereit.<\/p>\n
Wie sich das auswirkt, ist in Bild 1 Bild 1<\/b> zu sehen: Der Benutzer möchte nach der Kategorie filtern, bekommt aber nur ein leeres Eingabefeld und müsste die interne ID erraten. Genau hier setzen wir an. Wir wollen die Filterkriterien für Kombinationsfelder so gestalten, dass wir erstens die Bedingungen anpassen und zweitens die vorhandenen Werte als Vergleichswerte auswählen können.<\/p>\n
<\/p>\n
Bild 1: Bisher muss der Benutzer die interne ID des Kategorie-Feldes kennen<\/span><\/b><\/p>\n Bild 2 zeigt die neuen Bedingungen für Nachschlagefelder an:<\/p>\n Bild 2: Der Zwischenschritt: Wir bekommen für Nachschlagefelder neue Bedingungen.<\/span><\/b><\/p>\n Bild 3 zeigt, wie wir die vorhandenen Werte als Vergleichswerte auswählen können.<\/p>\n Bild 3: Das Ziel – im Vergleichsfeld erscheint dieselbe Auswahlliste wie im Datenformular.<\/span><\/b><\/p>\n Die Lösung besteht aus drei Bausteinen. Erstens muss das Filterformular beim Einlesen der Felder erkennen, ob ein Feld im aufrufenden Formular über ein Kombinationsfeld dargestellt wird, und sich dessen Datensatzherkunft merken.<\/p>\n Zweitens braucht jede Filterzeile ein zusätzliches Kombinationsfeld als alternatives Wertfeld. Drittens muss beim Aufbau des SQL-Ausdrucks der gebundene Wert – also die ID – verwendet werden, nicht der angezeigte Text.<\/p>\n Der angenehme Nebeneffekt: An der eigentlichen SQL-Logik in GetFilterausdruck<\/b> ändert sich nichts.<\/p>\n Da das neue Kombinationsfeld seinen gebundenen Wert liefert und der zugrunde liegende Feldtyp (Zahl oder Text) erhalten bleibt, quotiert die Funktion den Wert wie gewohnt – Zahlen ohne, Texte mit Anführungszeichen.<\/p>\n Bisher haben wir beim Aufrufen des Filterformulars einen Verweis auf das aufrufende Formular sowie auf das zu filternde Recordset übergeben. Um für ein zu filterndes Nachschlagefeld jedoch die notwendigen Informationen zu holen, benötigen wir einen Verweis auf das jeweilige Nachschlagefeld. Deshalb haben wir den Aufruf des Filterformulars so angepasst, dass wir keinen Verweis auf das zu filternde Recordset übergeben, sondern einen auf das Form<\/b>-Objekt, welches das Recordset anzeigt.<\/p>\n Der Aufruf ändert sich also wie folgt:<\/p>\n In Form_frmFilter <\/b>haben wir dazu eine neue Variable hinterlegt:<\/p>\n Sie kann über diese öffentliche Property Set<\/b>-Prozedur gefüllt werden:<\/p>\n Beim Öffnen liest das Filterformular in LadeFelder<\/b> alle Felder des Recordsets aus. An dieser Stelle ergänzen wir die Erkennung. Für jedes Feld prüfen wir, ob im aufrufenden Formular ein an dieses Feld gebundenes Kombinationsfeld existiert. Die dazu nötigen Metadaten halten wir in einem benutzerdefinierten Typ fest, den wir wie folgt definieren:<\/p>\n Das Array m_Kombi<\/b> speichert für jedes Recordset-Feld die komplette Konfiguration eines eventuell vorhandenen Kombinationsfelds:<\/p>\n Die Matrix m_bolAktKombi<\/b> merkt sich pro Filterzeile, ob das dort gerade gewählte Feld ein Lookup-Feld ist – analog zur bereits vorhandenen Feldtyp-Matrix:<\/p>\n Die eigentliche Erkennung erledigt ErmittleKombiInfo<\/b>. Die Prozedur sucht im datentragenden Formular nach einem Steuerelement, dessen Datensatzherkunft (die Eigenschaft ControlSource<\/b>) dem Feldnamen entspricht, und kopiert dessen Eigenschaften in die Struktur (siehe Listing 1).<\/p>\n Listing 1: ErmittleKombiInfo merkt sich die Liste eines gebundenen Kombinationsfelds<\/span><\/b><\/p>\n Hier ist m_frmDaten<\/b> der entscheidende Punkt. Das zu filternde Recordset gehört immer zu genau einem Formular – entweder dem Hauptformular selbst oder dem konkret angegebenen Unterformular.<\/p>\n Und genau in diesem Formular sitzen auch die gebundenen Kombinationsfelder, deren Liste wir brauchen. Die Funktion SucheKombiSteuerelement<\/b> durchsucht deshalb Steuerelemente dieses einen Formulars, wie Listing 2 zeigt.<\/p>\n Listing 2: SucheKombiSteuerelement durchsucht genau das datentragende Formular<\/span><\/b><\/p>\n Damit dieses datentragende Formular überhaupt zur Verfügung steht, übergeben wir es, wie oben bereits beschrieben, statt wie bisher nur das Recordset.<\/p>\n Für ein Lookup-Feld ergeben nur diskrete Vergleiche Sinn. Operatoren wie Größer als<\/b> oder Enthält<\/b> wären hier unpassend, weil der Benutzer ja einen konkreten Listeneintrag auswählt. Gleichzeitig wollen wir für die Nachschlagefelder keine Eingabe von Vergleichsausdrücken mit Platzhaltern erlauben. Deshalb spendieren wir dem Modul mdlFilter<\/b> eine eigene, schlanke Bedingungsliste, die das folgende Listing wiedergibt:<\/p>\n Die Prozedur FeldGewaehlt<\/b> ist die zentrale Reaktion auf die Feldauswahl (erster Teil siehe Listing 3). Sie wird von allen 25 After_Update<\/b>-Ereignissen der cboFeld<\/b>-Kombinationsfelder über die Parameter g <\/b>(Gruppe) und z <\/b>(Zeile) aufgerufen und richtet die betreffende Filterzeile vollständig ein. Zuerst liest sie den gewählten Feldnamen aus, wobei das umschließende Nz <\/b>den noch leeren Zustand abfängt. Ist kein Feld gewählt – etwa weil der Benutzer die Auswahl wieder geleert hat -, bricht die Prozedur sofort ab, denn ohne Feld gibt es nichts einzurichten.<\/p>\n Listing 3: Die Prozedur FeldGewaehlt (Teil 1)<\/span><\/b><\/p>\n Den Feldtyp liest die Prozedur nicht erneut aus dem Recordset, sondern aus dem beim Öffnen gefüllten Array m_strFeldnamen<\/b>. Bei einem Treffer übernimmt sie den zugehörigen Typ aus m_lngFeldtypen <\/b>und merkt sich zusätzlich den Array-Index in intIdx<\/b>. Dieser Index ist gleich doppelt nützlich: Er identifiziert das Feld eindeutig und dient kurz darauf als Schlüssel in die Kombi-Metadaten.<\/p>\n Der ermittelte Typ wandert in die Matrix m_lngAktFeldtyp<\/b>, damit spätere Ereignisse derselben Zeile – die Tastaturvalidierung oder der SQL-Aufbau – ihn ohne erneute Suche zur Hand haben.<\/p>\n Dass intIdx <\/b>mit dem Wert -1 <\/b>startet, ist Absicht: So bleibt ein nicht gefundenes Feld erkennbar.<\/p>\n Im nächsten Schritt entscheidet sich, ob es sich um ein Lookup-Feld handelt. Das Flag m_bolAktKombi <\/b>für diese Zeile wird zunächst auf False <\/b>gesetzt und nur dann auf True <\/b>eingestellt, wenn ein gültiger Index vorliegt und die zugehörige Kombi-Information IstKombi <\/b>meldet – also beim Laden ein an dieses Feld gebundenes Kombinationsfeld im datentragenden Formular gefunden wurde. In der geschachtelten If<\/b>-Konstruktion wird erst der Index geprüft, bevor mit m_Kombi(intIdx) <\/b>auf das Array zugegriffen wird, damit ein ungültiger Index keinen Laufzeitfehler auslöst.<\/p>\n Vom Kombi-Flag hängt nun ab, welche Operatorenliste das Bedingungsfeld erhält. Für ein Lookup-Feld liefert GetBedingungRowsourceKombi <\/b>die schlanke Liste mit nur den vier sinnvollen Vergleichen, für alle anderen Felder kommt wie gewohnt GetBedingungRowsource <\/b>mit der feldtypabhängigen Liste zum Einsatz.<\/p>\n Anschließend wird das Bedingungsfeld aktiviert – beim Anlegen der Zeile war es deaktiviert – und sein Wert auf Null <\/b>gesetzt (siehe Listing 4). Dieses Leeren ist wichtig, denn beim Wechsel des Feldes könnte eine zuvor gewählte Bedingung zum neuen Feldtyp gar nicht mehr passen.<\/p>\n Listing 4: Die Prozedur FeldGewaehlt (Teil 2)<\/span><\/b><\/p>\n Danach blendet die Prozedur sämtliche Wertfelder der Zeile aus und setzt deren Positionen zurück. Welches Wertfeld tatsächlich gebraucht wird, steht zu diesem Zeitpunkt noch nicht fest – eine Bedingung ist ja noch nicht gewählt -, also wird vorsorglich alles ausgeblendet. Das Zurücksetzen der Left<\/b>-Eigenschaften von txtWert <\/b>und txtDatum <\/b>auf ihre Ausgangswerte ist dabei mehr als Kosmetik: Beide Felder werden bei bestimmten Bedingungen wie Datum „Ist zwischen“ oder „Letzte X Tage“ per Code an andere Positionen verschoben. Ohne das Zurücksetzen bliebe ein Feld nach einem Feldwechsel an der falschen Stelle stehen.<\/p>\n Handelt es sich um ein Lookup<\/b>-Feld, wird das Kombinationsfeld cboWert <\/b>der Zeile mit den gemerkten Eigenschaften des Originalfelds bestückt: Datensatzherkunft, Spaltenanzahl, Spaltenbreiten und gebundene Spalte. Gerade die letzten drei sind entscheidend. Sie sorgen dafür, dass das Feld dieselbe – meist mehrspaltige – Darstellung mit ausgeblendeter ID-Spalte zeigt wie das Original und über BoundColumn <\/b>später den richtigen gebundenen Wert, also die ID, liefert. Das tatsächliche Einblenden übernimmt allerdings nicht FeldGewaehlt<\/b>, sondern erst BedingungGewaehlt<\/b>, sobald eine Bedingung feststeht.<\/p>\n Den Abschluss bilden zwei Aufgaben rund um die Oberfläche. War die gerade befüllte Zeile die letzte aktive der Gruppe und das Maximum von fünf Zeilen noch nicht erreicht, blendet die Prozedur eine weitere leere Eingabezeile ein, erhöht den Zähler m_intAktiveZeilen <\/b>und passt die Formularhöhe an – so steht nach jeder Feldauswahl automatisch eine frische Zeile bereit.<\/p>\n Der abschließende Aufruf von AktualisiereSchaltflaechen <\/b>aktiviert schließlich die Schaltflächen zum Anwenden und Zurücksetzen und steuert die Sichtbarkeit der Schaltfläche zum Hinzufügen einer ODER<\/b>-Gruppe.<\/p>\n Damit auch das mehrfache Löschen und Wiederherstellen von Zeilen sauber funktioniert, berücksichtigen wir das neue Steuerelement zudem an allen Stellen, an denen die übrigen Wertfelder bereits verwaltet werden – also in ZeileSetzenSichtbar<\/b>, PositioniereZeilen<\/b>, ZeileLeeren<\/b> und ZeileWiederherstellen<\/b>. Das Muster ist dort jeweils dasselbe wie für txtWert<\/b> – ein- und ausblenden, Position setzen, Wert leeren. Die Änderungen wollen wir hier aus Platzgründen nicht vollständig abbilden.<\/p>\n Jetzt kommt der entscheidende Punkt. Ein Kombinationsfeld zeigt zwar einen Text an, liefert über seine Value-Eigenschaft aber den Wert der gebundenen Spalte – bei einem Fremdschlüssel also die ID. Beim Auslesen in cmdAnwenden_Click<\/b> ziehen wir den Kombi-Fall deshalb vor und greifen auf cboWert<\/b> statt auf das Textfeld zu. Der entsprechende Ausschnitt sieht wie folgt aus:<\/p>\n Den so ermittelten Wert übergeben wir wie bisher an GetFilterausdruck<\/b> – zusammen mit dem unveränderten Feldtyp aus m_lngAktFeldtyp<\/b>. Dadurch setzt die Funktion eventuelle Anführungszeichen korrekt: Bei einem Zahlen-Fremdschlüssel entsteht ein Ausdruck wie (KategorieID = 3)<\/b>, bei einer Textbindung etwa (Land = ‚DE‘)<\/b>. Die SQL-Erzeugung selbst mussten wir also kein einziges Mal anfassen.<\/p>\n Bleibt die Frage, wie die 25 neuen Steuerelemente in das Formular kommen. Sie von Hand anzulegen, wäre mühsam und fehleranfällig – schließlich müssen alle exakt dem Namensschema cboWert_g_z<\/b> folgen. Wenn Sie also nicht ohnehin die neue Version des Filterformulars in Ihre Anwendung übernehmen wollen, weil Sie dieses gegebenenfalls bereits angepasst haben, können Sie die Kombinationsfelder mit der Prozedur aus Listing 5 einfügen.<\/p>\n Listing 5: Nach dem Aufruf von ErstelleCboWert sind alle 25 Kombinationsfelder vorhanden<\/span><\/b><\/p>\n Die Prozedur öffnet frmFilter<\/b> versteckt im Entwurf und legt mit CreateControl<\/b> die fehlenden Kombinationsfelder an. Bereits vorhandene Felder überspringt es – der Aufruf lässt sich also gefahrlos wiederholen. Datensatzherkunft, Spalten und Position bleiben hier bewusst leer beziehungsweise auf Standardwerten: Das Formularmodul setzt sie ja zur Laufzeit, sobald der Benutzer ein Feld wählt. Wichtig ist allein der korrekte Name und die feste Startposition bei Left = 4440<\/b>.<\/p>\n Den Aufruf erledigt man einmalig im Direktfenster mit ErstelleCboWert<\/b>. Nach kurzer Zeit meldet die Prozedur, wie viele Felder angelegt wurden (siehe Bild 4).<\/p>\n Bild 4: Die neuen Kombinationsfelder im Filter-Formular<\/span><\/b><\/p>\n Damit ist die Erweiterung fertig. Filtert der Benutzer nun nach einem Lookup-Feld, wählt er den Wert bequem aus derselben Liste, die er aus dem Datenformular kennt – ganz ohne interne IDs. Bild 5 zeigt einen kombinierten Filter, bei dem eine Bedingung das Kategorie-Kombinationsfeld nutzt und eine zweite wie gewohnt ein Textfeld.<\/p>\n Bild 5: Lookup-Feld und klassisches Textfeld lassen sich frei kombinieren.<\/span><\/b><\/p>\n Für alle Feldtypen, die kein gebundenes Kombinationsfeld im Originalformular haben, bleibt das Verhalten unverändert: Text-, Zahlen-, Datums- und Ja\/Nein-Felder zeigen weiterhin ihre gewohnten Eingabefelder. Die Erweiterung greift ausschließlich dort, wo sie einen echten Mehrwert bietet.<\/p>\n Mit überschaubarem Aufwand haben wir das Filterformular um eine komfortable Funktion erweitert. Wir können nun nicht nur nach Zahlenwerten, Datumsangaben, Ja\/Nein und Texten suchen, sondern auch gezielt die Werte aus Nachschlagefeldern als Suchkriterien angeben.<\/p>\n Dabei haben wir nicht nur die Vergleichsoperatoren entsprechend angepasst, sondern auch noch Kombinationsfelder hinzugefügt, mit denen sich die Vergleichswerte auf Basis der tatsächlich enthaltenen Werte einfach auswählen lassen.<\/p>\n In einer weiteren Folge dieser Beitragsreihe fügen wir noch eine Funktion hinzu, mit der wir die einmal eingegebenen Filterkriterien unter dem gewünschten Namen speichern und wiederherstellen können.<\/p>\n","protected":false},"excerpt":{"rendered":" In den ersten beiden Teilen dieser Beitragsreihe haben wir ein universell einsetzbares Filterformular vorgestellt und seine Programmierung beleuchtet. Bisher bietet das Formular für Vergleichswerte schlicht ein Textfeld an. Bei einem Feld wie „AnredeID“ oder „KategorieID“, das im aufrufenden Formular über ein Kombinationsfeld dargestellt wird, muss der Benutzer aber die nackte Zahl kennen, nach der er filtern will – wenig komfortabel. In diesem Teil erweitern wir das Filterformular so, dass es solche Lookup-Felder erkennt und im Vergleichsfeld dieselbe Auswahlliste anbietet wie das Originalformular.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"_uf_show_specific_survey":0,"_uf_disable_surveys":false,"footnotes":""},"categories":[662026,66042026,44000027],"tags":[],"class_list":["post-55001610","post","type-post","status-publish","format-standard","hentry","category-662026","category-66042026","category-Loesungen"],"yoast_head":"\n![\"Der](\"..\/fileadmin\/_temp_\/2026_04\/pic_1610_002.png\")
<\/p>\n\n
![\"Das](\"..\/fileadmin\/_temp_\/2026_04\/pic_1610_003.png\")
<\/p>\nDas Konzept<\/h2>\n
Vorbereitung: Übergabe des zu filternden Recordsets durch Formular ersetzen<\/h2>\n
Private Sub <\/span>cmdFilter_Click()\r\n DoCmd.OpenForm \"frmFilter\"\r\n Set<\/span> Forms!frmFilter.CallingForm = Me\r\n Set<\/span> Forms!frmFilter.RecordsetForm = _\r\n Me.sfmDatenMitFilter.Form\r\nEnd Sub<\/span><\/pre>\nPrivate <\/span>m_frmDaten As <\/span>Form<\/pre>\nPublic Property Set<\/span> <\/span>CallingForm(frm As <\/span>Form)\r\n Set<\/span> m_frmAufrufend = frm\r\nEnd Property<\/span><\/pre>\nSchritt 1: Lookup-Felder erkennen<\/h2>\n
Private <\/span>Type TKombiInfo\r\n IstKombi As Boolean<\/span>\r\n RowSource As String<\/span>\r\n RowSourceType As String<\/span>\r\n ColumnCount As Integer<\/span>\r\n ColumnWidths As String<\/span>\r\n BoundColumn As Integer<\/span>\r\nEnd Type<\/pre>\nPrivate <\/span>m_Kombi() As <\/span>TKombiInfo<\/pre>\nPrivate <\/span>m_bolAktKombi(1 To 5, 1 To 5) As Boolean<\/span><\/pre>\nPrivate Sub <\/span>ErmittleKombiInfo(strFeld As String<\/span>, ByRef tKombi As <\/span>TKombiInfo)\r\n Dim <\/span>cbo As <\/span>ComboBox\r\n tKombi.IstKombi = False<\/span>\r\n If <\/span>m_frmAufrufend Is Nothing Then<\/span>\r\n Exit Sub<\/span>\r\n End If<\/span>\r\n Set<\/span> cbo = SucheKombiSteuerelement(m_frmAufrufend, strFeld)\r\n If <\/span>cbo Is Nothing Then<\/span>\r\n Exit Sub<\/span>\r\n End If<\/span>\r\n If <\/span>Len<\/span>(Nz(cbo.RowSource, \"\")) = 0 Then<\/span>\r\n Exit Sub<\/span>\r\n End If<\/span>\r\n tKombi.IstKombi = True<\/span>\r\n tKombi.RowSource = cbo.RowSource\r\n tKombi.RowSourceType = cbo.RowSourceType\r\n tKombi.ColumnCount = cbo.ColumnCount\r\n tKombi.ColumnWidths = Nz(cbo.ColumnWidths, \"\")\r\n tKombi.BoundColumn = cbo.BoundColumn\r\nEnd Sub<\/span><\/pre>\nPrivate Function <\/span>SucheKombiSteuerelement(frm As <\/span>Form, strFeld As String<\/span>) As <\/span>ComboBox\r\n Dim <\/span>ctl As <\/span>Control\r\n For Each ctl In frm.Controls\r\n If <\/span>ctl.ControlType = acComboBox Then<\/span>\r\n If <\/span>StrComp(Nz(ctl.ControlSource, \"\"), strFeld, vbTextCompare) = 0 Then<\/span>\r\n Set<\/span> SucheKombiSteuerelement = ctl\r\n Exit Function<\/span>\r\n End If<\/span>\r\n End If<\/span>\r\n Next<\/span> ctl\r\nEnd Function<\/span><\/pre>\nSchritt 2: Passende Bedingungen anbieten<\/h2>\n
Public Function <\/span>GetBedingungRowsourceKombi() As String<\/span>\r\n GetBedingungRowsourceKombi = _\r\n \"Gleich;Nicht gleich;Ist leer;Ist nicht leer\"\r\nEnd Function<\/span><\/pre>\nPrivate Sub <\/span>FeldGewaehlt(g As Integer<\/span>, z As Integer<\/span>)\r\n Dim <\/span>strFeld As String<\/span>\r\n Dim <\/span>lngFeldtyp As Long<\/span>\r\n Dim <\/span>i As Integer<\/span>\r\n Dim <\/span>intIdx As Integer<\/span>\r\n strFeld = Nz(Me(\"cboFeld_\" & g & \"_\" & z).Value, \"\")\r\n If <\/span>Len<\/span>(strFeld) = 0 Then<\/span> Exit Sub<\/span>\r\n intIdx = -1\r\n For i = 0 To m_intFeldanzahl - 1\r\n If <\/span>m_strFeldnamen(i) = strFeld Then<\/span>\r\n lngFeldtyp = m_lngFeldtypen(i)\r\n intIdx = i\r\n Exit For<\/span>\r\n End If<\/span>\r\n Next<\/span> i\r\n m_lngAktFeldtyp(g, z) = lngFeldtyp\r\n m_bolAktKombi(g, z) = False<\/span>\r\n If <\/span>intIdx >= 0 Then<\/span>\r\n If <\/span>m_Kombi(intIdx).IstKombi Then<\/span> m_bolAktKombi(g, z) = True<\/span>\r\n End If<\/span>\r\n If <\/span>m_bolAktKombi(g, z) Then<\/span>\r\n Me(\"cboBedingung_\" & g & \"_\" & z).RowSource = GetBedingungRowsourceKombi()\r\n Else<\/span>\r\n Me(\"cboBedingung_\" & g & \"_\" & z).RowSource = GetBedingungRowsource(lngFeldtyp)\r\n End If<\/span>\r\n ...<\/pre>\n ...\r\n Me(\"cboBedingung_\" & g & \"_\" & z).Enabled = True<\/span>\r\n Me(\"cboBedingung_\" & g & \"_\" & z).Value = Null\r\n Me(\"txtWert_\" & g & \"_\" & z).Visible = False<\/span>\r\n Me(\"txtWert_\" & g & \"_\" & z).Left<\/span> = 4440\r\n Me(\"txtDatum_\" & g & \"_\" & z).Visible = False<\/span>\r\n Me(\"txtDatum_\" & g & \"_\" & z).Left<\/span> = 6560\r\n Me(\"txtDatumA_\" & g & \"_\" & z).Visible = False<\/span>\r\n Me(\"txtWert2_\" & g & \"_\" & z).Visible = False<\/span>\r\n Me(\"cboDatumstyp_\" & g & \"_\" & z).Visible = False<\/span>\r\n Me(\"cboJaNein_\" & g & \"_\" & z).Visible = False<\/span>\r\n Me(\"cboWert_\" & g & \"_\" & z).Visible = False<\/span>\r\n If <\/span>m_bolAktKombi(g, z) Then<\/span>\r\n With<\/span> Me(\"cboWert_\" & g & \"_\" & z)\r\n .RowSourceType = m_Kombi(intIdx).RowSourceType\r\n .RowSource = m_Kombi(intIdx).RowSource\r\n .ColumnCount = m_Kombi(intIdx).ColumnCount\r\n .ColumnWidths = m_Kombi(intIdx).ColumnWidths\r\n .BoundColumn = m_Kombi(intIdx).BoundColumn\r\n .Left<\/span> = 4440\r\n .Value = Null\r\n End With<\/span>\r\n End If<\/span>\r\n If <\/span>z = m_intAktiveZeilen(g) And z < cMaxZeilen Then<\/span>\r\n m_intAktiveZeilen(g) = z + 1\r\n ZeileEinblenden g, z + 1\r\n AktualisiereFormularHoehe\r\n End If<\/span>\r\n AktualisiereSchaltflaechen\r\nEnd Sub<\/span><\/pre>\nSchritt 3: Übrige Prozeduren anpassen<\/h2>\n
Schritt 4: Den richtigen Wert für SQL<\/h2>\n
If <\/span>m_bolAktKombi(g, z) Then<\/span>\r\n strWert = Nz(Me(\"cboWert_\" & g & \"_\" & z).Value, \"\")\r\nElse<\/span>\r\n strWert = Nz(Me(\"txtWert_\" & g & \"_\" & z).Value, \"\")\r\n If <\/span>Len<\/span>(strWert) = 0 Then<\/span>\r\n strWert = Nz(Me(\"txtDatum_\" & g & \"_\" & z).Value, \"\")\r\n End If<\/span>\r\nEnd If<\/span><\/pre>\nDie 25 Kombinationsfelder per Code anlegen<\/h2>\n
Public Sub <\/span>ErstelleCboWert()\r\n Const cFormName As String<\/span> = \"frmFilter\"\r\n Dim <\/span>frm As <\/span>Form\r\n Dim <\/span>ctlNeu As <\/span>Control\r\n Dim <\/span>g As Integer<\/span>, z As Integer<\/span>\r\n Dim <\/span>strName As String<\/span>\r\n DoCmd.OpenForm cFormName, acDesign, , , , acHidden\r\n Set<\/span> frm = Forms(cFormName)\r\n For g = 1 To 5\r\n For z = 1 To 5\r\n strName = \"cboWert_\" & g & \"_\" & z\r\n If <\/span>SteuerelementVorhanden(frm, strName) Then<\/span> GoTo Weiter\r\n Set<\/span> ctlNeu = CreateControl(cFormName, acComboBox, acDetail, \"\", \"\", 4440, 0, 1985, 300)\r\n ctlNeu.Name = strName\r\n ctlNeu.Visible = False<\/span>\r\n ctlNeu.LimitToList = True<\/span>\r\n ctlNeu.RowSourceType = \"Value List\"\r\n ctlNeu.ColumnCount = 1\r\n ctlNeu.BoundColumn = 1\r\nWeiter:\r\n Set<\/span> ctlNeu = Nothing\r\n Next<\/span> z\r\n Next<\/span> g\r\n DoCmd.Save acForm, cFormName\r\n DoCmd.Close acForm, cFormName, acSaveYes\r\nEnd Sub<\/span><\/pre>\n![\"Die](\"..\/fileadmin\/_temp_\/2026_04\/pic_1610_004.png\")
<\/p>\nDas Ergebnis in der Praxis<\/h2>\n
![\"Lookup-Feld](\"..\/fileadmin\/_temp_\/2026_04\/pic_1610_005.png\")
<\/p>\nZusammenfassung und Ausblick<\/h2>\n