Möchtest Du den gesamten Artikel lesen? Und vielleicht sogar den Artikel im PDF-Format und die Beispieldateien herunterladen? Dann hole Dir den Artikel gleich hier - völlig kostenlos!
Bild 1: Standardmäßig aktivierte Verweise
Wenn wir Objektvariablen deklarieren und instanzieren wollen, gibt es zwei Varianten: Early Binding und Late Binding. Beide haben ihre Daseinsberechtigung. Bei der ersten können wir IntelliSense nutzen, benötigen allerdings einen Verweis auf die jeweilige Bibliothek. Durch das Vorhandensein des Verweises ist die Performance außerdem ein wenig besser. Beim Late Binding deklarieren wir die Variable mit dem Typ Object und weisen diese anders zu. Hier benötigen wir keinen Verweis, was wiederum Vorteile mit sich bringt. Ferner können wir kein IntelliSense nutzen. In diesem Artikel zeigen wir zuerst die Unterschiede und die Vor- und Nachteile von Early Binding und Late Binding. Zudem stellen wir eine Möglichkeit vor, beide Varianten gleichzeitig zu definieren und zur Laufzeit zwischen den Methoden zu wechseln.
In den meisten Fällen kommt man beim Programmieren mit den Elementen der standardmäßig verfügbaren Bibliotheken aus. Welche das sind, sehen wir im Verweise-Dialog des VBA-Projekts einer frisch angelegten Access-Datenbank (siehe Bild 1).
Bild 1: Standardmäßig aktivierte Verweise
Wenn wir Elemente aus weiteren Bibliotheken benötigen, fügen wir diese Bibliotheken am einfachsten zunächst über den Verweise-Dialog hinzu. Wenn wir etwa mit ADODB auf Daten zugreifen wollen, benötigen wir die Bibliothek Microsoft ActiveX Data Objects 6.1 Library.
Danach können wir IntelliSense nutzen, um nach Eingabe von ADODB und dem Punkt die enthaltenen Elemente auszuwählen (siehe Bild 2).
Bild 2: Deklaration per IntelliSense
Hierbei handelt es sich um das sogenannte Early Binding.
Wir können auch ohne einen Verweis auf die Bibliothek arbeiten. Dazu entfernen wir zunächst den Verweis. Wenn wir dann mit dem Menüeintrag Debuggen|Kompilieren das Projekt kompilieren, erhalten wir einige fehlerhafte Stellen, da die deklarierten Typen nicht mehr gefunden werden können (siehe Bild 3).
Bild 3: Fehler bei nicht auffindbaren Typen
Diese müssen wir nun zunächst durch den Typ Object ersetzen:
Dim rst As Object Dim cnn As Object
Beim erneuten Kompilieren werden auch die Zeilen zur Initialisierung der Variablen mit New als fehlerhaft markiert.
Diese ersetzen wir durch den Aufruf der CreateObject-Anweisung:
Set rst = CreateObject("ADODB.Recordset") Set cnn = CreateObject("ADODB.Connection")
Damit erhalten wir das sogenannte Late Binding und der Code kann nun ebenfalls kompiliert werden.
Der Nachteil hierbei ist, dass wir kein Intellisense mehr zum Programmieren mit diesen Elementen nutzen können.
Vorteil: Wir können auf nicht vorhandene Bibliotheken reagieren
Der Vorteil tritt erst zutage, wenn wir die Anwendung auf einem Rechner ausführen, auf dem die verwendete Bibliothek nicht vorhanden ist. Wenn wir eine Anwendung mit einem Verweis auf eine nicht vorhandene Bibliothek auf einem solchen Rechner öffnen, erhalten wir eine Meldung wie die aus Bild 4. In der Folge erhalten wir weitere Meldungen, mit denen der Benutzer normalerweise nicht viel anfangen kann – er wird sich dann beim Entwickler melden und damit zusätzlichen Aufwand verursachen.
Bild 4: Meldung bei nicht vorhandener Bibliothek
Wenn wir hier mit Late Binding arbeiten, erscheint erst einmal keine solche Meldung – auch beim Kompilieren/Debuggen wird keine Fehlermeldung auftreten.
Wir können aus einer solchen Datenbank also sogar eine .accde-Datei erstellen.
Und es wird noch besser: Statt der nicht behandelbaren Fehlermeldung, die bei fehlerhaften Verweisen bei Early Binding auftaucht, können wir das Vorhandensein der notwendigen Bibliotheken explizit testen und den Benutzer darauf aufmerksam machen, dass diese gegebenenfalls noch installiert werden müssen.
Angenommen, wir wollen eine selbst erstellte DLL in einem VBA-Projekt nutzen, zum Beispiel eine DLL namens MyTestLibraryProject, die eine Klasse namens MyTestLibrary zur Verfügung stellt.
Die DLL findest Du im Download zu diesem Artikel im Ordner Build unter den folgenden Namen:
- Für 32-Bit: MyTestLibraryProject_win32.dll
- Für 64-Bit: MyTestLibraryProject_win64.dll
Um diese zu registrieren, verwendest Du in der Eingabeaufforderung von Windows (als Administrator gestartet) den folgenden Befehl:
regsvr32.exe "C:\...\Build\MyTestLibraryProject_win32.dll"
In der Eingabeaufforderung sieht das wie in Bild 6 aus.
Bild 5: Registrieren der Beispiel-DLL
Diese binden wir über den Verweise-Dialog wie in Bild 5 in das VBA-Projekt einer Datenbank ein. Danach können wir die einzige Funktion dieser DLL wie folgt nutzen, wobei wir hier zunächst Early Binding nutzen:
Bild 6: Einbinden einer Beispiel-DLL
Public Sub TestLibrary() Dim obj As MyTestLibraryProject.MyTestLibrary Set obj = New MyTestLibraryProject.MyTestLibrary Debug.Print obj.MultiplyByTen(10) End Sub
Der Aufruf der Prozedur liefert das gewünschte Ergebnis, in diesem Fall 100.
Registrierung der DLL aufheben
Nun schauen wir uns den Fall an, dass die DLL nicht wie erwartet registriert ist. Dazu heben wir die Registrierung wieder auf, indem wir RegSvr32.exe mit dem Parameter /u ausführen :
regsvr32.exe "C:\...\Build\MyTestLibraryProject_win32.dll" /u
Wenn wir die Anwendung danach erneut starten, erhalten wir zunächst einmal keinen Fehler. Auch der Verweis ist noch im Verweise-Dialog vorhanden. Kompilieren wir das VBA-Projekt, wird auch kein Fehler gemeldet. Erst, wenn wir die Prozedur ausführen, erhalten wir den Fehler aus Bild 7.
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