Unabhängige Formulare

Formulare sind ein zentraler Bestandteil jeder Access-Anwendung. Damit eine Access-Anwendung flexibel erweitert werden kann, ist es hilfreich, wenn bereits die Formulare flexibel gestaltet werden. Ein wichtiges Konzept für diese Gestaltung ist die Kapselung.

Was ist Kapselung?

Kapselung ist ein Konzept aus der objektorientierten Programmierung. Im Prinzip ist es eine Zugriffskontrolle auf Elemente einer Klasse.
(Wikipedia: Datenkapselung
)

Zugriffsregel

Auf Elemente einer Klasse darf nur über definierte Schnittstellen zugegriffen werden. Diese Schnittstellen können Eigenschaften, Methoden oder Ereignisse sein. Was im "Inneren" dieser Klassen abläuft, darf für die Zugriffe von "außen" keine Rolle spielen.

Wenn diese Regel beachtet wird, kann der Code innerhalb einer Prozedur ohne Probleme geändert werden. Solange sich an den Schnittstellen nichts ändert, muss kein Element verändert werden, das diese Klasse nutzt.

Dieses Prinzip kann man auch bei Formularen anwenden. Stellen Sie sich die Steuerelemente als Eigentum des Formulars vor. Zugriff auf diese Elemente sind nur erlaubt, wenn beim Formular nachgefragt wird. Nachgefragt wird mittels Property-Prozeduren oder Methoden. Diese geben den Zugriff auf die Inhalte frei.

Beispiel: Zugriff auf Unterformular

Gegeben: Hauptformular mit Unterformular. Vom Hauptformular aus soll ein Datenwert aus dem Unterformular abgefragt werden.

Direkter Zugriff auf Steuerelement bzw. Datenfeld
 
X = me!sfrABC.Form!X
Gekapselter Zugriff über Property-Prozedur
X = me.sfrABC.Form.WertVonX

 

Die Property-Prozedur muss allerdings im Unterformular definiert werden:

Public Property Get WertVonX() As String
   WertVonX = Nz(Me!X, vbNullString)
End Property

Das ist doch nur umständlich!

 

Auf den ersten Blick sieht das durchaus umständlich aus. Aber stellen Sie sich vor, dass Sie das Unterformular überarbeiten und das Datenfeld "X" nun nicht mehr im Unterformular enthalten ist, da es in ein Unterformular des Unterformulars verlagert wurde.
Nun müssten Sie in jedem Formular, in dem das geänderte Formular als Unterformular verwendet wird, den Zugriff umschreiben.
In der Property-Variante ändern Sie die Prozedur einmalig - und zwar genau in dem einen Formular, das Sie gerade bearbeiten. Da dabei die Schnittstelle (Eigenschaft WertVonX) nicht geändert wird, muss auch kein abhängiges Formular geändert werden.

 
Geänderte Property-Prozedur
Public Property Get WertVonX() As String
   WertVonX = Me.sfrNeuesUF.Form.WertVonX
End Property

Genau diese Unabhängigkeit von Änderungen im „Inneren“ ist das Ziel der Kapselung.

 

Beispiel: Edit-Modus

Bei Eingabeformularen kann es sinnvoll sein, über einen „Edit-Button“ im Hauptformular die Datensatzänderungen zu aktivieren. (Anfangs wird das Formular mit AllowEdits = False geöffnet. Erst das Betätigen der Edit-Schaltfläche schaltet auf AllowEdits = True um.)

Wenn Unterformulare verwendet werden, muss dieses Umschalten auch bei den Formularen der Unterformularsteuerelemente durchgeführt werden.

Me.sfrABC.Form.AllowEdits = True
Me.sfrXYZ.Form.AllowEdits = True
...

Falls in den Unterformularen noch weitere Unterformulare vorhanden sind, müssen auch diese eingestellt werden.

 

Damit man das nicht bei jedem Formular mit Unterformularen beachten muss, ist es hilfreich, in jedem betroffenen Formular eine Methode einzufügen, die diese Umstellung durchführt.
Vorteil: Jedes Formular kennt seine Unterformulare. Für die Unterformulare des Unterformulars ist aber bereits die Methode des jeweiligen Unterformulars zuständig. Damit kann man in einem Hauptformular nie ein Unterformular der Unterformulare übersehen.

 

Public Property Let AllowDataEdits(allowEdit As Boolean)
   Me.AllowEdits = allowEdit
   Me.AllowAdditions = allowEdit
   If allowEdit OR (Me.RecordsetClone.RecordCount <> 0) Then
      Me.sfrEinUF.Form.AllowDataEdits = allowEdit
      Me.sfrNochEinUF.Form.AllowDataEdits = allowEdit
   End If
End Property

Anm.: If allowEdit OR (Me.RecordsetClone.RecordCount <> 0) verhindert eine Fehlermeldung, wenn im Formular kein Datensatz vorhanden und somit auch das Unterformular nicht verfügbar ist.

In diese Prozedur könnte auch noch eine visuelle Änderung der Steuerelemente eingebaut werden, damit der Benutzer sofort erkennt, ob die Formularfelder bearbeitet werden können.
Auch eine Prüfung, ob der Benutzer die Daten überhaupt ändern darf, ist in dieser Prozedur gut aufgehoben.

 

Beispiel: Datenfilterung

Falls Sie einmal von einem Hauptformular aus die Datensätze in einem Unterformular filtern wollen, vermeiden Sie den direkten Zugriff auf die vorhandene Filter-Eigenschaft. Denn sollten Sie einmal das Unterformular bezüglich Datenzugriff ändern und z. B. die Datenherkunft des Formulars samt Filterkriterien einstellen, bewirkt die Filter-Eigenschaft möglicherweise nicht den gewünschten Effekt.
Wenn sie eine Hilfsprozedur zur Filterübergabe einsetzen, ist die eigentliche Datenfilterung in der Hand des jeweiligen Formulars und bei einer Änderung des Datenzugriffs muss keine Schnittstelle geändert werden.

Pubic Sub SetFilter(filterString as string)
   Me.Filter = filterString
   Me.FilterOn = (len(filterString)>0)
End Sub

Sollte nun die Datenherkunft direkt gefiltert werden, müssen Sie nur diese Prozedur ändern.

Pubic Sub SetFilter(filterString as string)
   Dim strSQL as String
   strSQL = "select ... from Tabelle"
   If len(filterString) > 0 then
      strSQL = strSQL & " where " & filterString
   End If
   Me.Recordsource = strSQL
End Sub

Sie sehen, dass bereits mit einfachen Mitteln das Prinzip der Kapselung umgesetzt werden kann.

 

Die konsequente Umsetzung von gekapselten Formularelementen ist anfangs etwas aufwendiger als das direkte Zugreifen auf die Elemente von außen. Spätestens bei den ersten Änderungen oder Erweiterungen macht sich dieser Aufwand aber bezahlt. Außerdem ist das Formular durch diese Gestaltung unabhängig von Aufbau anderer Formulare und kann somit an beliebiger Stelle eingesetzt werden. Wer den Schnittstellenprozeduren aussagekräftige Namen gibt, wird mit einem gut lesbaren Code belohnt.