{"id":55000682,"date":"2009-10-01T00:00:00","date_gmt":"2020-05-22T22:17:28","guid":{"rendered":"http:\/\/access-im-unternehmen.aix-dev.de\/aiu\/?p=682"},"modified":"-0001-11-30T00:00:00","modified_gmt":"-0001-11-30T00:00:00","slug":"Modale_Dialoge_mal_anders","status":"publish","type":"post","link":"https:\/\/access-im-unternehmen.de\/Modale_Dialoge_mal_anders\/","title":{"rendered":"Modale Dialoge mal anders"},"content":{"rendered":"

\"\"<\/p>\n

Unter modalen Dialogen verstehen wir Formulare zur Eingabe von Daten, die so geöffnet werden, dass der Benutzer während der Eingabe nichts anderes in Access erledigen kann als in diesem Formular zu arbeiten. Zum Öffnen eines solchen Formulars verwendet man üblicherweise den Parameter WindowMode:=acDialog, was den praktischen Nebeneffekt hat, dass der aufrufende Code stehen bleibt. Wir zeigen, welche Vor- und Nachteile dies bringt und welche Alternative es gibt.<\/b><\/p>\n

Der übliche Ablauf beim Einsatz modaler Dialoge, etwa zum Anlegen eines neuen Datensatzes, ist dieser:<\/p>\n

Sie öffnen das Formular mit einer Anweisung wie folgt:<\/p>\n

DoCmd.OpenForm \"Formularname\", WindowMode:=acDialog, DataMode:=acFormAdd, OpenArgs:=lngId<\/pre>\n
Dabei sorgt WindowMode:=acDialog <\/b>für das Öffnen als modaler Dialog. DataMode:=acFormAdd <\/b>teilt dem Formular mit, dass es nur einen neuen, leeren Datensatz anzeigen soll, und mit OpenArgs <\/b>übergeben Sie optional eine Information wie etwa den Fremdschlüsselwert für die Verknüpfung des neuen Datensatzes mit der übergeordneten Tabelle.<\/p>\n
Das Popup-Formular öffnet sich, der Benutzer kann nichts anderes tun, als die Daten einzugeben (alle anderen Access-Elemente sind in dieser Zeit tabu), und dann schließt der Benutzer das Formular auf eine von zwei Arten. Die erste offeriert in der Regel eine OK<\/b>-Schaltfläche, die das Formular mit der folgenden Anweisung unsichtbar schaltet:<\/p>\n
Me.Visible = False<\/pre>\n
Die zweite schließt das Formular gleich komplett:<\/p>\n
DoCmd.Close acForm, Me.Name<\/pre>\n
Beide sorgen dafür, dass das Formular verschwindet und dass der aufrufende Code weiterläuft, da das Formular den Fokus abgegeben hat. Wo aber ist der Unterschied Er liegt darin, dass der aufrufende Code noch auf das unsichtbare Formular zugreifen kann, um den Inhalt seiner Steuerelemente einzulesen – in den meisten Fällen holt es sich dabei die ID des neu angelegten Datensatzes. Dazu muss die Routine prüfen, ob das Formular noch geöffnet ist, was dann als sicheres Indiz dafür gilt, dass es über die OK<\/b>-Schaltfläche „geschlossen“ wurde:<\/p>\n
If IstFormularGeoeffnet(\"Formularname\") Then\r\n    €šLese wichtige Felder aus\r\nEnd If<\/pre>\n
Welche Nachteile hat dies Im Wesentlichen die folgenden zwei:<\/p>\n
Die Datenübergabe an das aufgerufene Formular ist je nach Anzahl der zu übergebenden Informationen aufwendig, weil prinzipiell nur der OpenArgs<\/b>-Parameter dafür bereitsteht. Und dem kann man mehrere Parameter gleichzeitig auch nur dann unterjubeln, wenn man diese mit einem geeigneten Trennzeichen oder einem anderen speziellen Format auszeichnet und im aufgerufenen Formular entsprechend parst.<\/p>\n
Gleichzeitig müssen Sie eine Abhängigkeit vom Popup-Formular zum aufrufenden Formular eingehen. Wenn der Benutzer das Popup-Formular mit der OK<\/b>-Schaltfläche schließt, wird dieses ja nur unsichtbar geschaltet. Das aufrufende Formular muss es dann nach dem Auslesen der Daten noch schließen. Das ist nicht gut, denn: Wenn die aufrufende Instanz dies nicht weiß, bleibt das Popup-Formular geöffnet. Das wiederum führt dazu, dass beim nächsten Öffnen per DoCmd.OpenForm <\/b>verwendete Parameter wirkungslos verpuffen.<\/p>\n
Alles neu<\/b><\/p>\n
Schauen wir uns also die alternative Variante an. Diese soll Folgendes ermöglichen:<\/p>\n