COM-Add-Ins mit twinBASIC

Lies in den Artikel rein und unten bekommst Du ein unschlagbares Angebot!

COM-Add-Ins sind Erweiterungen für Office-Anwendungen und ihre Entwicklungsumgebung, den VBA-Editor. Damit lassen sich Erweiterungen programmieren, die über die Benutzeroberfläche der jeweiligen Anwendung verfügbar gemacht werden und ihre Aufgabe mit oder ohne ein eigenes User Interface bereitstellen. COM-Add-Ins kann man jedoch nicht mit den Mitteln der Office-Anwendungen selbst programmieren. Dazu sind weitere Tools notwendig. Früher ging dies am einfachsten mit Visual Studio 6. Dieses ist jedoch spätestens seit der Einführung der 64-Bit-Versionen der Office-Anwendungen nicht mehr nutzbar, sodass Alternativen gefragt sind. Neben Visual Studio .NET, das ebenfalls das Erstellen von COM-Add-Ins erlaubt, erschien vor kurzer Zeit eine neue Alternative: twinBASIC. Ein Projekt von Wayne Phillips, das sich nicht nur anschickt, Nachfolger von Visual Studio 6 zu werden, sondern schon jetzt das Erstellen unter anderem von COM-Add-Ins ermöglicht. Dieser Artikel stellt die grundlegenden Techniken zum Erstellen eines Gerüsts für COM-Add-Ins vor, das wir in weiteren Artikeln mit praktischen Lösungen für die Erweiterung der Office-Anwendungen und auch des VBA-Editors nutzen werden.

Vorbereitungen

Wie wir twinBASIC herunterladen und betriebsbereit machen, beschreiben wir im Artikel twinBASIC: Visual Basic für die Zukunft (www.vbentwickler.de/310).

Nach dem Start von twinBASIC finden wir auf der zweiten Seite des Startdialogs namens Samples einige Beispielprojekte vor.

Erstellen eines COM-Add-In-Projekts

Wir starten mit einer der praktischen Vorlagen für die Erstellung verschiedener Beispielprojekte, in diesem Fall Sample 5. MyCOMAddIn (siehe Bild 1).

Bild 1: Erstellen eines COM-Add-Ins auf Basis des passenden Beispiels

Ein Klick auf diese Schaltfläche erstellt ein neues Projekt, das zu diesem Zeitpunkt jedoch noch nicht gespeichert ist. Um dieses zu speichern, betätigen wir den Menübefehl File|Save Project. Dies öffnet, da das Projekt noch ungespeichert ist, einen Save Project As…-Dialog. Mit diesem navigieren wir zu dem gewünschten Zielordner und geben den Dateinamen für das Projekt ein, der die Dateiendung .twinproj trägt (siehe Bild 2).

Bild 2: Festlegen des Speicherorts für die .twinproj-Datei

Schauen wir dann in das Verzeichnis, in dem wir das neue Projekt angelegt haben, stellen wir fest, dass hier tatsächlich nur eine Datei vorliegt – es gibt aktuell noch keine weiteren Elemente.

Damit kehren wir zurück zur twinBASIC-Entwicklungsumgebung, die das neu erstellte Projekt anzeigt.

Module des Beispielprojekts

Das Projekt enthält zu diesem Zeitpunkt zwei Module:

• Das erste heißt MyCOMAddin.twin und wird direkt beim Start im zentralen Bereich der Entwicklungsumgebung angezeigt. Es enthält im Falle eines COM-Add-Ins den gesamten Code des Projekts. Wir schauen uns diesen weiter unten an.
• Das zweite ist das Modul DllRegistration.twin. Dieses enthält Informationen, die erstens beim Erstellen des Projekts zum Testen in die Registry geschrieben werden und die auch beim manuellen Registrieren mit RegSvr32.exe verwendet werden. Auch den Inhalt dieses Moduls schauen wir uns gleich im Detail an.

Für welche Anwendung soll das COM-Add-In eingesetzt werden?

Die wichtigste Frage, die wir beantworten müssen, bevor wir das Add-In überhaupt testweise erstellen, ist die nach der Anwendung, in der das Add-In seine Funktionen zur Verfügung stellen soll.

Aktuell gehen wir davon aus, dass es sich dabei um eine der folgenden Office-Anwendungen handelt:

• Access
• Excel
• Outlook
• PowerPoint
• Word

Oder wollen wir das COM-Add-In sogar für mehrere Office-Anwendungen gleichzeitig verfügbar machen? Das ist möglich, aber es stellt sich die Frage, ob es Anwendungsfälle gibt, die in allen Office-Anwendungen nützlich sind. Tatsächlich gehen wir davon aus, dass ein COM-Add-In eher auf eine Office-Anwendung spezialisiert ist. Dennoch zeigen wir, wie wir das COM-Add-In für mehrere Office-Anwendungen gleichzeitig bereitstellen können.

Soll das COM-Add-In für eine 32-Bit- oder für eine 64-Bit-Anwendung kompiliert werden?

Die zweite Frage, die sich stellt, ist die nach der Architektur der Office-Installation: Ist diese für 32-Bit- oder für 64-Bit ausgelegt? Wir befinden uns in einem Wandel, denn bis vor kurzer Zeit hat das Office-Setup standardmäßig die 32-Bit-Version von Office installiert. Mit Office 2016 und den entsprechenden Versionen unter Office 365 hat sich dies jedoch geändert. Hier landet nun standardmäßig die 64-Bit-Version auf dem Rechner.

Das Problem ist nun, dass auch COM-Add-Ins für die entsprechende Version, also 32-Bit oder 64-Bit, kompiliert werden müssen. Unter twinBASIC ist das ein kleines Problem, wenn auch mit gewissen Einschränkungen. Wir können zwar die entsprechende Zielversion (win32 oder win64) vor der Kompilierung auswählen. Allerdings ist twinBASIC nur für die 32-Bit-Version kostenlos. Wenn wir die 64-Bit-Version kompilieren, wird sowohl während der Kompilierung als auch bei Start des COM-Add-Ins jeweils ein Dialog des Herstellers mit dem twinBASIC-Logo eingeblendet.

Für Entwicklungszwecke und zum Ausprobieren ist das kein Problem. Wir gehen jedoch davon aus, dass wir, wenn wir mit twinBASIC erstellte Anwendungen beim Kunden einsetzen wollen, auch die anfallenden (überschaubaren) Lizenzgebühren gerne entrichten.

Schnellstart mit dem Beispiel-COM-Add-In

Wir wollen direkt einmal das vorgefertigte Beispiel ausprobieren und klicken nach der Auswahl der Zielversion (32-Bit oder 64-Bit) direkt auf die Schaltfläche Build in der Menüleiste (siehe Bild 3).

Bild 3: Erstellen des COM-Add-Ins

Danach können wir das COM-Add-In in Excel und auch in Access ausprobieren. Wenn wir Excel öffnen, finden wir die Möglichkeit zum Aufrufen der Funktion des COM-Add-Ins im Ribbon unter twinBASIC Test. Ein Klick auf die in diesem Tab enthaltene Schaltfläche zeigt ein Meldungsfenster an (siehe Bild 4).

Bild 4: Aufruf des COM-Add-Ins von Excel aus

Das gleiche Ergebnis erhalten wir mit diesem COM-Add-In auch, wenn wir Access öffnen.

Anpassung der Zielanwendung

Der erste Schritt der Anpassung des COM-Add-Ins soll sich auf die Anwendung beziehen, in welcher dieses angezeigt wird. Diese Einstellung nehmen wir im Modul DllRegistration vor.

Hier finden wir den Code aus Listing 1. Wir sehen ganz oben, dass unter twinBASIC Standardmodule in Module [Modulname] und End Module eingefasst werden müssen. Wir sehen außerdem einige Konstanten, welche Informationen enthalten, die in den beiden weiter unten definierten Funktionen zum Einsatz kommen. Die erste speichert den Namen des Projekts, der aus VBA.Compilation.CurrentProjectName bezogen wird. Die Klasse Compilation ist eine twinBASIC-Erweiterung, die Informationen über das aktuelle Projekt liefert und deren Member wir beispielsweise wie in Bild 5 per IntelliSense abfragen können. In diesem Fall ermitteln wir den aktuellen Projektnamen. Wie wir den Projektnamen anpassen, zeigen wir weiter unten.

Bild 5: Die Compilation-Klasse per IntelliSense

Die zweite Konstante namens AddinClassName erhält den Namen der Klasse des Add-Ins. Dieser sollte mit dem Namen der Klasse im anderen Modul des Projekts übereinstimmen, in diesem Fall MyCOMAddin. Die nächste Konstante AddinQualifiedClassName fügt die beiden vorher definierten Konstanten, also AddinProjectName und AddinClassName zusammen.

Schließlich folgen noch zwei Konstanten namens RootRegistryFolder_ACCESS und RootRegistryFolder_EXCEL, welche die Pfade zu den zu erstellenden Einträgen für das COM-Add-In in der Registry aufnehmen. Für Access entsteht so beispielsweise der folgende Wert für diese Konstante:

HKCU\SOFTWARE\Microsoft\Office\Access\Addins\MyCOMAddin.MyCOMAddin\

Wozu Registry-Einträge?

Warum machen wir in Zusammenhang mit der Installation eines COM-Add-Ins überhaupt so einen Wirbel um Registry-Einträge? Der Grund ist einfach: Die Office-Anwendungen scannen beim Starten einen bestimmten Bereich der Registry, wo die für die jeweilige Anwendung registrierten COM-Add-Ins aufgelistet werden. Die dort angegebenen DLLs werden beim Start der Anwendung ausgelesen und dort untergebrachte Schnittstellen für die Anpassung von Ribbondefinitionen angewendet.

Um zu prüfen, ob das soeben erstellte COM-Add-In seinen Platz in der Registry gefunden hat, brauchen wir eigentlich nicht die Registry zu öffnen, denn wir haben uns ja durch Starten der Anwendungen Access und Excel davon überzeugt, dass das COM-Add-In für die beiden Anwendungen installiert ist.

Dennoch schauen wir uns die Registry an, wobei wir diese mit dem Befehl RegEdit über das Suchen-Feld von Windows öffnen.

Hier navigieren wir zum folgenden Eintrag: