VBA-Optionen, die jeder Entwickler kennen muss

Nicht nur Access, sondern auch der VBA-Editor bietet eine Reihe von Optionen an. Diese erlauben, das Aussehen und die Funktionalität des VBA-Editors anzupassen. Es gibt zwar nicht die Fülle von Optionen, die Sie vielleicht von modernen Entwicklungsumgebungen kennen, aber manchmal ist weniger auch mehr. In diesem Beitrag stellen wir die wichtigsten Optionen für den VBA-Editor vor – damit verhindern Sie beispielsweise dauerhaft das Verwenden von nicht deklarierten Variablen, nutzen verschiedene Einstellungen für die Fehlerbehandlung oder deaktivieren nervige Meldungen bei Syntaxfehlern.

Variablendeklaration per Option erzwingen

Die Optionen des Access-Hauptfensters sind hinlänglich bekannt. Weniger oft nutzt man hingegen die Optionen des VBA-Editors – zumindest, wenn man danach geht, wie oft wir bei unseren Kunden Anwendungen sehen, in denen die Anweisung Option Explicit fehlt.

Diese Anweisung finden wir üblicherweise oben im VBA-Modul, gleich hinter der Anweisung Option Compare Database:

Option Compare Database
Option Explicit

Allerdings finden wir sehr oft nur die erste Anweisung vor. Dabei ist Option Explicit sehr wichtig: Damit stellen wir sicher, dass bei der Verwendung nicht deklarierter Variablen im VBA-Code ein Kompilierfehler ausgelöst wird.

Nicht deklarierte Variablen können problematisch werden, weil so beispielsweise durch Tippfehler verursachte unterschiedliche Schreibweisen für die gleiche Variable ein unerwartetes Verhalten hervorrufen.

Warum aber finden wir die Anweisung Option Explicit in dem einen VBA-Projekt vor, in anderen fehlt es jedoch teilweise völlig?

Das hängt vermutlich mit einer Option des VBA-Editors zusammen, die standardmäßig deaktiviert ist, nämlich Variablendeklaration erforderlich. Diese finden wir gleich auf der ersten Seite des Optionen-Dialogs (siehe Bild 1).

Bild 1: Erste Seite der Optionen im VBA-Editor

Sobald wir diese Option aktivieren, wird Option Explicit bei jedem neu angelegten Modul automatisch hinzugefügt.

Leider sorgt dies nicht automatisch dafür, dass die Anweisung Option Explicit nachgerüstet wird, wo es noch fehlt. Eine Lösung, wie Sie schnell Module ohne Option Explicit finden können, zeigen wir im Beitrag Fehlendes Option Explicit finden und nachrüsten (www.access-im-unternehmen.de/1619).

Wer diese Option jedoch direkt aktiviert, braucht sich später nicht um fehlende Option Explicit-Anweisungen zu kümmern.

Automatische Syntaxüberprüfung deaktivieren

Der erste Eintrag auf der ersten Seite des Optionen-Dialogs heißt Automatische Syntaxüberprüfung.

Dieser ist standardmäßig aktiviert und sorgt so dafür, dass bei Eingabe von Codezeilen, die einen Syntaxfehler enthalten, direkt eine Fehlermeldung angezeigt wird.

Bild 2 zeigt ein Beispiel. Hier haben wir einen Rückgabeparameter definiert, obwohl wir keine Function-, sondern eine Sub-Prozedur definiert haben.

Bild 2: Anzeige einer Meldung für einen Syntaxfehler

Die zusätzlich zur roten Markierung des Textes erscheinende Fehlermeldung ist zumindest für Einsteiger hilfreich, außerdem wird auch noch das Schlüsselwort mit blauem Hintergrund markiert, das für den Fehler verantwortlich ist.

Versiertere Entwickler können auf solche Fehlermeldungen und Markierungen verzichten, für sie reicht es aus, dass die fehlerhafte Zeile in roter Schrift erscheint.

Zumindest jedoch bei manchen Operationen stört diese Fehlermeldung – zum Beispiel, wenn wir Anweisungen aus einer anderen Programmiersprache in das Modul einfügen, um dieses Schritt für Schritt in VBA zu übersetzen. Hier erhalten wir dann ständig neue Fehlermeldungen. Wenn wir diese nicht mehr erhalten wollen, können wir einfach die Option Automatische Syntaxüberprüfung ausschalten.

Benutzerdefinierte Fehlerbehandlung umgehen

Laufzeitfehler sollten an einer geeigneten Stelle behandelt werden, damit der Benutzer keine eingebauten Fehlermeldungen von VBA sieht. Bei größeren Prozeduren und an den Einstiegspunkten einer Anwendung empfiehlt sich in der Regel eine eigene Fehlerbehandlung. Kleinere Hilfsprozeduren können Fehler dagegen an die aufrufende Prozedur weiterreichen.

Gegebenenfalls stattet man auch längere Prozeduren mit Fehlerbehandlungen aus, ohne Zeilennummern anzulegen und diese in einer Fehlermeldung mit der Funktion Erl auszugeben. Wir erhalten dann also eine Fehlermeldung, die eventuell sogar einen Hinweis auf die fehlerhafte Prozedur und das Modul enthält, in dem sich diese Prozedur befindet. Aber wir wissen nicht, in welcher Zeile der Fehler ausgelöst wird.

Noch schwieriger wird es, wenn wir Fehler mit Absicht übergehen – beispielsweise, weil wir in einer verschachtelten Struktur ein XML-Dokument untersuchen, aber von verschiedenen Elementen wissen, dass sie nicht immer vorhanden sind. Dann könnte man einfach auf die entsprechenden Elemente zugreifen und zuvor die Meldung von Fehlern mit On Error Resume Next deaktivieren. So führt das Nichtvorhandensein nicht zu einer Unterbrechung. Die betreffende Zuweisung wird jedoch nicht ausgeführt. Dabei ist zu beachten, dass die Zielvariable gegebenenfalls ihren bisherigen Wert behält.

Tritt dann allerdings doch ein unerwarteter Fehler auf, der das Verhalten des Codes verfälscht, müssen wir herausfinden, welche Zeile den Fehler auslöst. Und dann wird es schwierig, gerade wenn wir – um bei diesem Beispiel zu bleiben – ein sehr umfangreiches XML-Dokument einlesen. Das Debuggen von Hand wird dann sehr aufwendig.

Einfacher ist es dann, eine Option zu aktivieren, mit der Laufzeitfehler gemeldet werden, obwohl zuvor On Error Resume Next oder On Error GoTo … aktiviert wurde.

Dann hält VBA trotz On Error Resume Next an der fehlerauslösenden Anweisung an, ohne dass wir die Fehlerbehandlung zuvor auskommentieren müssen (siehe Bild 3).