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
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 …).
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.
Nur für Abonnenten
Ab hier wird’s wirklich spannend – der Rest ist exklusiv für Abonnenten.
Mit dem Abo von Access im Unternehmen bekommst du den kompletten Artikel – inklusive vollständigem Code, Beispieldatenbank und Schritt-für-Schritt-Erklärung.
So sparst du dir stundenlanges Herumprobieren, vermeidest teure Fehler in deiner Access-Anwendung und kannst Lösungen direkt in deinem Unternehmen einsetzen, statt nur darüber zu lesen.
Teste Access im Unternehmen jetzt 4 Wochen lang kostenlos: Voller Zugriff auf alle Artikel, Downloads und Beispieldatenbanken. Kein Risiko – wenn es für dich nicht passt, kündigst du einfach innerhalb der ersten vier Wochen.
Bereits Abonnent? Hier einloggen
Kostenlos & unverbindlich
Oder hast Du eine konkrete Frage zu Deiner eigenen Access-Anwendung?
Vielleicht stellt Deine Anwendung Dich vor eine Herausforderung, zu der Du bisher keine Lösung findest. Schlechte Performance, kein ausreichender Zugriffsschutz, Du bist unsicher über Dein Datenmodell oder Dein Code liefert unerklärliche Fehler?
In unserem kostenlosen Access-Audit schaut sich André Minhorst persönlich gemeinsam mit Dir Deine Lösung per Zoom an – und zeigt Dir, wo Datenmodell, VBA-Code, Ergonomie und Sicherheit Optimierungspotenzial bieten.
Jetzt kostenloses Access-Audit anfordern →