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.

Sie haben das Ende des frei verfügbaren Textes erreicht. Möchten Sie ...

TestzugangOder bist Du bereits Abonnent? Dann logge Dich gleich hier ein. Die Zugangsdaten findest Du entweder in der aktuellen Print-Ausgabe auf Seite U2 oder beim Online-Abo in der E-Mail, die Du als Abonnent regelmäßig erhältst:

Schreibe einen Kommentar