Im ersten Teil dieser Beitragsreihe haben wir gezeigt, wie das Filterformular in eine eigene Datenbank eingebaut und bedient wird. In diesem zweiten Teil werfen wir einen Blick hinter die Kulissen: Wie ist das Filterformular aufgebaut, wie erkennt es den Feldtyp aus dem Recordset, wie baut es den SQL-WHERE-String zusammen, wie funktioniert die dynamische Höhenanpassung – und welche technischen Besonderheiten mussten gelöst werden. Einige dieser Lösungen sind nicht auf den ersten Blick offensichtlich, liefern aber wertvolle Denkanstöße für eigene Projekte.<\/b><\/p>\nArchitektur: Zwei Bausteine, eine Schnittstelle<\/h2>\n
Das Filterformular besteht aus zwei Bausteinen: dem Modul mdlFilter<\/b> mit allen Hilfsfunktionen und dem Formularmodul Form_frmFilter<\/b> mit der gesamten Steuerlogik. Die Trennung ist bewusst gewählt: mdlFilter<\/b> enthält ausschließlich Funktionen ohne Bindung an ein konkretes Formular – Feldtyperkennung, SQL-Aufbau, Datumsparsen, Wertevalidierung.<\/p>\n
Das Formularmodul nutzt diese Funktionen und kümmert sich um alles was mit der Benutzeroberfläche zu tun hat: Steuerelemente ein- und ausblenden, Positionen setzen, Ereignisse verarbeiten.<\/p>\n
Diese klare Aufgabentrennung hat einen praktischen Vorteil: mdlFilter<\/b> kann unverändert wiederverwendet werden wenn das Formular künftig angepasst oder durch eine andere Darstellung ersetzt wird.<\/p>\n
Die Kommunikation zwischen dem Filterformular und dem aufrufenden Formular läuft über zwei öffentliche Eigenschaften und eine öffentliche Prozedur. Das aufrufende Formular übergibt beim Öffnen über CallingForm<\/b> eine Referenz auf sich selbst und über RecordsetForm<\/b> das zu filternde Recordset.<\/p>\n
Das Filterformular ruft später FilterAnwenden<\/b> im aufrufenden Formular auf und übergibt den fertigen WHERE<\/b>-String als Parameter. Diese drei Elemente bilden die vollständige Schnittstelle – mehr ist für den Einbau nicht notwendig. Das folgende Listing zeigt die beiden Property-Prozeduren:<\/p>\n Der Parameter RecordsetForm<\/b> ist als Object<\/b> typisiert statt als konkreter Recordset-Typ.<\/p>\n Das hat zwei Vorteile: Erstens funktioniert die Übergabe sowohl mit einem DAO-Recordset als auch mit einem ADODB-Recordset, ohne dass der Aufrufer sich um den Typ kümmern muss.<\/p>\n Zweitens ist das Filterformular damit für künftige Erweiterungen vorbereitet. Das Flag m_bolDAO<\/b> wird über TypeName<\/b> gesetzt: Ein DAO-Recordset trägt den Typnamen Recordset<\/b> oder Recordset2<\/b> – je nach Access-Version und Datenbanktyp – ein ADODB-Recordset dagegen nicht.<\/p>\n Dieses Flag ist entscheidend für die Feldtyperkennung, wie wir im nächsten Abschnitt sehen werden.<\/p>\n Sobald RecordsetForm<\/b> gesetzt wird, ruft die Property-Prozedur automatisch LadeFelder<\/b> auf. Diese Prozedur liest alle Felder des Recordsets aus, bestimmt für jedes den Feldtyp und befüllt die RowSource<\/b> aller 25 cboFeld<\/b>-Kombinationsfelder mit den Feldnamen.<\/p>\n Das bedeutet: Der Benutzer sieht im Feldauswahl-Dropdown sofort nach dem Öffnen alle verfügbaren Felder – ohne dass eine manuelle Konfiguration der Felder notwendig wäre. Das Filterformular passt sich damit automatisch an jedes Formular an, dem es zugewiesen wird.<\/p>\n Das Filterformular unterstützt bis zu fünf ODER<\/b>-Gruppen mit je fünf Filterzeilen – also 25 Zeilen insgesamt.<\/p>\n Jede Zeile besteht aus sieben Steuerelementen die je nach Feldtyp und gewählter Bedingung wechselweise ein- und ausgeblendet werden.<\/p>\n Die Steuerelemente pro Zeile im Überblick: cboFeld_g_z<\/b> für die Feldauswahl, cboBedingung_g_z<\/b> für den Vergleichsoperator, cboDatumstyp_g_z<\/b> für den Datumstyp bei Datumsfeldern, txtWert_g_z<\/b> für den Vergleichswert bei Text- und Zahlenfeldern, txtDatum_g_z<\/b> für konkrete Datumseingaben, txtDatumA_g_z<\/b> für den Bis-Wert bei Datum-Zwischen-Bedingungen, txtWert2_g_z<\/b> für den Bis-Wert bei Zahlen-Zwischen-Bedingungen und cmdLoeschen_g_z<\/b> zum Entfernen der Zeile.<\/p>\n Das Namensschema ist einheitlich: g<\/b> steht für die Gruppennummer (1 bis 5), z<\/b> für die Zeilennummer (1 bis 5).<\/p>\n Alle Ereignisprozeduren im Formularmodul folgen demselben Schema und delegieren an generische Hilfsprozeduren: cboFeld_1_1_AfterUpdate<\/b> ruft FeldGewaehlt 1, 1<\/b> auf, cmdLoeschen_2_3_Click<\/b> ruft ZeileLeeren 2, 3<\/b> auf.<\/p>\n Das macht den Code überschaubar trotz der großen Zahl von Ereignisprozeduren. Für alle 25 Zeilen entstehen so je Ereignistyp 25 identisch aufgebaute Einzeiler. Die eigentliche Logik steckt in den generischen Hilfsprozeduren die g<\/b> und z<\/b> als Parameter erhalten und alle Steuerelementnamen daraus zusammensetzen – also etwa Me(„cboFeld_“ & g & „_“ & z)<\/b>.<\/p>\n Alle 175 Einzelsteuerelemente liegen im Formular an der Y-Position 0, also übereinander gestapelt. Nur die jeweils aktiven Zeilen werden sichtbar gemacht und an ihre richtige vertikale Position verschoben.<\/p>\n Unsichtbare Zeilen bleiben bei Y=0 und nehmen keinen Platz ein. Diese Technik ist der zentrale Trick der es überhaupt ermöglicht, die Höhe des Formulars dynamisch zu steuern: Access richtet die Höhe des Detailbereichs nicht nach den unsichtbaren Steuerelementen aus, sondern nach dem Wert der Eigenschaft Section(acDetail).Height<\/b> – und den setzen wir per Code.<\/p>\n Würden die unsichtbaren Steuerelemente an ihren ursprünglichen Positionen verbleiben, würde Access den Detailbereich nicht kleiner darstellen als notwendig um alle Elemente – auch die unsichtbaren – zu umschließen. Das Formular wäre dann stets so hoch wie alle 25 Zeilen zusammen.<\/p>\n Sobald das Recordset übergeben wurde, liest LadeFelder<\/b> alle Felder aus und bestimmt für jedes den Feldtyp. Das Filterformular unterscheidet vier eigene Feldtypen, die als öffentliche Konstanten in mdlFilter<\/b> definiert sind: cFeldtypText<\/b> (1), cFeldtypZahl<\/b> (2), cFeldtypDatum<\/b> (3) und cFeldtypJaNein<\/b> (4).<\/p>\n Diese vier Typen steuern, welche Vergleichsoperatoren angeboten werden, welches Eingabefeld erscheint und wie der Wert später im SQL-Ausdruck gequotet wird. Die Zuordnung vom nativen Typwert des Recordset-Feldes auf einen dieser vier Typen übernimmt die Funktion GetFeldtyp<\/b> in mdlFilter<\/b>. Sie erhält neben dem numerischen Typwert auch das Flag bolDAO<\/b> (siehe Listing 1).<\/p>\n Listing 1: GetFeldtyp unterscheidet DAO- und ADODB-Typnummern<\/span><\/b><\/p>\n Warum ist die strikte Trennung zwischen DAO und ADODB notwendig? Der Grund ist eine handfeste Kollision der Typnummern: DAO verwendet für den Typ dbDouble<\/b> (Gleitkommazahl) den Wert 7, ADODB verwendet denselben Wert 7 für adDate<\/b> (Datum).<\/p>\n Eine einheitliche Behandlung beider Bibliotheken mit derselben Fallunterscheidung ist daher nicht möglich. Würde man in einem DAO-Recordset den Wert 7 als Datum interpretieren, würden alle Double-Felder fälschlicherweise als Datumsfelder behandelt – mit entsprechend falschen Vergleichsoperatoren und Datumsformatierung im SQL-Ausdruck als Folge.<\/p>\n Die Lösung ist das Flag m_bolDAO<\/b> das beim Setzen von RecordsetForm<\/b> automatisch über TypeName<\/b> bestimmt wird. Im DAO-Zweig von GetFeldtyp<\/b> wird der Wert 7 korrekt als Zahl (dbDouble<\/b>) behandelt, während DAO-Datumsfelder den eindeutigen Wert 8 (dbDate<\/b>) tragen. Im ADODB-Zweig wird 7 dagegen korrekt als Datum (adDate<\/b>) behandelt, während ADODB-Boolean-Felder den Wert 11 (adBoolean<\/b>) haben.<\/p>\n Das bolDAO<\/b>-Flag ist damit nicht nur eine technische Notwendigkeit für den aktuellen Stand des Filterformulars – es ist gleichzeitig die Vorbereitung für die geplante Erweiterung auf ADODB-gebundene Formulare.<\/p>\n Wird das Filterformular künftig mit einem ADODB-Recordset aufgerufen, wird m_bolDAO<\/b> automatisch auf False<\/b> gesetzt und der ADODB-Zweig kommt zum Einsatz, ohne dass an GetFeldtyp<\/b> etwas geändert werden muss.<\/p>\n Der Aufruf in LadeFelder<\/b> ist entsprechend einfach gehalten:<\/p>\n Die ermittelten Feldnamen und Feldtypen werden in den Modulvariablen m_strFeldnamen<\/b> und m_lngFeldtypen<\/b> gespeichert.<\/p>\n Auf diese Arrays greift das Formularmodul später zu, wenn der Benutzer ein Feld auswählt. Der Feldtyp steckt dann bereits im Array und muss nicht erneut aus dem Recordset ausgelesen werden.<\/p>\n Das ist effizienter und vermeidet Probleme, wenn das Recordset zwischenzeitlich geschlossen oder verändert wurde.<\/p>\n Sobald der Benutzer ein Feld auswählt, reagiert FeldGewaehlt<\/b> auf das AfterUpdate<\/b>-Ereignis des jeweiligen cboFeld<\/b>-Kombinationsfelds. Die Prozedur ermittelt den Feldtyp des gewählten Felds aus dem gespeicherten Array und befüllt cboBedingung<\/b> mit den passenden Operatoren über GetBedingungRowsource<\/b> (siehe Listing 2).<\/p>\n Listing 2: GetBedingungRowsource liefert die passenden Operatoren je Feldtyp<\/span><\/b><\/p>\n Gleichzeitig mit dem Aktivieren des Bedingungsfelds blendet FeldGewaehlt<\/b> alle Wertfelder der Zeile aus und setzt den Wert von cboBedingung<\/b> auf Null<\/b>. Ein Feldwechsel macht die bisherige Bedingung ungültig – ein Textoperator wie Enthält<\/b> ergibt für ein Zahlenfeld keinen Sinn. Außerdem setzt FeldGewaehlt<\/b> die Left<\/b>-Positionen aller Wertfelder auf ihre Ursprungswerte zurück.<\/p>\n Das ist notwendig weil bei Datumsfeldern mit der Bedingung Ist zwischen<\/b> die Positionen der Eingabefelder per Code verändert werden – dazu gleich mehr.<\/p>\n Schließlich blendet FeldGewaehlt<\/b> automatisch eine neue leere Zeile unterhalb ein, sofern die aktuelle Zeile die letzte aktive in der Gruppe ist und noch nicht fünf Zeilen belegt sind.<\/p>\n Sobald der Benutzer eine Bedingung auswählt, entscheidet BedingungGewaehlt<\/b> welche Eingabefelder eingeblendet werden. Bei Bedingungen wie Ist leer<\/b>, Ist nicht leer<\/b>, Wahr<\/b> oder Falsch<\/b> erscheint kein Eingabefeld – der Operator definiert bereits vollständig den Filterausdruck. Für Textfelder erscheint txtWert<\/b>.<\/p>\n Für Zahlenfelder erscheint ebenfalls txtWert<\/b>, bei Ist zwischen<\/b> zusätzlich txtWert2<\/b> für den Bis-Wert. Bei Datumsfeldern mit Ist zwischen<\/b> erscheinen txtDatum<\/b> (Von) und txtDatumA<\/b> (Bis) nebeneinander.<\/p>\n Bei allen anderen Datumsbedingungen erscheint das Kombinationsfeld cboDatumstyp<\/b> mit den vordefinierten Zeiträumen – und je nach gewähltem Datumstyp zusätzlich txtDatum<\/b> für ein konkretes Datum oder txtWert<\/b> für die Anzahl Tage bei Letzte X Tage<\/b>.<\/p>\n Da alle Steuerelemente einer Zeile an derselben X-Position liegen, werden beim Wechsel der Bedingung zuerst alle ausgeblendet und dann nur das jeweils benötigte eingeblendet. Bei Datumsfeldern mit Ist zwischen<\/b> müssen txtDatum<\/b> und txtDatumA<\/b> nebeneinander sichtbar sein.<\/p>\n Da beide im Formular übereinander bei derselben X-Position liegen, setzt das Formular beim Einblenden die Left<\/b>-Eigenschaft von txtDatum<\/b> auf die Position des Wertfelds und platziert txtDatumA<\/b> direkt dahinter.<\/p>\n Beim Wechsel zu einer anderen Bedingung oder beim Wechsel des Felds wird Left<\/b> auf den gespeicherten Ursprungswert zurückgesetzt. Dieser Ursprungswert ist als Konstante im Erstellungsmodul hinterlegt und gilt für alle 25 Zeilen gleichermaßen.<\/p>\n Das Filterformular validiert Tastatureingaben in den Wertfeldern in Echtzeit. Jedes der 25 txtWert<\/b>-Steuerelemente sowie die txtDatum<\/b>-Felder implementieren ein KeyPress<\/b>-Ereignis das an die zentrale Funktion ValidiereEingabe<\/b> in mdlFilter<\/b> delegiert. Diese erhält den KeyAscii<\/b>-Wert des gedrückten Zeichens sowie den Feldtyp der aktuellen Zeile und gibt den bereinigten KeyAscii<\/b>-Wert zurück (siehe Listing 3).<\/p>\n Listing 3: ValidiereEingabe filtert ungültige Zeichen je nach Feldtyp heraus<\/span><\/b><\/p>\n Bei Zahlenfeldern lässt die Funktion Ziffern, Komma (ASCII 44), Punkt (46), Minuszeichen (45) und Steuerzeichen (ASCII-Wert kleiner als 32, also Rück-, Tab-, Entf-Taste und so weiter) durch – alle anderen Zeichen werden durch Rückgabe von 0 stillschweigend abgewiesen.<\/p>\n Das Setzen von KeyAscii<\/b> auf 0 ist die VBA-Standardmethode um eine Tastatureingabe zu unterdrücken: Access ignoriert das Zeichen dann vollständig. Bei Datumsfeldern sind zusätzlich Punkt und Schrägstrich (47) erlaubt.<\/p>\n Für Textfelder und Ja\/Nein<\/b>-Felder ist keine Validierung nötig – Textfelder akzeptieren beliebige Zeichen, Ja\/Nein<\/b>-Felder haben gar kein Eingabefeld.<\/p>\n Darüber hinaus prüft cmdAnwenden_Click<\/b> vor dem Aufbau des WHERE<\/b>-Strings ob alle ausgefüllten Bedingungen auch einen Vergleichswert haben, sofern die gewählte Bedingung einen erfordert. Fehlt ein Wert, erscheint eine Hinweismeldung mit dem Namen des betroffenen Feldes und die Verarbeitung wird abgebrochen.<\/p>\n Nur Bedingungen wie Ist leer<\/b>, Ist nicht leer<\/b>, Wahr<\/b> und Falsch<\/b> sind von dieser Prüfung ausgenommen. Bei Datumsfeldern mit Ist zwischen<\/b> prüft die Funktion PruefeDatumVonBis<\/b> zusätzlich ob das Von-Datum kleiner oder gleich dem Bis-Datum ist.<\/p>\n Die dynamische Höhenanpassung ist eine der zentralen Anforderungen des Filterformulars – und technisch anspruchsvoller als es auf den ersten Blick scheint. Das Formular soll beim Öffnen kompakt sein und mit jeder neuen Filterzeile wachsen. Beim Löschen einer Zeile oder beim Zurücksetzen soll es entsprechend schrumpfen.<\/p>\n Umgesetzt wird das über zwei zusammenspielende Prozeduren: PositioniereZeilen<\/b> setzt die Top<\/b>-Eigenschaft jedes Steuerelements, AktualisiereFormularHoehe<\/b> (siehe Listing 4) berechnet die benötigte Gesamthöhe und setzt Section(acDetail).Height<\/b> sowie Me.InsideHeight<\/b>.<\/p>\n Listing 4: AktualisiereFormularHoehe berechnet die Höhe anhand tatsächlich sichtbarer Zeilen<\/span><\/b><\/p>\n AktualisiereFormularHoehe<\/b> ruft dabei PositioniereZeilen<\/b> intern auf bevor es die Höhe setzt – die Reihenfolge ist wichtig, denn die Positionen müssen stimmen bevor das Formular seine Größe anpasst.<\/p>\n Entscheidend ist, dass die Höhe nicht anhand von Zählvariablen wie m_intAktiveZeilen<\/b> berechnet wird, sondern anhand der tatsächlichen Sichtbarkeit der Steuerelemente.<\/p>\n Ein früherer Ansatz mit Zählvariablen führte zu Problemen: Nach dem Löschen einer mittleren Zeile oder nach dem Ausblenden einer ganzen ODER<\/b>-Gruppe war die Zählvariable nicht mehr synchron mit der tatsächlichen Anzahl sichtbarer Zeilen – das Formular zeigte dann eine falsche Höhe. Die Prüfung über Visible<\/b> ist dagegen immer korrekt, weil sie den tatsächlichen Zustand der Benutzeroberfläche widerspiegelt.<\/p>\n Die Konstantenwerte für Höhen und Abstände – cZeileHoehe<\/b>, cZeileAbstand<\/b>, cODERHoehe<\/b> und cGruppenAbstand<\/b> – sind als Public Const<\/b> in mdlFilter<\/b> definiert. Das stellt sicher dass das Formularmodul und das Erstellungsmodul stets dieselben Werte verwenden.<\/p>\n Würden die Werte an zwei Stellen gepflegt, könnten Inkonsistenzen entstehen – das Formular wäre dann zu hoch oder zu niedrig für die tatsächlich platzierten Steuerelemente.<\/p>\n PositioniereZeilen<\/b> läuft durch alle Gruppen und Zeilen und setzt die Top<\/b>-Position: Sichtbare Zeilen bekommen ihre berechnete Y-Position, unsichtbare Zeilen werden auf Y=0 gesetzt. Die Prozedur berücksichtigt dabei nur Gruppen die tatsächlich sichtbare Zeilen haben – leere Gruppen werden übersprungen ohne ODER<\/b>-Trenner oder Abstand einzufügen. Das ist wichtig wenn eine mittlere ODER<\/b>-Gruppe geleert wird: Die nachfolgenden Gruppen rücken lückenlos nach oben. cmdODERHinzufuegen<\/b> wird am Ende direkt unterhalb der letzten sichtbaren Zeile positioniert und wandert damit automatisch mit dem Formularinhalt (siehe Listing 5).<\/p>\n Listing 5: PositionereZeilen richtet die Höhe der verschiedenen Steuerelemente ein.<\/span><\/b><\/p>\n Das Formular verwaltet den Zustand der aktiven Gruppen in den Modulvariablen m_intAktiveGruppen<\/b> und m_intAktiveZeilen(1 To 5)<\/b>. Wenn der Benutzer auf ODER-Filtergruppe hinzufügen<\/b> klickt, wird m_intAktiveGruppen<\/b> erhöht, die erste Zeile der neuen Gruppe eingeblendet und AktualisiereFormularHoehe<\/b> aufgerufen. Die Schaltfläche ODER-Filtergruppe hinzufügen<\/b> erscheint und verschwindet dynamisch: Sie ist nur sichtbar wenn mindestens eine Bedingung in der aktuellen letzten Gruppe ausgefüllt ist, diese Gruppe noch nicht alle fünf Zeilen belegt hat und noch nicht alle fünf Gruppen aktiv sind. Diese Logik ist in AktualisiereSchaltflaechen<\/b> zentralisiert, die bei jeder relevanten Änderung aufgerufen wird.<\/p>\n Wird die letzte Bedingung einer ODER<\/b>-Gruppe gelöscht (ausgenommen Gruppe 1, die immer bestehen bleibt), verschwindet die gesamte Gruppe automatisch: ODER<\/b>-Trenner und Eingabezeile werden ausgeblendet.<\/p>\n m_intAktiveGruppen<\/b> wird anschließend neu berechnet – nicht einfach dekrementiert, denn es könnte eine mittlere Gruppe geleert worden sein, während eine spätere noch Einträge enthält. Das Formular iteriert daher nach dem Löschen durch alle Gruppen und setzt m_intAktiveGruppen<\/b> auf die letzte Gruppe, die noch sichtbare Zeilen hat.<\/p>\n Wenn der Benutzer auf Filter anwenden<\/b> klickt, sammelt cmdAnwenden_Click<\/b> alle ausgefüllten Filterbedingungen in einem zweidimensionalen Variant<\/b>-Array und übergibt es an zwei Hilfsfunktionen in mdlFilter<\/b>: GetFilterausdruck<\/b> baut den SQL-Ausdruck für eine einzelne Zeile, GetWhereString<\/b> kombiniert alle Gruppen zum vollständigen WHERE<\/b>-String.<\/p>\n GetFilterausdruck<\/b> erhält Feldname, Bedingung, Wert, zweiten Wert, Feldtyp und Datumstyp als Parameter. Die kritische Aufgabe ist das korrekte Quoten des Werts abhängig vom Feldtyp.<\/p>\n Textwerte werden in einfache Anführungszeichen gesetzt, wobei vorhandene Hochkommas im Wert selbst durch Verdopplung „escaped“ werden. Datumswerte werden im US-Format mit Rauten als Begrenzer formatiert. Zahlenwerte benötigen kein Trennzeichen:<\/p>\n Beim Quoten von Textwerten wird Chr(39)<\/b> statt eines direkt geschriebenen Hochkommas verwendet um Verwirrung im Quellcode zu vermeiden. Chr(39)<\/b> ist das einfache Anführungszeichen. Replace(strWert, Chr(39), Chr(39) & Chr(39))<\/b> verdoppelt alle Hochkommas im Wert – das ist die SQL-Standardmethode um Hochkommas in Zeichenketten zu escapen. Ein Name wie O’Brien<\/b> wird damit zu ‚O“Brien‘<\/b> – ein gültiger SQL-Ausdruck.<\/p>\n Bei LIKE<\/b>-Ausdrücken für Textoperatoren wird der Wert zusätzlich mit Platzhaltersternen umgeben: LIKE ‚*Suchbegriff*‘<\/b> für Enthält<\/b>, LIKE ‚Suchbegriff*‘<\/b> für Beginnt mit<\/b> und LIKE ‚*Suchbegriff‘<\/b> für Endet mit<\/b>.<\/p>\n GetWhereString<\/b> kombiniert die Ausdrücke: Innerhalb einer Gruppe werden alle Ausdrücke mit AND<\/b> verknüpft, zwischen Gruppen mit OR<\/b>.<\/p>\n Jeder Teilausdruck und jede Gruppe werden in Klammern gesetzt. Ein Filter mit zwei Gruppen – Gruppe 1 mit KundeID und Firma, Gruppe 2 mit Geburtsdatum – ergibt etwa:<\/p>\n Der Datumsbereich für vordefinierte Zeiträume wie Diesen Monat<\/b> oder Diese Woche<\/b> wird in GetFilterausdruck<\/b> zur Laufzeit berechnet. Für Diesen Monat<\/b> ermittelt die Funktion den ersten und letzten Tag des aktuellen Monats mit DateSerial<\/b> und baut daraus einen Zwischen-Ausdruck mit zwei Datumsliteralen auf.<\/p>\n Für Letzte X Tage<\/b> wird das Von-Datum als Date – CLng(strWert)<\/b> berechnet. Diese Berechnungen finden zum Zeitpunkt des Klicks auf Filter anwenden<\/b> statt – der Filter ist damit stets tagesaktuell.<\/p>\n Eine häufige Fehlerquelle bei der Verarbeitung von Datumseingaben in VBA ist die Funktion CDate<\/b>. Sie interpretiert eine Zeichenkette wie „23.1.1971“<\/b> nicht zuverlässig als deutsches Datum: VBA liest 23.1<\/b> manchmal als Dezimalzahl 23,1 und wandelt diesen Wert in ein Datum um, was einem Datum Ende Januar 1900 entspricht.<\/p>\n Das Verhalten ist systemabhängig und deshalb schwer zu reproduzieren und zu debuggen – genau die Art von Problem, die in der Entwicklung nicht auffällt und erst beim Kunden sichtbar wird.<\/p>\n Die Lösung ist die Funktion ParseDatum<\/b> in mdlFilter<\/b>, die das deutsche Format TT.MM.JJJJ über DateSerial<\/b> verarbeitet:<\/p>\n Split<\/b> zerlegt die Eingabezeichenkette am Punkt in ein Array: Index 0 enthält den Tag, Index 1 den Monat, Index 2 das Jahr. DateSerial<\/b> erwartet diese drei Werte als separate Ganzzahlen – damit ist das Ergebnis vollständig unabhängig von den regionalen Einstellungen des Systems. Im Fehlerfall gibt die Funktion das aktuelle Datum zurück. Der Else<\/b>-Zweig mit CDate<\/b> behandelt Eingaben ohne Punkte und überlässt deren Interpretation VBA. ParseDatum<\/b> wird in GetFilterausdruck<\/b> überall dort aufgerufen wo der Benutzer ein konkretes Datum eingegeben hat.<\/p>\n Eine technische Besonderheit von Access sorgt beim Ausblenden von Steuerelementen regelmäßig für den Laufzeitfehler 2165 mit der Meldung Sie können ein Steuerelement nicht ausblenden, solange es den Fokus hat<\/b>. Access erlaubt das Ausblenden eines Steuerelements schlicht nicht wenn dieses gerade den Eingabefokus hält.<\/p>\n Das ist eine harte Einschränkung ohne Workaround über die Eigenschaften des Steuerelements selbst – der Fokus muss zwingend vorher auf ein anderes Steuerelement umgesetzt werden.<\/p>\n Das Problem tritt an mehreren Stellen im Filterformular auf. Wenn der Benutzer auf die Löschen-Schaltfläche einer Filterzeile klickt, hat diese Schaltfläche durch den Klick den Fokus.<\/p>\n Im Zuge der anschließenden Neuberechnung soll sie aber ausgeblendet werden – was Access verweigert. Dasselbe gilt für die Schaltfläche ODER-Filtergruppe hinzufügen<\/b> wenn diese nach dem Klick aufgrund der geänderten Situation ausgeblendet werden soll.<\/p>\n Die Lösung ist die Hilfsprozedur SetFocusSicher<\/b>, die vor dem Ausblenden den Fokus auf ein anderes Steuerelement umsetzt:<\/p>\n Der Aufruf lautet etwa SetFocusSicher „cmdAnwenden“, „cmdZuruecksetzen“<\/b>. Die Schaltflächen im Formularfuß sind immer sichtbar und aktiviert und damit zuverlässige Kandidaten. ParamArray<\/b> erlaubt eine beliebige Anzahl von Kandidaten ohne explizite Array-Deklaration – der Aufrufer kann also je nach Situation unterschiedliche Kandidatenlisten angeben.<\/p>\n SetFocusSicher<\/b> wird immer ganz am Anfang von ZeileLeeren<\/b> aufgerufen – bevor irgendein Steuerelement geändert oder ausgeblendet wird.<\/p>\n Wenn der Benutzer eine Filterzeile löscht, muss das Formular nicht nur diese Zeile ausblenden, sondern auch die verbleibenden Zeilen der Gruppe korrekt neu aufbauen.<\/p>\n Das ist notwendig weil die Steuerelemente feste Indizes haben und beim Löschen einer mittleren Zeile keine Lücke in der Anzeige entstehen soll. ZeileLeeren<\/b> geht so vor: Fokus umsetzen, alle Werte der betroffenen Zeile leeren, alle Zeilen der Gruppe ausblenden, dann alle Zeilen mit ausgefülltem cboFeld<\/b> von oben nach unten über ZeileWiederherstellen<\/b> neu einblenden, schließlich eine leere Eingabezeile dahinter einblenden.<\/p>\n ZeileWiederherstellen<\/b> macht dabei mehr als nur Visible = True<\/b> zu setzen. Die Prozedur aktiviert cboBedingung<\/b> wieder und blendet das passende Wertfeld ein – basierend auf dem gespeicherten Feldtyp und dem aktuellen Wert von cboBedingung<\/b>.<\/p>\n Das ist notwendig weil ZeileSetzenSichtbar<\/b> beim Ausblenden cboBedingung.Enabled = False<\/b> setzt und alle Wertfelder ausblendet. Ohne ZeileWiederherstellen<\/b> wären nach dem Neuaufbau zwar Feld und Bedingung sichtbar, aber das Wertfeld wäre verschwunden und der eingegebene Filter für den Benutzer nicht mehr sichtbar und nicht mehr veränderbar.<\/p>\n Nach dem Neuaufbau prüft ZeileLeeren<\/b> ob die Gruppe noch Einträge enthält. Ist sie leer und ist es nicht Gruppe 1, wird auch der ODER<\/b>-Trenner ausgeblendet und m_intAktiveGruppen<\/b> neu berechnet. Zum Abschluss werden AktualisiereFormularHoehe<\/b> und AktualisiereSchaltflaechen<\/b> aufgerufen.<\/p>\n Das Filterformular löst eine Reihe von technischen Herausforderungen die beim Bau eines universell einsetzbaren dynamischen Filterformulars in Access auftreten.<\/p>\n Die wichtigsten Erkenntnisse im Überblick: Die DAO\/ADODB-Typkollision bei Wert 7 <\/b>erfordert ein explizites Flag das angibt welche Bibliothek verwendet wird – dieses Flag ist gleichzeitig die Vorbereitung für eine künftige ADODB-Erweiterung.<\/p>\n Deutsches Datum muss über DateSerial<\/b> statt über CDate<\/b> geparst werden, um systemunabhängig korrekte Ergebnisse zu liefern.<\/p>\n Steuerelemente können nicht ausgeblendet werden, wenn sie den Fokus haben – eine Hilfsprozedur, die den Fokus vorab sicher umsetzt, löst dieses Problem zuverlässig.<\/p>\n Die dynamische Höhenanpassung funktioniert nur, wenn sie auf der tatsächlichen Sichtbarkeit der Steuerelemente basiert, nicht auf Zählvariablen. Das Stapeln aller Steuerelemente bei Y=0 ermöglicht die dynamische Höhensteuerung.<\/p>\n Und beim Neuaufbau von Zeilen nach einem Löschvorgang genügt einfaches Einblenden nicht – der vollständige Zustand einer Zeile inklusive aktiviertem Bedingungsfeld und sichtbarem Wertfeld muss über eine dedizierte Wiederherstellungsprozedur rekonstruiert werden.<\/p>\n Enthaltene Beispieldateien:<\/p>\n FilterformularFuerAlleFaelleDieProgrammierung.accdb<\/p>\nPublic Property Set<\/span> <\/span>CallingForm(frm As <\/span>Form)\r\n Set<\/span> m_frmAufrufend = frm\r\nEnd Property<\/span>\r\nPublic Property Set<\/span> <\/span>RecordsetForm(rst As Object<\/span>)\r\n Set<\/span> m_rst = rst\r\n m_bolDAO = (TypeName(rst) = \"Recordset\") _\r\n Or (TypeName(rst) = \"Recordset2\")\r\n LadeFelder\r\nEnd Property<\/span><\/pre>\nDas Steuerelemente-Raster: 175 Elemente auf einem Haufen<\/h2>\n
Feldtypen erkennen: Die DAO\/ADODB-Kollision<\/h2>\n
Public Function <\/span>GetFeldtyp(lngTyp As Long<\/span>, bolDAO As Boolean<\/span>) As Long<\/span>\r\n If <\/span>bolDAO Then<\/span>\r\n Select Case lngTyp\r\n Case <\/span>2, 3, 4, 5, 6, 7, 15, 16, 17, 18, 19, 20\r\n GetFeldtyp = cFeldtypZahl\r\n Case <\/span>8\r\n GetFeldtyp = cFeldtypDatum 'dbDate = 8\r\n Case <\/span>1\r\n GetFeldtyp = cFeldtypJaNein 'dbBoolean = 1\r\n Case Else<\/span>\r\n GetFeldtyp = cFeldtypText\r\n End Select<\/span>\r\n Else<\/span>\r\n Select Case lngTyp\r\n Case <\/span>2, 3, 4, 5, 6, 14, 15, 16, 17, 18, 19, 20, 21, 131\r\n GetFeldtyp = cFeldtypZahl\r\n Case <\/span>7, 133, 134, 135\r\n GetFeldtyp = cFeldtypDatum 'adDate = 7\r\n Case <\/span>11\r\n GetFeldtyp = cFeldtypJaNein 'adBoolean = 11\r\n Case Else<\/span>\r\n GetFeldtyp = cFeldtypText\r\n End Select<\/span>\r\n End If<\/span>\r\nEnd Function<\/span><\/pre>\nFor i = 0 To m_rst.Fields.Count - 1\r\n m_strFeldnamen(i) = m_rst.Fields(i).Name\r\n m_lngFeldtypen(i) = GetFeldtyp( _\r\n m_rst.Fields(i).Type, m_bolDAO)\r\nNext<\/span> i<\/pre>\nBedingungen und Wertfelder dynamisch einblenden<\/h2>\n
Public Function <\/span>GetBedingungRowsource(lngFeldtyp As Long<\/span>) As String<\/span>\r\n Select Case lngFeldtyp\r\n Case <\/span>cFeldtypText\r\n GetBedingungRowsource = _\r\n \"Gleich;Nicht gleich;Enthaelt;Enthaelt nicht;Beginnt mit;Endet mit;Ist leer;Ist nicht leer\"\r\n Case <\/span>cFeldtypZahl\r\n GetBedingungRowsource = _\r\n \"Gleich;Nicht gleich;Groesser als;Kleiner als;Ist zwischen;Ist leer;Ist nicht leer\"\r\n Case <\/span>cFeldtypDatum\r\n GetBedingungRowsource = _\r\n \"Gleich;Ist vor;Ist nach;Ist zwischen;Ist leer;Ist nicht leer\"\r\n Case <\/span>cFeldtypJaNein\r\n GetBedingungRowsource = \"Wahr;Falsch\"\r\n End Select<\/span>\r\nEnd Function<\/span><\/pre>\nEingaben validieren<\/h2>\n
Public Function <\/span>ValidiereEingabe(KeyAscii As Integer<\/span>, lngFeldtyp As Long<\/span>) As Integer<\/span>\r\n Select Case lngFeldtyp\r\n Case <\/span>cFeldtypZahl\r\n If Not<\/span> (Chr(KeyAscii) Like \"[0-9]\" _\r\n Or KeyAscii = 44 _\r\n Or KeyAscii = 46 _\r\n Or KeyAscii = 45 _\r\n Or KeyAscii < 32) Then\r\n KeyAscii = 0\r\n End If<\/span>\r\n Case <\/span>cFeldtypDatum\r\n If Not<\/span> (Chr(KeyAscii) Like \"[0-9]\" _\r\n Or KeyAscii = 46 _\r\n Or KeyAscii = 45 _\r\n Or KeyAscii = 47 _\r\n Or KeyAscii < 32) Then\r\n KeyAscii = 0\r\n End If<\/span>\r\n End Select<\/span>\r\n ValidiereEingabe = KeyAscii\r\nEnd Function<\/span><\/pre>\nDynamische Höhenanpassung<\/h2>\n
Private Sub <\/span>AktualisiereFormularHoehe()\r\n Dim <\/span>lngHoehe As Long<\/span>\r\n Dim <\/span>g As Integer<\/span>, z As Integer<\/span>\r\n Dim <\/span>intSichtbar As Integer<\/span>\r\n Dim <\/span>bolErsteGruppe As Boolean<\/span>\r\n lngHoehe = 400 'Spaltenueberschriften\r\n bolErsteGruppe = True<\/span>\r\n For g = 1 To cMaxGruppen\r\n intSichtbar = 0\r\n For z = 1 To cMaxZeilen\r\n If <\/span>Me(\"cboFeld_\" & g & \"_\" & z).Visible Or Me(\"cboBedingung_\" & g & \"_\" & z).Visible Then<\/span>\r\n intSichtbar = intSichtbar + 1\r\n End If<\/span>\r\n Next<\/span> z\r\n If <\/span>intSichtbar > 0 Then<\/span>\r\n If <\/span>Not<\/span> bolErsteGruppe Then<\/span>\r\n lngHoehe = lngHoehe + cODERHoehe + cZeileAbstand\r\n End If<\/span>\r\n lngHoehe = lngHoehe + _\r\n intSichtbar * (cZeileHoehe + cZeileAbstand)\r\n bolErsteGruppe = False<\/span>\r\n End If<\/span>\r\n Next<\/span> g\r\n PositioniereZeilen\r\n Me.Section(acDetail).Height = lngHoehe\r\n Me.InsideHeight = lngHoehe + Me.Section(acHeader).Height + Me.Section(acFooter).Height\r\nEnd Sub<\/span><\/pre>\nPrivate Sub <\/span>PositioniereZeilen()\r\n Dim <\/span>lngY As Long<\/span>, g As Integer<\/span>, z As Integer<\/span>\r\n Dim <\/span>bolErsteGruppe As Boolean<\/span>\r\n lngY = 400\r\n bolErsteGruppe = True<\/span>\r\n For g = 1 To cMaxGruppen\r\n 'Pruefen ob diese Gruppe sichtbare Zeilen hat\r\n Dim <\/span>bolHatZeilen As Boolean<\/span>\r\n bolHatZeilen = False<\/span>\r\n For z = 1 To cMaxZeilen\r\n If Me(\"cboFeld_\" & g & \"_\" & z).Visible Or _\r\n Me(\"cboBedingung_\" & g & \"_\" & z).Visible Then\r\n bolHatZeilen = True<\/span>\r\n Exit For<\/span>\r\n End If<\/span>\r\n Next<\/span> z\r\n If <\/span>bolHatZeilen Then<\/span>\r\n 'ODER-Trenner positionieren (ausser bei erster sichtbarer Gruppe)\r\n If <\/span>Not<\/span> bolErsteGruppe Then<\/span>\r\n Me(\"lblODER_\" & g).Top = lngY\r\n lngY = lngY + cODERHoehe + cZeileAbstand\r\n End If<\/span>\r\n bolErsteGruppe = False<\/span>\r\n 'Zeilen positionieren\r\n For z = 1 To cMaxZeilen\r\n If Me(\"cboFeld_\" & g & \"_\" & z).Visible Or _\r\n Me(\"cboBedingung_\" & g & \"_\" & z).Visible Then\r\n Me(\"cboFeld_\" & g & \"_\" & z).Top = lngY\r\n '... weitere Steuerelemente\r\n lngY = lngY + cZeileHoehe + cZeileAbstand\r\n Else<\/span>\r\n Me(\"cboFeld_\" & g & \"_\" & z).Top = 0\r\n Me(\"cboBedingung_\" & g & \"_\" & z).Top = 0\r\n '... weitere Steuerelemente\r\n End If<\/span>\r\n Next<\/span> z\r\n Else<\/span>\r\n 'Gruppe leer - alle auf Y=0\r\n For z = 1 To cMaxZeilen\r\n Me(\"cboFeld_\" & g & \"_\" & z).Top = 0\r\n Me(\"cboBedingung_\" & g & \"_\" & z).Top = 0\r\n '... weitere Steuerelemente\r\n Next<\/span> z\r\n End If<\/span>\r\n Next<\/span> g\r\n 'ODER-Schaltflaeche positionieren\r\n cmdODERHinzufuegen.Top = lngY\r\nEnd Sub<\/span><\/pre>\nODER-Gruppen verwalten<\/h2>\n
Den WHERE-String aufbauen<\/h2>\n
Select Case lngFeldtyp\r\n Case <\/span>cFeldtypZahl\r\n strWertSQL = strWert\r\n Case <\/span>cFeldtypDatum\r\n strWertSQL = \"#\" & _\r\n Format(datVon, \"mm\/dd\/yyyy\") & \"#\"\r\n Case Else<\/span> 'Text\r\n strWertSQL = Chr(39) & _\r\n Replace<\/span>(strWert, Chr(39), Chr(39) _\r\n & Chr(39)) & Chr(39)\r\nEnd Select<\/span><\/pre>\nWHERE ((KundeID > 95) AND (Firma LIKE 'M*'))\r\n OR ((Geburtsdatum = #01\/23\/1971#))<\/pre>\n
Datumsangaben korrekt parsen<\/h2>\n
Public Function <\/span>ParseDatum(strDatum As String<\/span>) As Date<\/span>\r\n Dim <\/span>arrTeile() As String<\/span>\r\n On Error GoTo<\/span> Fehler\r\n arrTeile = Split<\/span>(strDatum, \".\")\r\n If <\/span>UBound<\/span>(arrTeile) >= 2 Then<\/span>\r\n ParseDatum = DateSerial( _\r\n CInt(arrTeile(2)), _\r\n CInt(arrTeile(1)), _\r\n CInt(arrTeile(0)))\r\n Else<\/span>\r\n ParseDatum = CDate(strDatum)\r\n End If<\/span>\r\n Exit Function<\/span>\r\nFehler:\r\n ParseDatum = Date\r\nEnd Function<\/span><\/pre>\nDas Fokus-Problem beim Ausblenden von Steuerelementen<\/h2>\n
Private Sub <\/span>SetFocusSicher( _\r\n ParamArray arrNamen() As Variant<\/span>)\r\n Dim <\/span>i As Integer<\/span>\r\n Dim <\/span>ctl As <\/span>Control\r\n For i = 0 To UBound<\/span>(arrNamen)\r\n On Error Resume Next<\/span>\r\n Set<\/span> ctl = Me(arrNamen(i))\r\n On Error GoTo<\/span> 0\r\n If <\/span>Not<\/span> ctl Is Nothing Then<\/span>\r\n If <\/span>ctl.Visible And ctl.Enabled Then<\/span>\r\n ctl.SetFocus\r\n Exit Sub<\/span>\r\n End If<\/span>\r\n End If<\/span>\r\n Next<\/span> i\r\nEnd Sub<\/span><\/pre>\nZeilen löschen und Zustand wiederherstellen<\/h2>\n
Zusammenfassung<\/h2>\n
Downloads zu diesem Beitrag<\/h2>\n