<\/p>\n
Viele Anwendungen zeigen Daten in Haupt- und Unterformularen an, wobei das Unterformular Daten einfacher Tabellen enthält (etwa Adressen) oder Haupt- und Unterformular verknüpfte Daten darstellen (zum Beispiel Kunden und Projekte). Die Daten im Unterformular können dann zwar möglicherweise direkt an Ort und Stelle bearbeitet werden, aber wenn das im Unterformular dargestellte Objekt viele Felder enthält, sollten Sie dafür ein spezielles Detailformular bereitstellen. Mit diesem kann der Benutzer dann neue Datensätze anlegen und bestehende bearbeiten. In diesem Beitrag erfahren Sie, wie Sie ein solches Detailformular aufbauen und es für die verschiedenen Bearbeitungsarten einsetzen.<\/b><\/p>\n
Das Zusammenspiel eines Formulars zur Anzeige der Übersicht der Datensätze einer Tabelle und eines weiteren Formulars zum Anlegen eines neuen Datensatzes oder zum Bearbeiten des jeweils in der Liste ausgewählten Datensatzes liefert eine Menge Herausforderungen:<\/p>\n
Diese und weitere Fragen beantwortet der vorliegende Beitrag.<\/p>\n
Beispiele dieses Beitrags<\/b><\/p>\n
In diesem Beitrag werden wir zwei verschiedene Beispiele betrachten: Im ersten zeigen Haupt- und Unterformular lediglich Adressdaten im Unterformular an, aber keine Daten im Hauptformular. Im zweiten Beispiel enthält das Hauptformular ebenfalls Daten, die per 1:n-Beziehung mit denen im Unterformular verknüpft sind. In diesem Fall kommt das gute, alte Beispiel der Projekte eines Kunden zum Einsatz: Das Hauptformular zeigt die Daten eines Kunden an, das Unterformular die der zu diesem Kunden gehörenden Projekte.<\/p>\n
Die grundsätzliche Technik ist bei beiden Varianten gleich, bei der Version mit 1:n-Beziehung und Daten im Hauptformular kommt noch eine Feinheit hinzu.<\/p>\n
Haupt- und Unterformular des ersten Beispiels heißen frmAdressenMitDetailformular <\/b>und sfmAdressenMitDetailformular <\/b>und sehen wie in Bild 2 aus und bringt eine Kopfzeile im Kopfbereich sowie die Schaltflächen cmdOK <\/b>und cmdAbbrechen <\/b>im Fußbereich des Formulars unter.<\/p>\n
![\"pic001.png\"](\"..\/fileadmin\/_temp_\/2010_05\/UnterformularDetailansicht-web-images\/pic001.png\")
<\/p>\n
Bild 1: Übersicht der Adressen, die per Detailformular neu angelegt und bearbeitet werden sollen<\/span><\/b><\/p>\n Bild 2: Formular zum Anlegen oder Bearbeiten einer Adresse<\/span><\/b><\/p>\n Später werden die Eigenschaften Trennlinien<\/b>, Datensatzmarkierer<\/b>, Navigationsschaltflächen <\/b>und Bildlaufleisten <\/b>sämtlich auf den Wert Nein <\/b>eingestellt, vorerst benötigen wir jedoch zumindest noch die Navigationsschaltflächen, um Informationen über den beziehungsweise die aktuell angezeigten Datensätze zu erhalten.<\/p>\n Das Bezeichnungsfeld im Formularkopf heißt lblTitel<\/b> und zeigt aktuell den Text Adresse bearbeiten <\/b>an. Warum erhält ein Bezeichnungsfeld einen richtigen Namen Normalerweise ändern wir diesen nie, weil wir kaum einmal per VBA auf Bezeichnungsfelder zugreifen. In diesem Fall soll das Bezeichnungsfeld jedoch je nach Art der Datenbearbeitung entweder den Titel Neue Adresse <\/b>oder Adresse bearbeiten <\/b>anzeigen.<\/p>\n Öffnen des Detailformulars zum Anlegen eines neuen Datensatzes<\/b><\/p>\n Wenn Sie einen neuen Datensatz anlegen möchten, klicken Sie im Formular frmAdressenMitDetailformular <\/b>auf die Schaltfläche cmdNeu <\/b>mit der Beschriftung Neue Adresse<\/b>.<\/p>\n Die Schaltfläche soll nun das Formular frmAdresseDetail <\/b>aufrufen und einen leeren, neuen Datensatz anzeigen. Dazu statten wir die Prozedur cmdNeu_Click<\/b>, die wir durch Auswählen des Wertes [Ereignisprozedur] <\/b>für die Eigenschaft Beim Klicken <\/b>und anschließendes Anklicken der Schaltfläche mit den drei Punkten erzeugen, wie folgt mit einer einzigen Anweisung aus:<\/p>\n Normalerweise würde die Anweisung DoCmd.OpenForm "frmAdresseDetail" <\/b>ausreichen, um das Formular zu öffnen. In diesem Fall brauchen wir jedoch zwei weitere Parameter:<\/p>\n Bild 3 zeigt, wie dies aussieht. Der Datensatzmarkierer bestätigt, dass das Formular neben dem neuen, leeren Datensatz keine weiteren Datensätze enthält.<\/p>\n Bild 3: Anlegen eines neuen Datensatzes über das Detailformular frmAdresseDetail<\/span><\/b><\/p>\n Sie können damit nun einen neuen Datensatz eingeben, aber was geschieht dann Wir müssen zunächst die beiden Schaltflächen cmdOK <\/b>und cmdAbbrechen <\/b>mit Ereignisprozeduren ausstatten. Dies ist normalerweise sehr einfach. Die OK<\/b>-Schaltfläche soll nur das Formular schließen, was die folgende Prozedur erledigt:<\/p>\n Unter normalen Umständen wird der neue Datensatz, sofern einer angelegt wurde, nun gespeichert und das Formular geschlossen.<\/p>\n Die Abbrechen<\/b>-Schaltfläche hingegen soll die änderungen verwerfen und das Formular daraufhin schließen. Das Verwerfen der änderungen erledigt die Undo<\/b>-Methode des Formulars:<\/p>\n Dummerweise kann man änderungen nach dem erstmaligen Speichern des Datensatzes nicht mehr rückgängig machen – mehr dazu erfahren Sie gleich.<\/p>\n Beobachtungen im Detailformular<\/b><\/p>\n Wenn Sie das Detailformular über die Schaltfläche Neue Adresse <\/b>geöffnet haben, zeigt die Navigationsleiste 1 von 1 <\/b>an und die Schaltfläche zum Neuanlegen eines weiteren Datensatzes ist deaktiviert. Sofort nach dem Eingeben des ersten Zeichens in eines der Felder des Formulars ändert sich dies: Die Schaltfläche zum Anlegen eines neuen Datensatzes wird aktiviert. Sie können also nun einen neuen Datensatz anlegen, obwohl Sie den ersten noch gar nicht abgeschlossen haben.<\/p>\n Man sollte meinen, dass man dies durch Einstellen der Eigenschaft Anfügen zulassen <\/b>des Formulars frmAdresseDetail <\/b>auf den Wert Nein <\/b>verhindern kann. Dies gelingt jedoch nur, wenn Sie das Formular ohne das Argument DataMode <\/b>öffnen oder durch einen Doppelklick auf seinen Namen im Datenbankfenster beziehungsweise im Navigationsbereich. DataMode:=acFormAdd <\/b>stellt diese Eigenschaft automatisch auf Ja <\/b>ein, was auch logisch ist.<\/p>\n Wie aber können wir verhindern, dass der Benutzer mehr als einen Datensatz gleichzeitig eingibt, ohne das Formular erneut öffnen zu müssen Wir nehmen ihm einfach die Möglichkeit, zu einem neuen Datensatz zu springen, indem wir die Navigationsleiste durch Einstellen der entsprechenden Eigenschaft auf den Wert Nein <\/b>ausblenden.<\/p>\n Nun kann der Benutzer aber immer noch durch wiederholtes Betätigen der Tab- oder Eingabetaste durch die Steuerelemente navigieren. Wenn er sich auf dem letzten Steuerelement der Aktivierungsreihenfolge befindet und nochmals die Tab- oder Eingabetaste betätigt, landet er ebenfalls in einem neuen Datensatz. Aber auch dies können Sie verhindern: Dazu stellen Sie einfach die Eigenschaft Zyklus <\/b>des Formulars auf Aktueller Datensatz <\/b>ein. Der Fokus landet dann zwar auch wieder beim ersten Steuerelement der Aktivierreihenfolge, jedoch ohne den Datensatz zu wechseln. Sie können dies am besten beobachten, wenn Sie die Navigationsschaltflächen aktivieren und einmal alle Steuerelemente durchlaufen.<\/p>\n Anzeige der richtigen Überschrift<\/b><\/p>\n Eine weitere Beobachtung ist, dass das Formular frmAdresseDetail <\/b>nun natürlich den Text Adresse bearbeiten <\/b>als Beschriftung des Bezeichnungsfeldes lblTitle <\/b>anzeigt, obwohl Sie ja gerade einen neuen Datensatz anlegen. Wir müssen also herausfinden, ob die DoCmd.OpenForm<\/b>-Methode den Wert acFormAdd <\/b>oder acFormEdit <\/b>für den Parameter DataMode <\/b>verwendet hat.<\/p>\n Es gibt sicher ein paar Workarounds, den direkten Weg liefert aber eine nicht dokumentierte und verborgene Eigenschaft namens DefaultEditing<\/b>. Diese enthält in direkter Abhängigkeit vom Wert des Parameters DataMode <\/b>einen der folgenden beiden Werte (es gibt noch weitere, die aber in diesem Zusammenhang irrelevant sind):<\/p>\n Im Code können wir uns dies in einer Ereignisprozedur zunutze machen, die durch das Ereignis Beim Laden <\/b>des Formulars ausgelöst wird. Diese wertet die Eigenschaft DefaultEditing <\/b>aus und weist der Caption<\/b>-Eigenschaft von lblTitle <\/b>den entsprechenden Wert zu:<\/p>\n Gespeicherte änderungen abbrechen<\/b><\/p>\n Schließlich fällt uns beim spielerischen Ausprobieren des Formulars noch auf, dass die Abbrechen<\/b>-Schaltfläche spätestens dann keinen Sinn mehr macht, wenn der Benutzer einen neu angelegten Datensatz erstmalig gespeichert hat, was er normalerweise mit einem Klick auf den Datensatzmarkierer oder durch den Wechseln zu einem anderen Datensatz erledigen kann. Ersteres gelingt nicht, wenn wir den Datensatzmarkierer mit der entsprechenden Eigenschaft ausblenden, das Zweite unterbinden wir mit der Zyklus<\/b>-Eigenschaft.<\/p>\n Es bleibt allerdings noch die Möglichkeit, den Datensatz mit Strg + S <\/b>zu speichern – da dies eine in vielen Anwendungen verbreitete Tastenkombination zum Speichern ist, werden manche Benutzer sie vielleicht automatisch hin und wieder einsetzen (der Autor spricht aus Erfahrung). Beim Speichern werden aber die beiden Ereignisse Vor Aktualisierung <\/b>und Nach Aktualisierung <\/b>ausgelöst. Hier könnten Sie schlicht dafür sorgen, dass die Abbrechen<\/b>-Schaltfläche deaktiviert wird:<\/p>\n Möglicherweise wird der Benutzer nicht verstehen, warum die Abbrechen<\/b>-Schaltfläche plötzlich inaktiv ist. Daher sollten Sie beim Ereignis Vor Aktualisierung <\/b>eine entsprechende Meldung anzeigen (s. Bild 4):<\/p>\n Bild 4: Diese Meldung erscheint beim Versuch, einen Datensatz zu speichern.<\/span><\/b><\/p>\n Wenn der Benutzer nun die Tastenkombination Strg + S <\/b>betätigt, erscheint die Meldung. Beim Klicken auf OK <\/b>wird der Datensatz gespeichert und in der Folge die Abbrechen<\/b>-Schaltfläche des Formulars deaktiviert. Klickt der Benutzer auf die Abbrechen<\/b>-Schaltfläche des Meldungsfensters, wird der Speichervorgang abgebrochen.<\/p>\n Beim reinen Einsatz eines Formulars zum Anlegen neuer Datensätze wäre es auch denkbar, dass man den Datensatz, wenn dieser bereits gespeichert wurde, beim Anklicken der Abbrechen<\/b>-Schaltfläche einfach wieder löscht. In diesem Falle brauchte man die Abbrechen<\/b>-Schaltfläche nach dem vorzeitigen Speichern des neuen Datensatzes auch nicht zu deaktivieren, da sie ja die erwartete Aufgabe erfüllt. Die Abbrechen<\/b>-Schaltfläche müsste dann etwa folgende Prozedur ausführen (die Ereignisprozeduren für Vor Aktualisierung <\/b>und Nach Aktualisierung <\/b>müssten Sie dann verwerfen):<\/p>\n <\/p>\n Die Prozedur prüft zunächst den Datenmodus. Beim Anlegen eines neuen Datensatzes untersucht sie dann mit der Dirty<\/b>-Eigenschaft, ob der Datensatz seit dem letzten Speichern geändert wurde. Wenn Dirty <\/b>den Wert True <\/b>aufweist, wurde der Datensatz offensichtlich noch nicht gespeichert und die änderungen können mit Me.Undo <\/b>verworfen werden, bevor die Prozedur das Formular schließt. Hat Me.Dirty <\/b>den Wert False<\/b>, wurde der Datensatz gespeichert und muss gelöscht werden. Dies erledigt die Delete<\/b>-Methode des Recordset<\/b>-Objekts des Formulars.<\/p>\n Eines haben wir jedoch übersehen: Wenn man den Datensatz speichert und diesen danach erneut bearbeitet, ist er bereits in der Tabelle angelegt. Durch die erneute Bearbeitung ohne wiederholtes Speichern hat aber Me.Dirty <\/b>den Wert True<\/b>, was dazu führt, dass die Abbrechen<\/b>-Schaltfläche lediglich ein Me.Undo <\/b>ausführt und nicht den Datensatz löscht. Wir müssten also eine Variable einsetzen, die beim ersten Speichern auf True <\/b>gestellt wird und beim Ausführen der Abbrechen<\/b>-Schaltfläche statt Me.Dirty <\/b>abgefragt wird.<\/p>\n Die Variable deklarieren Sie wie folgt im Kopf des Klassenmoduls des Formulars frmAdresseDetail<\/b>:<\/p>\n Sie wird im Ereignis Nach Aktualisierung<\/b>, das nach dem Speichern ausgelöst wird, gesetzt:<\/p>\n Der entscheidende Teil der Beim Klicken<\/b>-Ereignisprozedur der Schaltfläche cmdAbbrechen <\/b>sieht dann so aus:<\/p>\n Alternativ können Sie natürlich auch die Tastenkombination Strg + S <\/b>abfangen – aber auch dies ist nicht ganz trivial und soll an dieser Stelle nicht durchgespielt werden.<\/p>\n Bestehende Datensätze bearbeiten<\/b><\/p>\n Wenden wir uns lieber der Schaltfläche Datensatz bearbeiten <\/b>des Formulars frmAdressenMitDetailformular <\/b>zu. Diese soll ebenfalls das Formular frmAdresseDetail <\/b>öffnen – allerdings nicht zum Anlegen eines neuen, sondern zum Bearbeiten eines bestehenden Datensatzes. Hierzu verwenden wir ebenfalls die DoCmd.OpenForm<\/b>-Methode, diesmal allerdings mit einem anderen Wert für den Parameter DataMode<\/b> – nämlich acFormEdit<\/b>. Das reicht allerdings noch nicht ganz: Wir müssen dem Detailformular nämlich auch noch mitteilen, welchen Datensatz es denn überhaupt anzeigen soll. Dazu verwenden wir den Parameter WhereCondition<\/b>: Er erwartet einen Ausdruck, der festlegt, welcher der Datensätze der Datenherkunft des zu öffnenden Formulars angezeigt werden soll. Da die Tabelle tblAdressen <\/b>das Feld AdresseID <\/b>als Primärschlüsselfeld verwendet, benutzen wir dieses logischerweise für die Angabe des Parameters. Das Formular frmAdresseDetail <\/b>soll genau den Datensatz anzeigen, dessen Feld AdresseID <\/b>den Wert des gleichen Feldes des aktuell im Unterformular sfmAdressenMitDetailformular <\/b>markierten Datensatzes aufweist. Dies erreichen Sie mit dem Parameterwert "AdresseID = " & Me!sfmAdressen.Form!AdresseID<\/b>. Der letzte Teil wird beim Aufruf ausgewertet, sodass sich ein Ausdruck wie AdresseID = 12 <\/b>ergibt. Insgesamt sieht die Prozedur, die durch einen Mausklick auf die Schaltfläche Adresse bearbeiten <\/b>ausgelöst wird, so aus:<\/p>\n Wenn Sie im Unterformular sfmAdresseMitDetailformular <\/b>den zu bearbeitenden Datensatz markieren und dann auf Adresse bearbeiten <\/b>klicken, öffnet die Ereignisprozedur das Formular frmAdresseDetail <\/b>wie in Bild 5.<\/p>\n Bild 5: Bearbeiten des aktuell ausgewählten Datensatzes in der Detailansicht<\/span><\/b><\/p>\n Kleinere Probleme<\/b><\/p>\n Ohne weitere Nacharbeiten würde es hier und da haken. Wenn Sie zum Beispiel den Datensatzmarkierer im Unterformular auf den neuen Datensatz verschieben und dann auf die Schaltfläche cmdBearbeiten <\/b>klicken, löst Access einen Fehler aus (s. Bild 6). Das Problem ist, dass der hintere Teil des Ausdrucks für die WhereCondition <\/b>(Me!sfmAdressen.Form!AdresseID<\/b>) den Wert Null <\/b>liefert, weil der markierte leere Datensatz natürlich noch keinen Wert im Feld AdresseID <\/b>aufweist. Dies können Sie auf drei Arten umgehen:<\/p>\n Bild 6: Dieser Fehler tritt auf, wenn beim Aufrufen des Detailformulars kein zu bearbeitender Datensatz markiert ist.<\/span><\/b><\/p>\n Die erste Variante fragt ab, ob das Unterformular gerade einen neuen, nicht gespeicherten Datensatz anzeigt. Falls ja, öffnet die Prozedur nicht das Detailformular, sondern zeigt eine entsprechende Meldung an:<\/p>\n Bei der zweiten Variante soll die Schaltfläche cmdBearbeiten <\/b>einfach deaktiviert werden, wenn das Unterformular einen neuen, leeren Datensatz anzeigt.<\/p>\n Dazu müssen wir bei jedem Datensatzwechsel im Unterformular prüfen, ob dieses gerade auf einem neuen Datensatz steht oder vielleicht sogar gar keinen Datensatz anzeigt (dies geschieht, wenn die Datenherkunft tatsächlich keine Daten enthält oder wenn diese durch Setzen eines entsprechenden Filters herausgefiltert wurden). Legen Sie daher für die Ereigniseigenschaft Beim Anzeigen <\/b>des Unterformulars sfmAdressenMitDetailformular <\/b>die folgende Ereignisprozedur an:<\/p>\n Diese Prozedur wird zumindest einmal beim Öffnen des Formulars und anschließend bei jedem Datensatzwechsel ausgelöst. Sie prüft, ob das Formular gerade einen neuen Datensatz anzeigt oder ob das Recordset<\/b>-Objekt des Formulars keine Datensätze enthält, und aktiviert oder deaktiviert in Abhängigkeit davon die beiden Schaltflächen cmdBearbeiten <\/b>und auch cmdLoeschen<\/b>.<\/p>\n Dies ist eine ergonomisch sehr runde Lösung, da sie dem Benutzer gleich durch Deaktivieren der entsprechenden Schaltflächen zeigt, welche Möglichkeiten sich für die aktuelle Auswahl bieten.<\/p>\n Die dritte Möglichkeit ist das Sperren des Formulars für das Neuanlegen von Datensätzen – dies kann ja bequem durch einen Klick auf die Schaltfläche Neue Adresse <\/b>und anschließendes Eingeben des neuen Datensatzes im Formular frmAdresseDetail <\/b>geschehen.<\/p>\n Und auch das Bearbeiten bestehender Datensätze können wir eigentlich verhindern, denn auch dies kann der Benutzer im entsprechenden Formular viel komfortabler erledigen. Stellen Sie abhängig von Ihren Anforderungen einfach eine oder mehrere der Eigenschaften Anfügen zulassen<\/b>, Löschen zulassen <\/b>und Bearbeiten zulassen <\/b>auf den Wert Nein <\/b>ein. Wenn Sie generell keine Bearbeitung der enthaltenen Daten erlauben möchten, können Sie auch einfach den Wert Snapshot <\/b>für die Eigenschaft Recordsettyp <\/b>auswählen.<\/p>\n Leider werden die einzelnen Steuerelemente des Unterformulars auf diese Weise nicht gesperrt, sodass es immer noch möglich ist, die Einfügemarke beispielsweise in einem Textfeld zu platzieren – dies suggeriert dem Benutzer unnötigerweise, dass die enthaltenen Daten noch geändert werden könnten. Beim Versuch, dies zu tun, ertönt jedoch ein Warnton und die Statusleiste zeigt einen entsprechenden Hinweis an.<\/p>\n Obwohl Sie den Datensatzmarkierer nun nicht mehr auf einen neuen Datensatz verschieben können, sollten Sie die oben beschriebene Technik zum Aktivieren und Deaktivieren der Schaltflächen cmdBearbeiten <\/b>und cmdLoeschen <\/b>beibehalten – immerhin kann der Benutzer die Anzahl der angezeigten Datensätze immer noch durch das Setzen eines entsprechenden Filters auf 0 <\/b>herunterschrauben und dann sollen die Schaltflächen zum Bearbeiten und Löschen eines Datensatzes natürlich gesperrt sein.<\/p>\n Bearbeiten im Detailformular<\/b><\/p>\n Damit gelangen wir zur eigentlichen Aufgabe: zum Bearbeiten des ausgewählten Datensatzes im Detailformular. Da wir das gleiche Formular wie für das Anlegen eines neuen Adressdatensatzes verwenden wollen, findet der Benutzer auch die beiden Schaltflächen cmdOK <\/b>und cmdAbbrechen <\/b>vor. Die Schaltfläche cmdOK <\/b>soll das Formular einfach schließen, was den enthaltenen Datensatz immer automatisch speichert (zumindest fast immer – mehr dazu weiter unten). Die Schaltfläche cmdAbbrechen <\/b>soll die seit dem Öffnen vorgenommenen änderungen verwerfen, also das Formular ohne Speichern schließen. Dies ist, wie schon beim Anlegen eines Datensatzes angemerkt, nicht so einfach: Der Benutzer kann nämlich auch hier zwischenzeitlich die änderungen speichern, was die Funktion der Abbrechen<\/b>-Schaltfläche eigentlich ad absurdum führt.<\/p>\n Während wir beim Anlegen eines Datensatzes aber ganz einfach die Möglichkeit haben, diesen Vorgang durch Löschen des Datensatzes wieder rückgängig zu machen, ist dies beim ändern des Datensatzes nicht so leicht: Wir müssten dazu nämlich irgendwo die vor der änderung gültigen Werte der einzelnen Felder speichern. Jedes Feld besitzt zwar eine Eigenschaft namens OldValue<\/b>, welche die beim Anzeigen des Datensatzes gültigen Werte enthält, aber diese werden beim Speichern des Datensatzes mit den aktuellen Werten überschrieben. OldValue <\/b>kann nur dann die alten Werte liefern, solange der Datensatz nicht gespeichert wurde – also beispielsweise dann, wenn Sie den Datensatz zwar geändert, diese änderungen aber mit der Undo<\/b>-Methode eines einzelnen Feldes oder des kompletten Formulars wieder rückgängig gemacht haben. In diesem Fall schreibt Access für alle Felder die Werte von OldValue <\/b>in die Eigenschaft Value <\/b>zurück.<\/p>\n Was also können wir tun, wenn wir den vorherigen Zustand wiederherstellen wollen, obwohl der Datensatz bereits gespeichert ist und somit die alten Feldwerte verworfen wurden Wir müssen diese einfach irgendwo zwischenspeichern und beim Anklicken der Abbrechen<\/b>-Schaltfläche wiederherstellen.<\/p>\n Unter Access besitzt fast jedes Objekt eine Eigenschaft namens Tag<\/b>, die üblicherweise nicht genutzt wird – es sei denn für Spezialfälle wie diesen hier. Wir müssen also beim Anzeigen des Datensatzes die Werte aller gebundenen Steuerelemente in die Tag<\/b>-Eigenschaft des jeweiligen Steuerelements schreiben und diese von dort beim Klick auf die Abbrechen<\/b>-Schaltfläche wieder in die Value<\/b>-Eigenschaft der betroffenen Steuerelemente zurückschreiben.<\/p>\n Das Übertragen in die Tag<\/b>-Eigenschaft übernimmt eine Prozedur, die durch das Ereignis Beim Anzeigen <\/b>des Formulars frmAdresseDetail <\/b>ausgelöst wird. Diese durchläuft alle Steuerelemente des Formulars und lässt diejenigen aus, deren Eigenschaft ControlType <\/b>den Wert 100 <\/b>(Bezeichnungsfeld) oder 104 <\/b>(Schaltfläche) besitzt (wir könnten noch weitere Steuerelementtypen ausschließen, aber in diesem Beispiel ist dies nicht nötig). Für die übrigen prüft die Prozedur, ob deren Eigenschaft ControlSource <\/b>(Steuerelementinhalt<\/b>) einen Wert enthält, was auf ein gebundenes Steuerelement hinweist. Ist dies der Fall, schreibt die Prozedur den aktuellen Wert des Steuerelements in seine Tag<\/b>-Eigenschaft:<\/p>\n Passend dazu müssen Sie natürlich auch noch die Prozedur erweitern, die beim Anklicken der Abbrechen<\/b>-Schaltfläche aufgerufen wird:<\/p>\n Die Prozedur prüft, wie bereits weiter oben erwähnt, anhand der Eigenschaft DefaultEditing<\/b>, ob das Formular zum Anlegen eines neuen oder zum Bearbeiten eines bestehenden Datensatzes geöffnet wurde. In unserem Fall enthält diese den Wert 2<\/b>.<\/p>\n Der betreffende Zweig der Select Case<\/b>-Bedingung durchläuft wieder alle Steuerelemente außer den Bezeichnungsfeldern und Schaltflächen und weist ihrer Eigenschaft Value <\/b>den in der Eigenschaft Tag <\/b>gespeicherten alten Wert zu – dies aber auch nur für gebundene Steuerelemente.<\/p>\n Diese Methode ist gut einsetzbar, wenn es sich um Daten aus einer einfachen Tabelle handelt. Sobald das Detailformular jedoch Daten aus verknüpften Tabellen anzeigt und dabei einen Teil der Daten in einem Unterformular darstellt, wird es kompliziert – immerhin kann das Unterformular selbst mehrere mit dem Datensatz des Hauptformulars verknüpfte Datensätze enthalten, und Sie müssten für all diese Datensätze die alten Werte vorhalten, um diese gegebenenfalls später wiederherzustellen.<\/p>\n Aktualisieren der Adressenliste nach Anfügen oder Bearbeiten<\/b><\/p>\n Nach dem Anfügen eines neuen Datensatzes oder dem Bearbeiten eines bestehenden Datensatzes wird das Detailformular mit der DoCmd.Close<\/b>-Methode geschlossen.<\/p>\n Das bedeutet jedoch nicht, dass die Daten im Unterformular des aufrufenden Formulars automatisch aktualisiert werden: Weder erscheinen neu angelegte Datensätze umgehend, noch werden geänderte Datensätze sofort aktualisiert.<\/p>\n Und hier kommt der Parameter WindowMode:=acDialog <\/b>ins Spiel, den Sie beim Aufrufen des Detailformulars angegeben haben. Dieser sorgt nämlich dafür, dass die aufrufende Prozedur nach dem Ausführen von DoCmd.OpenForm <\/b>angehalten wird und erst weiterläuft, wenn das geöffnete Formular wieder geschlossen wurde.<\/p>\n Natürlich sorgt dieser Parameter erstmal dafür, dass der Benutzer keine Daten in anderen Formularen bearbeiten kann, solange frmAdresseDetail <\/b>geöffnet ist, aber es ist ebenso wichtig, dass wir unmittelbar auf das Schließen dieses Formulars reagieren können.<\/p>\n Sie haben dann nämlich Gelegenheit, die Aktualisierung des Unterformulars sfmAdressenMitDetailformular <\/b>gleich nach dem Schließen des Detailformulars per Code anzustoßen. Dies sieht dann zum Beispiel beim Anlegen eines neuen Datensatzes so aus:<\/p>\n Die Requery<\/b>-Methode des im Unterformular befindlichen Formulars sorgt hier gleich nach dem Schließen des aufgerufenen Formulars für seine Aktualisierung.<\/p>\n Schließen speichert Datensatz – oder doch nicht<\/b><\/p>\n Gelegentlich kommt es beim Einsatz von Detailformularen zu dem Problem, dass ein frisch angelegter Datensatz nach dem Schließen des Detailformulars einfach nicht unter den gespeicherten Datensätzen auftaucht. Sie können dies ganz leicht nachvollziehen:<\/p>\n Bild 7: Tabelle mit einem Feld, das keine Duplikate zulässt<\/span><\/b><\/p>\n Das Formular wird anstandslos geschlossen, obwohl Sie einen doppelten Wert in das Feld Beispieltext <\/b>eingegeben haben. Normalerweise sollte eine Meldung erscheinen, die Sie auf die Eingabe eines doppelten Wertes hinweist. Dies geschieht aber nur, wenn Sie den Datensatz speichern, bevor Sie das Formular mit der OK<\/b>-Schaltfläche schließen, oder wenn Sie das Formular auf einem anderen Wege, beispielsweise über die Schließen<\/b>-Schaltfläche oben rechts, schließen. Dieses Problem besteht auch, wenn Sie Felder definieren, die keinen Nullwert enthalten dürfen et cetera.<\/p>\n Sie sollten daher in solchen Fällen vor dem Schließen per DoCmd.Close <\/b>eine Anweisung zum Speichern des aktuellen Datensatzes vorschalten. Wenn es Probleme mit dem Speichern des Datensatzes gibt, löst dies einen Fehler aus – im Beispiel des eindeutigen Indexes beispielsweise den Fehler 3022<\/b>. Diesen fangen Sie entsprechend ab:<\/p>\n Die Anweisung Application.RunCommand <\/b>mit dem Parameter acCmdSaveRecord <\/b>versucht, den Datensatz zu speichern. Wenn dies misslingt, fängt die Prozedur den in unserem Beispiel auftretenden Fehler 3022 <\/b>ab und gibt eine entsprechende Meldung aus. Das Formular wird in diesem Fall nicht geschlossen.<\/p>\n Detailformular bei Daten aus 1:n-Beziehungen<\/p>\n Etwas komplizierter wird es noch, wenn das Haupt- und das Unterformular Daten anzeigen, deren Herkunftstabellen in einer 1:n-Beziehung stehen.<\/p>\n Dies ist beispielsweise bei den Formularen frmKundenProjekte <\/b>und sfmKundenProjekte <\/b>der Fall, wo das Hauptformular die Daten der Tabelle tblKunden <\/b>anzeigt und das Unterformular die Datensätze der Tabelle tblProjekte<\/b>, die mit den Kunden im Hauptformular verknüpft sind. Bild 8 zeigt das Datenmodell dieser Beziehung.<\/p>\n Bild 9: Aufruf des Detailformulars für Daten in einer 1:n-Beziehung<\/span><\/b><\/p>\n Das Detailformular, das wie in Bild 9 aufgerufen wird, bietet dabei üblicherweise die Möglichkeit, den betreffenden Kunden auszuwählen. Da das Detailformular jedoch vom Formular frmKundenProjekte<\/b> stets im Kontext eines bestimmten Kunden aufgerufen wird, können wir zwei Anforderungen festhalten:<\/p>\n Bild 8: Verknüpfte Tabellen des zweiten Beispiels<\/span><\/b><\/p>\n Wie aber erfährt das Detailformular, für welchen Kunden es das neue Projekt anlegen soll Hierzu verwenden wir einen weiteren Parameter der DoCmd.OpenForm<\/b>-Methode. Der Aufruf, der durch das Ereignis Beim Klicken <\/b>der Schaltfläche cmdNeu <\/b>des Hauptformulars ausgelöst wird, sieht so aus:<\/p>\n Der neue Parameter heißt OpenArgs <\/b>und soll den Wert des Feldes KundeID <\/b>im Hauptformular enthalten. Im Detailformular können wir den übergebenen Wert über die Eigenschaft OpenArgs <\/b>des Formulars auslesen und dazu verwenden, den Wert des Kombinationsfeldes zur Auswahl auf diesen Kunden voreinzustellen.<\/p>\n Die Betonung liegt hierbei auf „vor", denn wir dürfen lediglich den Standardwert für dieses Feld auf den übergebenen Wert einstellen und nicht den Wert selbst. Dies würde nämlich dazu führen, dass der Datensatz gleich als Dirty <\/b>gekennzeichnet würde – und dies soll doch erst geschehen, wenn der Benutzer sich tatsächlich an diesem zu schaffen gemacht hat.<\/p>\n Wir bringen also im Klassenmodul des Detailformulars frmProjektDetail <\/b>eine Ereignisprozedur unter, die durch das Ereignis Beim Laden <\/b>ausgelöst wird:<\/p>\n Die Prozedur prüft zunächst, ob Me.OpenArgs <\/b>überhaupt einen Wert enthält. Falls ja, füllt sie die Eigenschaft DefaultValue <\/b>des Steuerelements KundeID<\/b> mit dem dort enthaltenen Wert. Im geöffneten Formular wirkt sich dies wie in Bild 9 aus: Das Feld KundeID <\/b>wird mit dem richtigen Eintrag vorbelegt.<\/p>\n Wir können das Feld KundeID <\/b>also entweder ausblenden oder zumindest deaktivieren, damit der Benutzer keinen anderen Kunden auswählen kann. Dies würde möglicherweise zu Irritationen führen, wenn der Benutzer die Eingabe abschließt und dann im aufrufenden Formular frmKundenProjekte <\/b>nicht gleich das neue Projekt sieht – dieses wurde schließlich einem anderen als dem voreingestellten Kunden zugewiesen.<\/p>\n Bearbeiten von Daten aus 1:n-Beziehungen<\/b><\/p>\n Das Bearbeiten eines vorhandenen Datensatzes verläuft wiederum genau wie beim Bearbeiten eines Datensatzes aus einer einfachen Tabelle. Es ist nicht nötig, den Inhalt des Feldes KundeID <\/b>des Kunden eigens per Öffnungsargument an das Detailformular zu übergeben, da diese ja bereits in dem zu bearbeitenden Datensatz gespeichert ist. Sie sollten das entsprechende Steuerelement jedoch im Formular frmProjektDetail <\/b>ausblenden, damit der Benutzer die Zuordnung nicht ändern kann – auch dies würde nach dem Schließen des Formulars wiederum zu Fragen führen.<\/p>\n Der Aufruf geschieht also in einer Ereignisprozedur wie dieser:<\/p>\n Die übrigen Techniken stimmen mit denen des ersten Beispiels zur Eingabe der Adressen überein. <\/p>\n Zusammenfassung und Ausblick<\/b><\/p>\n Die Eingabe von Daten mithilfe von Detailformularen ist grundsätzlich einfach zu bewerkstelligen, aber manchmal steckt der Teufel halt im Detail. Dieser Beitrag erläutert die grundlegenden Techniken, um Detailformulare für neue und zu bearbeitende Datensätze zu öffnen und das aufrufende Formular nach dem Bearbeiten zu aktualisieren.<\/p>\n Es bleiben jedoch noch eine Reihe Themen offen:<\/p>\n![\"pic002.png\"](\"..\/fileadmin\/_temp_\/2010_05\/UnterformularDetailansicht-web-images\/pic002.png\")
<\/p>\nPrivate Sub cmdNeu_Click()\r\n DoCmd.OpenForm "frmAdresseDetail",\r\n WindowMode:=acDialog, DataMode:=acFormAdd\r\nEnd Sub<\/pre>\n
\n
![\"pic003.png\"](\"..\/fileadmin\/_temp_\/2010_05\/UnterformularDetailansicht-web-images\/pic003.png\")
<\/p>\nPrivate Sub cmdOK_Click()\r\n DoCmd.Close acForm, Me.Name\r\nEnd Sub<\/pre>\n
Private Sub cmdAbbrechen_Click()\r\n Me.Undo\r\n DoCmd.Close acForm, Me.Name\r\nEnd Sub<\/pre>\n
\n
Private Sub Form_Load()\r\n Select Case Me.DefaultEditing\r\n Case 1\r\n Me!lblTitel.Caption = "Neue Adresse anlegen"\r\n Case 2\r\n Me!lblTitel.Caption = "Adresse bearbeiten"\r\n End Select\r\nEnd Sub<\/pre>\n
Private Sub Form_AfterUpdate()\r\n Me!cmdAbbrechen.Enabled = False\r\nEnd Sub<\/pre>\n
![\"pic004.png\"](\"..\/fileadmin\/_temp_\/2010_05\/UnterformularDetailansicht-web-images\/pic004.png\")
<\/p>\nPrivate Sub Form_BeforeUpdate(Cancel As Integer)\r\n If MsgBox("änderungen können nach dem Speichern nicht mehr mit Abbrechen oder " _\r\n & "Escape verworfen werden. Fortsetzen", vbOKCancel + vbExclamation, _\r\n "Datensatz wird gespeichert") = vbCancel Then\r\n Cancel = True\r\n End If\r\nEnd Sub<\/pre>\nPrivate Sub cmdAbbrechen_Click()\r\n Select Case Me.DefaultEditing\r\n Case 1 ''Neuer Datensatz\r\n If Me.Dirty Then\r\n Me.Undo\r\n Else\r\n Me.Recordset.Delete\r\n End If\r\n Case 2 ''Datensatz bearbeiten\r\n Me.Undo\r\n End Select\r\n DoCmd.Close acForm, Me.Name\r\nEnd Sub<\/pre>\n
Dim bolGespeichert As Boolean<\/pre>\n
Private Sub Form_AfterUpdate()\r\n bolGespeichert = True\r\nEnd Sub<\/pre>\n
If Not bolGespeichert Then\r\n Me.Undo\r\nElse\r\n Me.Recordset.Delete\r\nEnd If<\/pre>\n
Private Sub cmdBearbeiten_Click()\r\n DoCmd.OpenForm "frmAdresseDetail", WindowMode:=acDialog, _\r\n DataMode:=acFormEdit, WhereCondition:="AdresseID = " & Me!sfmAdressen.Form!AdresseID\r\nEnd Sub<\/pre>\n
![\"pic005.png\"](\"..\/fileadmin\/_temp_\/2010_05\/UnterformularDetailansicht-web-images\/pic005.png\")
<\/p>\n![\"pic006.png\"](\"..\/fileadmin\/_temp_\/2010_05\/UnterformularDetailansicht-web-images\/pic006.png\")
<\/p>\n\n
Private Sub cmdBearbeiten_Click()\r\n If Not Me!sfmAdressen.Form.NewRecord Then\r\n DoCmd.OpenForm "frmAdresseDetail", ...\r\n Else\r\n MsgBox "Bitte markieren Sie den anzuzeigenden Datensatz.", _\r\n vbOKOnly + vbExclamation, "Kein Datensatz ausgewählt"\r\n End If\r\nEnd Sub<\/pre>\n
Private Sub Form_Current()\r\n Dim bolNewRecord As Boolean\r\n Dim bolNoRecord As Boolean\r\n bolNewRecord = Me.NewRecord\r\n bolNoRecord = Me.Recordset.EOF\r\n Me.Parent!cmdBearbeiten.Enabled = Not bolNewRecord And Not bolNoRecord\r\n Me.Parent!cmdLoeschen.Enabled = Not bolNewRecord And Not bolNoRecord\r\nEnd Sub<\/pre>\n
Private Sub Form_Current()\r\n Dim ctl As Control\r\n For Each ctl In Me.Controls\r\n Select Case ctl.ControlType\r\n Case 100, 104\r\n Case Else\r\n If Len(ctl.ControlSource) > 0 Then\r\n ctl.Tag = IsNull(ctl.Value)\r\n End If\r\n End Select\r\n Next ctl\r\nEnd Sub<\/pre>\n
Private Sub cmdAbbrechen_Click()\r\n Dim ctl As Control\r\n Select Case Me.DefaultEditing\r\n Case 1 ''Neuer Datensatz\r\n If Not bolGespeichert Then\r\n Me.Undo\r\n Else\r\n Me.Recordset.Delete\r\n End If\r\n Case 2 ''Datensatz bearbeiten\r\n For Each ctl In Me.Controls\r\n Select Case ctl.ControlType\r\n Case 104, 100\r\n Case Else\r\n If Len(ctl.ControlSource) > 0 Then\r\n ctl.Value = ctl.Tag\r\n End If\r\n End Select\r\n Next ctl\r\n End Select\r\n DoCmd.Close acForm, Me.Name\r\nEnd Sub<\/pre>\n
Private Sub cmdNeu_Click()\r\n DoCmd.OpenForm "frmAdresseDetail", _\r\n WindowMode:=acDialog, DataMode:=acFormAdd\r\n Me!sfmAdressen.Form.Requery\r\nEnd Sub<\/pre>\n
\n
![\"pic007.png\"](\"..\/fileadmin\/_temp_\/2010_05\/UnterformularDetailansicht-web-images\/pic007.png\")
<\/p>\nPrivate Sub cmdOK_Click()\r\n On Error Resume Next\r\n Application.RunCommand acCmdSaveRecord\r\n If Err.Number = 3022 Then\r\n MsgBox "Das Formular enthält fehlerhafte Daten."\r\n Exit Sub\r\n End If\r\n On Error GoTo 0\r\n DoCmd.Close acForm, Me.Name\r\nEnd Sub<\/pre>\n
![\"pic008.png\"](\"..\/fileadmin\/_temp_\/2010_05\/UnterformularDetailansicht-web-images\/pic008.png\")
<\/p>\n![\"pic009.png\"](\"..\/fileadmin\/_temp_\/2010_05\/UnterformularDetailansicht-web-images\/pic009.png\")
<\/p>\n\n
Private Sub cmdNeu_Click()\r\n DoCmd.OpenForm "frmProjektDetail", WindowMode:=acDialog, _\r\n DataMode:=acFormAdd, OpenArgs:=Me!KundeID\r\nEnd Sub<\/pre>\n
Private Sub Form_Load()\r\n If Not IsNull(Me.OpenArgs) Then\r\n Me!KundeID.DefaultValue = Me.OpenArgs\r\n End If\r\nEnd Sub<\/pre>\n
Private Sub cmdBearbeiten_Click()\r\n DoCmd.OpenForm "frmProjektDetail", WindowMode:=acDialog, _\r\n DataMode:=acFormEdit, WhereCondition:="ProjektID = " _\r\n & Me!sfmKundenProjekte.Form!ProjektID\r\n Me!sfmKundenProjekte.Form.Requery\r\nEnd Sub<\/pre>\n