Datensätze in einem Access-Formular bearbeiten

Lassen Sie Benutzer die Datensätze eines WklGrid, einer WklTreeList oder eines WklGantt in einem gewöhnlichen Access-Formular bearbeiten – als Dialogfeld, als Fenster oder angedockt neben der Liste – statt in den Zellen der Liste.

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

• Das Formular gehört Ihnen. Entwerfen Sie ein gebundenes Access-Formular für die Tabelle oder Abfrage der Datensätze, mit den Feldern, Gültigkeitsregeln und dem Layout, die Sie möchten. Es braucht weder Code noch Modul. Ein ungebundenes Formular, das seine Werte selbst liest und schreibt (zum Beispiel über gespeicherte Prozeduren), funktioniert ebenfalls; siehe Ein ungebundenes Formular unter „Hinweise“.
• Die Liste öffnet es. EditForm nennt das Formular, EditFormMode legt fest, wo es erscheint. Doppelklick, Eingabetaste, F2 und EditSelected öffnen es gefiltert auf den ausgewählten Datensatz; Strg++ und NewRecord öffnen es für einen neuen Datensatz. Ist das Formular fertig, liest die Liste ihre Datensätze neu.
• Schlüssel und Arten. EditKeyFields nennt die Schlüsselfelder des Formulars, wenn sie vom KeyField der Liste abweichen; EditKindField und EditForms wählen ein Formular je Art von Datensatz, für eine Struktur über mehrere Tabellen. Eine Detailansicht eines WklGrid kann ein eigenes Formular haben (editForm in DetailViews).
• Was das Formular getan hat. Nach dem Formular gibt EditFormResult an, ob der Datensatz unverändert, geändert, hinzugefügt oder gelöscht ist; ein vom Formular hinzugefügter Datensatz wird ausgewählt (EditFormNewKey).

Ein Formular frmKunden mit dem Raster Grid1 auf tblKunde (Schlüssel ID) und ein Bearbeitungsformular frmKunde, gebunden an tblKunde, mit einem Textfeld je Feld.

1. Öffnen Sie in der Entwurfsansicht von frmKunden den Designer des Rasters (Eigenschaften des Steuerelements oder die Schaltfläche […] einer Eigenschaft im Eigenschaftenblatt), Seite Verhalten (in einer WklTreeList: Gitter, Gruppierung und Export), Abschnitt Bearbeitungsmaske:
   • Formular (EditForm): frmKunde
   • Anzeige (EditFormMode): Dialog
2. Speichern Sie das Formular, und öffnen Sie es in der Formularansicht. Doppelklicken Sie auf einen Kunden: frmKunde öffnet sich als Dialogfeld mit diesem Kunden. Ändern Sie einen Wert, und schließen Sie das Dialogfeld; das Raster zeigt den neuen Wert.

Dieselben Einstellungen per Code:

Private Sub Form_Load()
    With Me!Grid1.Object
        .EditForm = "frmKunde"
        .EditFormMode = wfmDialog
    End With
End Sub

Angedockt neben dem Raster: Fügen Sie frmKunden ein Unterformular-Steuerelement sfEdit hinzu (zum Beispiel in einem Bereich eines WklDockLayout), und lassen Sie sein Herkunftsobjekt leer; das Raster füllt es.

With Me!Grid1.Object
    .EditForm = "frmKunde"
    .EditFormControl = "sfEdit"
    .EditFormMode = wfmDocked
End With

Eine Struktur über einer UNION-Abfrage von Kunden und Bestellungen, mit einer Spalte Art und einer gemeinsamen Schlüsselspalte ID:

With Me!Tree1.Object
    .EditKindField = "Art"
    .EditForms = "{""forms"":[{""kind"":""Kunde"",""form"":""frmKunde"",""keys"":""KundeID""}," & _
                 "{""kind"":""Bestellung"",""form"":""frmBestellung"",""keys"":""BestellNr""}]}"
    .EditFormMode = wfmDialog
End With

Eine Struktur, deren Schlüssel über mehrere Tabellen hinweg nur durch einen Text wie 'r5' (Regel 5) oder 'i5:resource' (Element resource der Regel 5) eindeutig ist: Die Union führt die Tabellenschlüssel in eigenen Spalten (Nr, Item), und sourceKeys entnimmt ihnen den Schlüssel des Formulars. Mit children fügt Strg++ auf einer Regel ihr ein Element hinzu; deleteFrom nennt die Tabelle, aus der ihre Elemente gelöscht werden:

With Me!Tree1.Object
    .KeyField = "Key"
    .EditKindField = "Kind"
    .EditForms = "{""forms"":[" & _
        "{""kind"":""Rule"",""form"":""frmRule"",""sourceKeys"":""Nr"",""keys"":""Id""," & _
        """children"":[{""kind"":""Item"",""link"":""RuleId=Nr""}]}," & _
        "{""kind"":""Item"",""form"":""frmRuleItem"",""sourceKeys"":""Nr;Item"",""keys"":""RuleId;Item""," & _
        """deleteFrom"":""tblRuleItem""}]}"
    .EditFormControl = "sfEdit"
    .EditFormMode = wfmDocked
End With

Eigene Schaltflächen je Art verwenden NewRecordOfKind und CanAddKind:

Private Sub Tree1_CommandStateChange()
    Me!cmdNewRule.Enabled = Me!Tree1.Object.CanAddKind("Rule")
    Me!cmdNewItem.Enabled = Me!Tree1.Object.CanAddKind("Item")
End Sub
 
Private Sub cmdNewItem_Click()
    Me!Tree1.Object.NewRecordOfKind "Item"
End Sub

• Die Prüfung bleibt im Formular. Pflichtfelder, Gültigkeitsregeln und Fehler der Datenquelle erscheinen im Bearbeitungsformular, wie in jedem Access-Formular; die Liste zeigt dafür keine eigenen Meldungen. Ein Bearbeitungsformular, das nicht existiert, oder ein Schlüssel, der nicht zu den Schlüsselfeldern des Formulars passt, wird über DataError gemeldet (oder ohne DataError-Prozedur in einem Meldungsfenster).
• Neue Datensätze einer verknüpften Liste. Ist die Liste mit einem Masterdatensatz verknüpft (LinkChildFields), erhalten die Steuerelemente des Bearbeitungsformulars, die an die Verknüpfungsfelder gebunden sind, die Werte des Masters als Standardwert. Das Formular braucht für jedes Verknüpfungsfeld ein Steuerelement; es darf unsichtbar sein. Im Dialogmodus wird ein solches Formular verborgen geöffnet, vorbereitet und dann mit Modal = True angezeigt statt als acDialog, weil sich ein Dialogfeld nach dem Öffnen nicht mehr ändern lässt: Die Liste wartet weiterhin, bis es geschlossen wird, aber das Hauptfenster von Access bleibt aktiviert.
• Was das Formular getan hat. Die Liste liest den Datensatz vor dem Öffnen des Formulars und danach aus ihrer Datenherkunft und vergleicht alle Felder: EditFormResult ist wfrUnchanged auch dann, wenn das Formular ohne Änderung gespeichert hat. Bei einem neuen Datensatz vergleicht sie die Schlüssel, die die Liste vorher und nachher enthält (im Servermodus den größten Schlüssel eines einzelnen numerischen Schlüsselfelds); anschließend wählt sie den neuen Datensatz aus, klappt seinen übergeordneten Knoten auf und führt einen Bildlauf zu ihm aus. Eine Liste über einem Recordset meldet wfrUnknown. AfterEditForm meldet für ein Formular, das für einen neuen Datensatz geöffnet wurde, weiterhin NewRecord = True. Weil die Liste ihre Datenherkunft selbst liest, wird wfrChanged für jede Änderung gemeldet, die die Datenherkunft danach zeigt – auch für eine, die das Formular über eine gespeicherte Prozedur geschrieben hat, statt seinen eigenen Datensatz zu speichern.
• Einen auf anderem Weg hinzugefügten Datensatz auswählen. Lässt sich der neue Schlüssel durch Vergleichen der Schlüssel nicht finden (mehrere Benutzer fügen gleichzeitig hinzu, ein Schlüssel ist keine aufsteigende Zahl), setzen Sie SelectedKey in AfterEditForm: Die Liste hat ihre Datensätze vor dem Ereignis neu gelesen.
• Ein ungebundenes Formular. Das Formular wird mit einer WhereCondition auf den Schlüssel geöffnet (angedockt: Filter und FilterOn); ein ungebundenes Formular erhält dadurch weder einen Datensatz noch OpenArgs. Es liest den Schlüssel aus der Liste (Forms!frmList!Grid1.Object.SelectedKey oder Key von BeforeEditForm) und lädt und schreibt seine Werte selbst, zum Beispiel über eine Pass-Through-Abfrage. EditFormResult meldet weiterhin wfrChanged, wenn die Datenherkunft danach eine Änderung zeigt, auch wenn das Formular selbst nichts gespeichert hat (wfrUnknown bei einer Liste über einem Recordset). Verwenden Sie dafür den Dialogmodus: Im angedockten und im automatischen Modus ändert die Liste bei jeder Auswahl nur den Filter des Formulars, und das bemerkt ein ungebundenes Formular nicht.
• Datensätze einer UNION-Abfrage. Access kann eine Union nicht ändern. Ein Datensatz einer Art mit sourceKeys oder deleteFrom wird deshalb in dieser Tabelle (oder in der RecordSource des Formulars) über die Schlüsselfelder des Formulars gelöscht, wie gewohnt mit BeforeDelete und der Rückfrage. Mit Bearbeitungsformularen lassen sich nur Datensätze bearbeiten und löschen, deren Art ein Formular hat. Eine Art, die hinzugefügt und gelöscht, aber nicht geändert werden darf, braucht keine Einstellung der Liste: Setzen Sie Bearbeitungen zulassen (AllowEdits) ihres Formulars auf Nein, dann öffnet sich das Formular schreibgeschützt.
• Fenstermodus. Wird das Formular für einen anderen Datensatz erneut geöffnet, während sein Fenster offen ist, zeigt dasselbe Fenster den anderen Datensatz: Access öffnet ein Formular ohne Modul nur einmal. Wird das Formular der Liste geschlossen, bleibt ein solches Fenster mit seinen Änderungen geöffnet, so wie Access jedes andere Formular geöffnet lässt; die Liste fragt nichts.
• Angedockter Modus. Access speichert den Datensatz des angedockten Formulars, wenn der Fokus zur Liste zurückkehrt, wie bei jedem Unterformular; ein Datensatz, der sich nicht speichern lässt, hält den Fokus mit der Meldung von Access im Formular. Ein Klick auf einen anderen Datensatz der Liste setzt den Fokus zurück in die Liste; der angezeigte Datensatz wird also wie beschrieben gespeichert, und danach zeigt das angedockte Formular den ausgewählten. Wird das Formular der Liste geschlossen, wird der angedockte Datensatz wie bei jedem Unterformular gespeichert.
• Überlagerungsmodus. Das Unterformular-Steuerelement muss in der Reihenfolge des Formulars nach der Liste kommen (Anordnen › In den Vordergrund), damit es über ihr liegt. Die Liste legt es über ihren rechten Teil (EditFormWidth, sonst die eigene Breite des Steuerelements), wenn ein Datensatz bearbeitet wird, und blendet es aus, wenn der Fokus zur Liste zurückkehrt; die Überlagerung folgt der Auswahl nicht.
• Detailansichten. Eine Detailansicht hat kein eigenes Unterformular-Steuerelement; der angedockte und der automatische Modus öffnen ihr Formular deshalb als Dialogfeld. Ihre Ereignisse BeforeEditForm und AfterEditForm löst das Masterraster aus.
• Ereignisse brauchen ein Modul, das Formular nicht. BeforeEditForm (anderes Formular wählen, abbrechen) und AfterEditForm sind Ereignisse des Steuerelements und brauchen das Modul des Formulars; Öffnen, Filtern und erneutes Lesen funktionieren ohne sie.
• Nicht in UserForms. In Excel und Word gibt es kein Access-Formular, das sich öffnen ließe; die Eigenschaften bleiben erhalten, haben aber keine Wirkung.

• API-Referenz (Englisch): WklTreeList (EditForm, EditKeyFields, EditFormMode, EditKindField, EditForms, EditFormControl, EditFormWidth, EditFormResult, EditFormNewKey, NewRecordOfKind, CanAddKind, BeforeEditForm, AfterEditForm), WklGrid (DetailViews), Enumerationen (WklEditFormMode, WklEditFormResult)
• Befehle des Rasters über eigene Schaltflächen ausführen
• Zusammengesetzten Schlüssel verwenden
• Detailansichten unter einem Datensatz anzeigen
• WklGrid