Beständige Objektvariablen

Objektvariablen benötigen Sie immer wieder. Manchmal werden diese sogar in mehreren Routinen eines einzigen Moduls eingesetzt – etwa eine Objektvariable mit einem Verweis auf ein ActiveX- oder ein MSForms-Steuerelement. Aus Performancegründen deklariert man diese oft modulweit – was aber auf Dauer nicht immer gut geht. Access im Unternehmen stellt eine Alternative vor.

Es gibt eine ganze Reihe von Gründen, dafür zu sorgen, dass eine Objektvariable einen Verweis auf ein Objekt über längere Zeit hält. Zwei davon sind Stabilität und Performance. Die beiden folgenden Beispiele zeigen, wie Sie eine scheinbar ständige Verfügbarkeit von Objektvariablen und den referenzierten Objekten erreichen und warum Sie dies tun sollten.

Fehler zerstören Verweise

Wer gelegentlich mit Objekten wie ActiveX-Steuerelementen arbeitet und die Vorzüge von
IntelliSense genießen möchte, deklariert im VBA-Code eine Objektvariable mit dem Schlüsselwort WithEvents.

üblicherweise erfolgt die Deklaration modulweit, sodass man der Objektvariable den Verweis auf das Steuerelement nur einmal beim öffnen des zugrunde liegenden Formulars setzen muss und ihn beim Schließen wieder zerstören kann. Betrachten Sie folgendes Beispiel (s. Beispieldatenbank, Formular frmTreeView): Hier enthält ein Formular ein TreeView-Steuerelement namens ctlTreeView, für das mit folgender Zeile im Formularmodul eine Objektvariable deklariert wird (siehe Bild 1):

Dim WithEvents objTreeView As MSComctlLib.TreeView
pic001.tif

Bild 1: Das TreeView-Steuerelement des Beispielformulars wird in VBA per Objektvariable referenziert.

Die Zuweisung und gegebenenfalls das Füllen mit Daten erfolgt im Ereignis Beim Laden und sieht etwa wie folgt aus:

Private Sub Form_Load(Cancel As Integer)
 Set objTreeView = Me!ctlTreeView.Object
 With objTreeView
 .Nodes.Add , , "A001", _
"Ein verwaister Knoten ..." .Nodes.Add , , "A002", _
"... bleibt nie lang allein." End With End Sub

Andere Routinen, wie etwa die durch die Schaltfläche cmdKontentextAusgeben, greifen dann über die Objektvariable auf das Objekt zu:

Private Sub cmdKnotentextAusgeben_Click()
 MsgBox objTreeView.SelectedItem.FullPath
End Sub

Wo also liegt nun das Problem Dieses taucht genau dann auf, wenn ein unbehandelter Fehler im Formular auftaucht und der Benutzer die anschließende Fehlermeldung (siehe Bild 2) mit einem Klick auf Beenden quittiert: Access verliert dann nämlich alle in Objektvariablen gespeicherten Verweise und reagiert beim Aufruf der nächsten Routine, die mit der Objektvariablen objTreeView auf das TreeView-Steuerelement zugreifen möchte, mit einem weiteren Fehler. Die Stabilität der Anwendung ist somit endgültig dahin, ein vernünftiges Arbeiten mit dem fehlerhaften Formular ist erst nach dem Schließen und erneuten öffnen wieder möglich. Dies können Sie mit folgender Vorgehensweise verhindern (davon abgesehen, dass Sie natürlich alle Fehler per VBA abfangen sollten – aber manchmal finden die Benutzer eben doch noch eine Lücke …).

pic002.tif

Bild 2: Auf die Meldung unbehandelter Fehler reagieren Benutzer üblicherweise mit einem Klick auf die Schaltfläche Beenden.

Property mit Verweis-Check

Der Clou dieser Lösung liegt darin, dass man im kompletten Modul nicht auf die Objektvariable selbst zugreift, sondern auf eine Property-Prozedur, die entweder einen neuen Verweis auf das Objekt erstellt und diesen oder einen bestehenden Verweis zurückgibt. Dazu benötigen Sie neben der eigentlichen Objektvariable, die hier mTreeView heißt, die passende Property Get-Prozedur:

Dim mTreeView As MSComctlLib.TreeView
Private Property Get objTreeViewB() 
As MSComctlLib.TreeView If mTreeView Is Nothing Then Set mTreeView = Me.ctlTreeView.Object End If Set objTreeViewB = mTreeView End Property

Damit sparen Sie sich erstens das Füllen der Objektvariablen mit dem Verweis auf das Steuerelement beim öffnen des Formulars und stellen die Funktion des Objektverweises für das komplette Modul sicher. Um das TreeView-Steuerelement im Ereignis Beim Laden zu füllen, greifen Sie direkt auf die Property objTreeViewB zu.
Diese liefert dann mit Sicherheit einen Verweis auf das passende Steuerelement zurück. Dazu prüft die Property-Prozedur zunächst, ob mTreeView, also die eigentliche Objektvariable, einen Verweis enthält, und erstellt diesen gegebenenfalls neu.

Ende des frei verfügbaren Teil. Wenn Du mehr lesen möchtest, hole Dir ...

den kompletten Artikel im PDF-Format mit Beispieldatenbank

diesen und alle anderen Artikel mit dem Jahresabo

Schreibe einen Kommentar