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.<\/b><\/p>\n
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<\/b>-Dialog des VBA-Projekts einer frisch angelegten Access-Datenbank (siehe Bild 1).<\/p>\n
![\"Standardmäßig](\"..\/fileadmin\/_temp_\/2025_06\/pic_494_001.png\")
<\/p>\n
Bild 1: Standardmäßig aktivierte Verweise<\/span><\/b><\/p>\n 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<\/b>.<\/p>\n Danach können wir IntelliSense nutzen, um nach Eingabe von ADODB <\/b>und dem Punkt die enthaltenen Elemente auszuwählen (siehe Bild 2).<\/p>\n Bild 2: Deklaration per IntelliSense<\/span><\/b><\/p>\n Hierbei handelt es sich um das sogenannte Early Binding<\/b>.<\/p>\n 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 <\/b>das Projekt kompilieren, erhalten wir einige fehlerhafte Stellen, da die deklarierten Typen nicht mehr gefunden werden können (siehe Bild 3).<\/p>\n Bild 3: Fehler bei nicht auffindbaren Typen<\/span><\/b><\/p>\n Diese müssen wir nun zunächst durch den Typ Object <\/b>ersetzen:<\/p>\n Beim erneuten Kompilieren werden auch die Zeilen zur Initialisierung der Variablen mit New <\/b>als fehlerhaft markiert.<\/p>\n Diese ersetzen wir durch den Aufruf der CreateObject<\/b>-Anweisung:<\/p>\n Damit erhalten wir das sogenannte Late Binding<\/b> und der Code kann nun ebenfalls kompiliert werden.<\/p>\n Der Nachteil hierbei ist, dass wir kein Intellisense mehr zum Programmieren mit diesen Elementen nutzen können.<\/p>\n 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.<\/p>\n Bild 4: Meldung bei nicht vorhandener Bibliothek<\/span><\/b><\/p>\n Wenn wir hier mit Late Binding arbeiten, erscheint erst einmal keine solche Meldung – auch beim Kompilieren\/Debuggen wird keine Fehlermeldung auftreten.<\/p>\n Wir können aus einer solchen Datenbank also sogar eine .accde<\/b>-Datei erstellen. <\/p>\n 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.<\/p>\n Angenommen, wir wollen eine selbst erstellte DLL in einem VBA-Projekt nutzen, zum Beispiel eine DLL namens MyTestLibraryProject<\/b>, die eine Klasse namens MyTestLibrary <\/b>zur Verfügung stellt.<\/p>\n Die DLL findest Du im Download zu diesem Artikel im Ordner Build <\/b>unter den folgenden Namen:<\/p>\n Um diese zu registrieren, verwendest Du in der Eingabeaufforderung von Windows (als Administrator gestartet) den folgenden Befehl:<\/p>\n In der Eingabeaufforderung sieht das wie in Bild 6 aus.<\/p>\n Bild 5: Registrieren der Beispiel-DLL<\/span><\/b><\/p>\n Diese binden wir über den Verweise<\/b>-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:<\/p>\n Bild 6: Einbinden einer Beispiel-DLL<\/span><\/b><\/p>\n Der Aufruf der Prozedur liefert das gewünschte Ergebnis, in diesem Fall 100<\/b>.<\/p>\n 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 <\/b>mit dem Parameter \/u <\/b>ausführen :<\/p>\n Wenn wir die Anwendung danach erneut starten, erhalten wir zunächst einmal keinen Fehler. Auch der Verweis ist noch im Verweise<\/b>-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.<\/p>\n Bild 7: Fehler beim Versuch, die DLL zu nutzen<\/span><\/b><\/p>\n Das liegt daran, dass allein das Aufheben der Registrierung nicht ausreicht – die DLL kann nach wie vor unter dem Pfad gefunden werden, der im Verweise<\/b>-Dialog hinterlegt ist.<\/p>\n Wir schließen die Anwendung also erneut und benennen die DLL um, sodass diese nicht mehr gefunden werden kann. Das ist der Zustand, den wir beispielsweise erhalten, wenn wir die Datenbank auf einen Rechner kopieren, wo die DLL noch gar nicht installiert ist.<\/p>\n Starten wir die Anwendung erneut, erhalten wir schließlich den Fehler aus Bild 8.<\/p>\n Bild 8: Die DLL kann nicht gefunden werden.<\/span><\/b><\/p>\n Beim Versuch, das VBA-Projekt zu kompilieren, erscheint nun auch der erwartete Kompilierfehler (siehe Bild 9).<\/p>\n Bild 9: Kompilierfehler<\/span><\/b><\/p>\n Nun wandeln wir den Code im VBA-Projekt nach Late Binding um:<\/p>\n Damit erreichen wir zunächst, dass das Projekt wieder erfolgreich kompiliert werden kann. Damit beim Schließen und erneuten Öffnen der Datenbank kein Fehler mehr auftritt, müssen wir auch den Verweis noch aus dem Verweise<\/b>-Dialog entfernen. Dieser wird dort bereits als NICHT VORHANDEN <\/b>markiert (siehe Bild 10).<\/p>\n Bild 10: Die Bibliothek wird als NICHT VORHANDEN markiert.<\/span><\/b><\/p>\n Danach können wir die Anwendung schließen und problemlos wieder öffnen.<\/p>\n Erst beim Versuch, die DLL per VBA aufzurufen, liefert das eine Fehlermeldung (siehe Bild 11).<\/p>\n Bild 11: Weiterr Fehler beim Versuch, die DLL zu nutzen<\/span><\/b><\/p>\n Und hier können wir eingreifen und dem Benutzer eine nachvollziehbare Meldung liefern. Dazu fügen wir die Fehlerbehandlung aus Listing 1 hinzu.<\/p>\n Listing 1: Fehlerbehandlung für eine fehlende DLL<\/span><\/b><\/p>\n Hier schalten wir die eingebaute Fehlerbehandlung mit On Error Resume Next <\/b>aus und prüfen nach dem Aufruf, ob die Fehlernummer 429 <\/b>lautet. In diesem Fall geben wir eine entsprechende Fehlermeldung aus und brechen die Prozedur ab.<\/p>\n Nun wollen wir dem Benutzer den Fehler nicht erst präsentieren, wenn er die entsprechende Prozedur aufruft, sondern direkt beim Start der Anwendung eine Prüfung durchführen.<\/p>\n Dazu fügen wir ein AutoExec<\/b>-Makro hinzu, das eine Funktion namens DLLTest <\/b>aufruft (siehe Bild 12).<\/p>\n Bild 12: AutoExec-Makro zum Testen der DLL<\/span><\/b><\/p>\n Diese erhält den folgenden Code:<\/p>\n Damit können wir direkt beim Start der Anwendung eine Fehlermeldung ausgeben, wenn die benötigte DLL nicht verfügbar ist.<\/p>\n Wenn wir dennoch Early Binding und IntelliSense nutzen wollen, können wir schrittweise vorgehen. Dabei würden wir zunächst einen Verweis zur entsprechenden Bibliothek hinzufügen und mit Early Binding <\/b>programmieren. Bevor wir die Anwendung weitergeben, können wir den Verweis wieder entfernen und die entsprechenden Anweisungen auf Late Binding umstellen.<\/p>\n Dabei sollten wir die Early Binding-Anweisungen jedoch nur auskommentieren und nicht entfernen, um jederzeit zu Programmierzwecken und zur Nutzung von IntelliSense auf die Early Binding-Variante zurückwechseln zu können.<\/p>\n Wir können dies sogar mit der sogenannten Bedingten Kompilierung so einstellen, dass je nach Modus entweder Early oder Late Binding genutzt werden kann. Wie das im Detail funktioniert, zeigen wir in einem weiteren Artikel namens VBA: Bedingte Kompilierung nutzen <\/b>(www.vbentwickler.de\/6<\/b>).<\/p>\n Early Binding und Late Binding haben beide Vor- und Nachteile, die wir in diesem Artikel vorgestellt haben.<\/p>\n Da das Umstellen von Early Binding zu Late Binding und zurück je nach der Anzahl der Deklarations- und Initialisierungsanweisungen aufwendig sein kann, stellen wir in einem weiteren Beitrag namens Per VBA von Early Binding zu Late Binding <\/b>(www.vbentwickler.de\/5<\/b>) eine Lösung vor, mit der wir mit wenigen Mausklicks automatisch alle Early Binding-Anweisungen zu Late Binding umstellen können.<\/p>\n Enthaltene Beispieldateien:<\/p>\n VBAEarlyBindingUndLateBinding.accdb<\/p>\n![\"Deklaration](\"..\/fileadmin\/_temp_\/2025_06\/pic_494_002.png\")
<\/p>\n![\"Fehler](\"..\/fileadmin\/_temp_\/2025_06\/pic_494_003.png\")
<\/p>\nDim <\/span>rst As Object<\/span>\r\nDim <\/span>cnn As Object<\/span><\/pre>\nSet<\/span> rst = CreateObject(\"ADODB.Recordset\")\r\nSet<\/span> cnn = CreateObject(\"ADODB.Connection\")<\/pre>\nVorteil: Wir können auf nicht vorhandene Bibliotheken reagieren<\/h2>\n
![\"Meldung](\"..\/fileadmin\/_temp_\/2025_06\/pic_494_004.png\")
<\/p>\n\n
regsvr32.exe \"C:\\...\\Build\\MyTestLibraryProject_win32.dll\"<\/pre>\n
![\"Registrieren](\"..\/fileadmin\/_temp_\/2025_06\/pic_494_006.png\")
<\/p>\n![\"Einbinden](\"..\/fileadmin\/_temp_\/2025_06\/pic_494_005.png\")
<\/p>\nPublic Sub <\/span>TestLibrary()\r\n Dim <\/span>obj As <\/span>MyTestLibraryProject.MyTestLibrary\r\n Set<\/span> obj = New<\/span> MyTestLibraryProject.MyTestLibrary\r\n Debug.Print<\/span> obj.MultiplyByTen(10)\r\nEnd Sub<\/span><\/pre>\nRegistrierung der DLL aufheben<\/h2>\n
regsvr32.exe \"C:\\...\\Build\\MyTestLibraryProject_win32.dll\" \/u<\/pre>\n
![\"Fehler](\"..\/fileadmin\/_temp_\/2025_06\/pic_494_007.png\")
<\/p>\n![\"Die](\"..\/fileadmin\/_temp_\/2025_06\/pic_494_008.png\")
<\/p>\n![\"Kompilierfehler\"](\"..\/fileadmin\/_temp_\/2025_06\/pic_494_009.png\")
<\/p>\nUmwandeln in Late Binding<\/h2>\n
Dim <\/span>obj As Object<\/span>\r\nSet<\/span> obj = _\r\n CreateObject(\"MyTestLibraryProject.MyTestLibrary\")<\/pre>\n![\"Die](\"..\/fileadmin\/_temp_\/2025_06\/pic_494_010.png\")
<\/p>\n![\"Weiterr](\"..\/fileadmin\/_temp_\/2025_06\/pic_494_011.png\")
<\/p>\nPublic Sub <\/span>TestLibrary()\r\n Dim <\/span>obj As Object<\/span>\r\n On Error Resume Next<\/span>\r\n Set<\/span> obj = CreateObject(\"MyTestLibraryProject.MyTestLibrary\")\r\n If <\/span>Err.Number = 429 Then<\/span>\r\n MsgBox<\/span> \"Die Bibliothek MyTestLibraryProject ist nicht installiert.\", vbOKOnly + vbCr<\/span>itical, \"Fehlende DLL\"\r\n Exit Sub<\/span>\r\n End If<\/span>\r\nEnd Sub<\/span><\/pre>\nDLL direkt beim Start prüfen<\/h2>\n
![\"AutoExec-Makro](\"..\/fileadmin\/_temp_\/2025_06\/pic_494_012.png\")
<\/p>\nPublic Function <\/span>DLLTest()\r\n Dim <\/span>obj As Object<\/span>\r\n On Error Resume Next<\/span>\r\n Set<\/span> obj = CreateObject( _\r\n \"MyTestLibraryProject.MyTestLibrary\")\r\n If <\/span>Err.Number = 429 Then<\/span>\r\n MsgBox<\/span> \"Die Bibliothek MyTestLibraryProject \" _\r\n & \"ist nicht installiert.\", _\r\n vbOKOnly + vbCr<\/span>itical, \"Fehlende DLL\"\r\n DoCmd.Quit\r\n End If<\/span>\r\nEnd Function<\/span><\/pre>\nVorgehensweise bei der Programmierung<\/h2>\n
Zusammenfassung und Ausblick<\/h2>\n
Downloads zu diesem Beitrag<\/h2>\n