Access-Formular mit WklValidator prüfen

Prüfen Sie die Textfelder eines Access-Formulars – ein Bearbeitungsformular zu einer Liste, ein Dialogfeld, ein beliebiges gebundenes Formular – mit Regeln je Feld und je Datensatz. Zeigen Sie die Fehler an den Feldern und in einer Zusammenfassung an, und verhindern Sie, dass ein Datensatz gespeichert wird, der gegen eine Regel verstößt.

Voraussetzungen: WKL Forms Object Library 1.31 oder höher.

• Ein Steuerelement im Formular. Fügen Sie WKL Validator (ein ActiveX-Steuerelement) dort ein, wo die Zusammenfassung erscheinen soll, zum Beispiel unter den Feldern. Solange es keine Fehler gibt, zeichnet es nichts.
• Ein leeres Modul. Setzen Sie die Formulareigenschaft Enthält Modul auf Ja. Access leitet die Ereignisse eines Formulars nur dann an ein Steuerelement weiter, wenn das Formular ein Modul hat; ein leeres genügt. Die Ereigniseigenschaften, die er braucht, setzt der Validator selbst auf [Ereignisprozedur].
• Regeln legen Sie auf den Designerseiten Feldregeln und Satzregeln fest (Eigenschaften des Steuerelements) oder als JSON in Rules: je Feld required, maxLength, pattern, min, max, valueList, text, optional when (die Regel gilt nur, solange ein anderes Feld einen von bestimmten Werten hat); je Datensatz exactlyOne, atLeastOne, atMostOne über mehrere Felder.
• Was der Benutzer sieht: Verlässt er ein Feld, das gegen eine Regel verstößt, bleibt der Fokus darin; das Feld erhält einen roten Rahmen und die Meldung als QuickInfo. Der Validator zeigt „2 Fehler – …“, und ein Klick darauf führt zum ersten Fehler. Das Speichern eines Datensatzes, der gegen eine Regel verstößt, wird abgelehnt – auch das Speichern, das Access vornimmt, wenn der Fokus aus einem angedockten Bearbeitungsformular zurück in seine Liste wechselt. Meldungsfenster erscheinen nicht.

Ein Bearbeitungsformular frmIdentity (gebunden an tblIdentity, mit leerem Modul) ist neben einer Liste angedockt. Login besteht aus Kleinbuchstaben und ist für die Art „Login“ erforderlich; eine Identität nennt genau eines von Person, Windows-Konto und Schlüssel:

' Once, in design view (or on the designer's pages); the rules are saved with the form.
Forms!frmIdentity!Validator1.Object.Rules = _
    "{""fields"":[" & _
    "{""field"":""Login"",""pattern"":""[a-z]+"",""text"":""Login nur aus Kleinbuchstaben""}," & _
    "{""field"":""Login"",""required"":true,""when"":{""field"":""Kind"",""equals"":""Login""}}]," & _
    """records"":[{""exactlyOne"":[""PersonId"",""Account"",""KeyId""],""text"":""Genau eine Quelle angeben""}]}"

Eine eigene Speichern-Schaltfläche meldet eine Ablehnung durch den Datendienst ebenfalls in der Zusammenfassung:

Private Sub cmdSpeichern_Click()
    On Error GoTo Abgelehnt
    If Not Me!Validator1.Object.Validate Then Exit Sub   ' shows what is missing
    Me.Dirty = False
    Exit Sub
Abgelehnt:
    Me!Validator1.Object.SetError "", Err.Description
End Sub

Häufig benötigte Muster:

In JSON wird jeder Backslash doppelt geschrieben (\\d).

• Ohne Modul prüft der Validator von sich aus nichts. Er meldet das in seinem Rechteck („Prüfung inaktiv …“), und IsConnected ist False; ein Aufruf von Validate per Code funktioniert weiterhin. Siehe Der Validator prüft nichts.
• Wie Felder benannt werden. field ist der Name eines Steuerelements oder das Feld, das ein Steuerelement anzeigt (sein Steuerelementinhalt; berechnete Steuerelemente zählen nie); für when.field und die Felder von Satzregeln gilt dasselbe. Ein Feld ohne Steuerelement wird aus dem Datensatz gelesen und geprüft, aber nicht markiert. Meldungen nennen ein Feld mit der Beschriftung des zugeordneten Bezeichnungsfelds des Steuerelements; ein frei daneben platziertes Bezeichnungsfeld zählt nicht.
• Muster gelten immer für den gesamten Text (^/$ sind nicht nötig), sind reguläre Ausdrücke von .NET (\\p{L} für einen beliebigen Buchstaben in JSON), prüfen nur eingegebene Werte und gelten nach einer Viertelsekunde als nicht erfüllt.
• Ereigniseigenschaften, die ein Makro oder einen Ausdruck enthalten, bleiben unverändert; das Ereignis geht dann an das Makro, nicht an den Validator. Verwenden Sie [Ereignisprozedur], und rufen Sie das Makro aus der Prozedur auf.
• Fehler der Datenquelle beim Speichern – eine Gültigkeitsregel der Tabelle, ein Datendienst, der den Datensatz über seinen ODBC-Treiber ablehnt – erscheinen mit der Begründung des Treibers in der Zusammenfassung statt im Meldungsfenster von Access (HandleDataErrors, standardmäßig eingeschaltet), und zwar beim Speichern, das Access während einer Benutzeraktion vornimmt. Ein Speichern, das Ihr eigener Code auslöst (Me.Dirty = False, aber auch ein Fokuswechsel per Code wie area!grdMain.SetFocus), meldet seinen Fehler stattdessen diesem Code, wie in jedem Access-Formular (zum Beispiel Fehler 3316 einer Gültigkeitsregel der Tabelle oder 3155 eines ablehnenden ODBC-Treibers); übergeben Sie den Text wie oben an SetError. Siehe Ein abgelehntes Speichern erscheint nicht in der Zusammenfassung des Validators.
• Ein neuer Datensatz, ein gespeicherter Datensatz und Rückgängig löschen die Fehler; ClearErrors stellt Rahmen und QuickInfos jederzeit wieder her.
• Prüfungen, die sich nicht als Regel formulieren lassen, gehören in das Ereignis ValidateRecord (Message, Cancel). Anders als die Regeln braucht es Code im Modul.
• Per Code aufgebaut: Fügen Sie den Validator als Steuerelementbaustein ein, nicht mit CreateControl – siehe WKL-Steuerelemente per Code in Formulare einfügen.
• Der Validator arbeitet in Access-Formularen; in UserForms von Excel und Word hat er kein Formular, das er prüfen könnte.

• API-Referenz (Englisch): WklValidator, Enumerationen (WklValidateMode)
• Zelleingaben prüfen – dieselben Regeln für die Zellen einer Liste
• Datensätze in einem Access-Formular bearbeiten
• WKL-Steuerelemente per Code in Formulare einfügen
• Der Validator prüft nichts
• Ein abgelehntes Speichern erscheint nicht in der Zusammenfassung des Validators