André Minhorst, Duisburg und Sascha Trowitzsch, Berlin
Je ernsthafter man mit Access arbeitet, desto mehr verlagert sich der Schwerpunkt der Arbeit vom Access-Fenster auf die VBA-Entwicklungsumgebung. Und wie es mit einem Arbeitsplatz so ist, sollte man ihn sich so angenehm wie möglich gestalten – das gilt auch für die Programme, mit denen man arbeitet. Und das umso mehr, wenn sich tatsächlich die Möglichkeit dazu ergibt. Die VBA-Entwicklungsumgebung lässt sich beliebig erweitern, wenn man das Know-how dazu besitzt. Das finden Sie hier und ein praktisches Beispiel gleich dazu: Ab jetzt können Sie durch den Code springen, wie Sie möchten – mit dem CodeHistory-Tool finden Sie schnell wieder zurück.
Hinweis
Die Beispieldateien befinden sich in der .zip-Datei AIU_CodeHistory.zip. Zwei Verzeichnisse enthalten je eine Version des Quellcodes mit und eine ohne Kommentare. Sie finden die Datei auf der Heft-CD oder im Internet unter http://www.access-im-unternehmen.de unter dem Shortlink 278. Grundlagen und verwandte Themen finden Sie in den Beiträgen Per VBA auf VBA-Code zugreifen, Shortlink 277 und Erweitern der VBA-Entwicklungsumgebung, Shortlink 237.
Die VBA-Entwicklungsumgebung lässt sich um verschiedene Elemente erweitern. Bei diesen Elementen handelt es sich um COM-AddIns, die nach ihrer Installation beim Start der Entwicklungsumgebung automatisch erkannt und den Voreinstellungen entsprechend entweder direkt geladen werden oder erst über den Add-In-Manager aktiviert werden müssen.
Erweiterungsmöglichkeiten
Für die VBA-Entwicklungsumgebung gibt es mehrere Möglichkeiten, eine Erweiterung zu integrieren. Interessant sind dabei die Varianten zum Starten beziehungsweise Anzeigen des Add-Ins und wie es sich in die Entwicklungsumgebung einfügt. Die einfachste Variante ist ein Add-In, das nach dem Laden im Add-Ins-Menü zur Verfügung steht und eine Operation ausführt, für die keine Benutzeroberfläche benötigt wird – beispielsweise das automatische Hinzufügen von Code anstelle der Einfügemarke.
Darüber hinaus gibt es sowohl für den Aufruf als auch für den Grad der Interaktion mit dem Benutzer einige Varianten. Für den Aufruf eines Add-Ins bietet sich neben dem Add-Ins-Menü ein Eintrag in ein anderes bestehendes Menü (dabei kann es sich auch um ein Kontextmenü handeln) oder gar die Erstellung einer eigenen Menüleiste an.
Was die Interaktion mit dem Benutzer betrifft, so gibt es neben den Add-Ins, die ihren Dienst ohne Rückfragen erledigen, solche, die zusätzliche Benutzereingaben für ihre Arbeit benötigen. Dabei kann die Art der Interaktion von Meldungsfenster und Eingabefenster bis hin zu mehreren Benutzerformularen reichen.
Immer präsent (wenn nicht gerade ausgeblendet) sind die „Toolwindows“. Sie kennen bereits einige Beispiele für diese in der Entwicklungsumgebung verankerbaren Fenster: Das Direktfenster ist eines und auch der Projekt-Explorer, das überwachungsfenster und das Eigenschaftsfenster sind Toolwindows.
Diese Fenster haben gemeinsam, dass sie sowohl frei schweben als auch an den Rahmen des Editorfensters oder andere Toolwindows angedockt werden können. Der wichtigste Unterschied zu den Benutzerformularen ist die ständige Sichtbarkeit dieser Fenster.
Bild 1: Festlegen des Ladeverhaltens von COM-Add-Ins
Bild 2: Aktivieren des CodeHistory-Tools
Toolwindows
Toolwindows sind das Thema dieses Beitrags: Sie erfahren, wie Sie diese erstellen, installieren und aktivieren oder deaktivieren. Leider lassen sich Toolwindows nicht mit Access erstellen; Sie benötigen dazu Microsoft Visual Basic 6 (Visual Studio 6). Sollten Sie nicht in Besitz dieses Tools sein, können Sie immerhin das hier vorgestellte Tool für die Entwicklung mit der VBA-Entwicklungsoberfläche verwenden.
Der Entwicklungsprozess eines Toolwindows lässt sich grob in die Erstellung des Gerüsts mit den grundlegenden Elementen, das unter anderem die Funktionalität zum Einklinken in die Benutzeroberfläche sowie ein jungfräuliches Toolwindow enthält und das Aufsetzen der eigentlichen Funktionalität aufteilen.
Den ersten Teil haben wir bereits für Sie erledigt: Auf der Heft-CD finden Sie ein VB-Projekt mit dem Quellcode für das Gerüst eines Toolwindows. Der erste Teil dieses Beitrags enthält eine Beschreibung der enthaltenen Komponenten. Auch für die Schritte vom leeren Gerüst zum fertigen Toolwindow ist gesorgt: Sie finden sowohl das komplette Projekt im Quellcode als auch die fertige .dll für den Soforteinsatz auf der Heft-CD. Leider, und das ist die schlechte Nachricht, würde eine ausführliche Vorstellung des Tools mit dem enthaltenen Quellcode circa ein bis zwei komplette Magazine verschlingen, sodass wir den Quellcode nur auszugweise im Beitrag vorstellen können. Der in den Beispieldateien enthaltene Quellcode ist allerdings sehr gut dokumentiert.
In den nachfolgenden Abschnitten erfahren Sie, wie Sie COM-Add-Ins verfügbar machen und wie das Beispiel-Add-In funktioniert.
Add-Ins verfügbar machen
Den Add-In-Manager können Sie in der VBA-Entwicklungsumgebung über den Menüeintrag Add-Ins/Add-In-Manager… starten.
Der Add-In-Manager aus Bild 1 zeigt bereits das weiter unten in diesem Beitrag vorgestellte VBA-CodeHistory-Tool an. Um das Tool zu aktivieren, das heißt, es in der VBA-Entwicklungsumgebung sichtbar zu machen, sind zwei Schritte nötig: Aktivieren Sie die Option Geladen/Entladen und wählen Sie nach dem Schließen des Dialogs den neuen Eintrag im Add-Ins-Menü aus (siehe Bild 2).
Bild 3: Anzeigen der Definition einer Prozedur
Bild 4: Liste bereits besuchter Codestellen
Funktionen des CodeHistory-Tools
Möglicherweise kennen Sie selbst das Dilemma: Sie durchforsten die Prozeduren und Module einer VBA-Anwendung, um zu verstehen, wie diese funktioniert. Egal ob es sich um eine eigene Entwicklung oder um das Produkt eines anderen Entwicklers handelt – wenn Sie länger nicht mehr oder noch gar nicht hineingeschaut haben, müssen Sie sich zuerst in die Struktur einarbeiten. Sie starten also mit einer Prozedur, die durch eine bestimmte Schaltfläche aufgerufen wird und untersuchen dessen Funktion. Dabei finden Sie mehrere weitere Prozeduraufrufe – also schnell hinterher und die entsprechenden Module in weiteren Codefenstern aufrufen. Die Entwicklungsumgebung stellt geeignete Mittel dafür zur Verfügung – etwa den Kontextmenüeintrag Definition beim Rechtsklick auf den Aufruf der gewünschten Prozedur (siehe Bild 3).
Das ganze Spiel machen Sie noch zwei oder drei Mal, dann möchten Sie vielleicht zur Ausgangprozedur zurückkehren – aber in welchem Modul war die noch Mal Hier kommt das CodeHistory-Tool ins Spiel. Es speichert Positionen im Code so, dass Sie mühelos per Mausklick auf einen Eintrag zur entsprechenden Stelle zurückkehren können.
Aufzeichnen von Positionen
Das CodeHistory-Tool zeichnet Informationen über Code-Zeilen auf, die Sie mit der Maus „besucht“ haben und gibt diese in einer Liste aus (siehe Bild 4). Mit einem Mausklick auf einen der Einträge öffnen Sie das Modul mit der entsprechenden Codestelle und zeigen diese an.
Das Toolwindow mit der Liste der gemerkten Positionen im Code zeigt den Namen des Projekts, den Modulnamen, die Zeile und den Prozedurnamen an. Zusätzlich finden Sie ganz links ein Sternchen (*) – auf diese Weise markierte Einträge werden dauerhaft gespeichert und bei der nächsten Sitzung wieder geladen.
Die Schaltflächen im oberen Bereich haben folgende Funktionen:
Wann wird eine Position gespeichert
Wenn jede Zeile, in die Sie die Einfügemarke setzen, zur Liste hinzugefügt würde, wäre diese bald voll. Der Sinn dieses Tools ist vielmehr, markante Sprünge zu speichern und das Zurückspringen an diese Stellen zu ermöglichen. Das Speichern einer Position erfolgt in folgenden Fällen, wobei Sie die ersten beiden Optionen im entsprechenden Dialog deaktivieren können:
Bild 5: Kontextmenüeinträge des CodeHistory-Tools
Navigieren zwischen den Positionen
Nachdem Sie einige Positionen aufgezeichnet haben, möchten Sie gezielt zu der einen oder anderen zurückspringen – vielleicht möchten Sie aber auch einfach den zurückgelegten Weg nachvollziehen. Das Tool bietet einige Möglichkeiten zum Navigieren an:
Bild 6: Diese Schnellauswahl zeigen Sie per Kontextmenü an.
Optionen des Tools
Mit der Schaltfläche Einstellungen des Toolwindows können Sie einen Dialog zum ändern der Einstellungen öffnen (siehe Bild 7).
Die erste Option legt fest, wie viele Zeilen eine Zeile von der zuvor gespeicherten Position entfernt sein muss, damit das Tool diese automatisch speichert. Die standardmäßig eingestellten 40 Zeilen entsprechen ungefähr einer Bildschirmseite, somit wird eine Zeile, die mehr als eine Bildschirmseite als die vorherige entfernt liegt, automatisch gespeichert. Der kleinste einstellbare Wert, den dieses Optionsfeld annimmt, ist 3.
Mit der zweiten Option legen Sie fest, wie viele Positionen sich das Tool merken soll. Ist die angegebene Anzahl erreicht, schmeißt das Tool die ältesten Einträge aus der Liste. Mit der Option Sprungstellen automatisch merken geben Sie an, ob das Tool sich Positionen automatisch entsprechend Ihrer Angabe in für die Option Anzahl Codezeilen merken oder dies nur nach Aufforderung über den entsprechenden Kontextmenübefehl oder die dafür vorgesehene Tastenkombination tun soll.
Mit der Option Sprungstellen dauerhaft merken legen Sie fest, dass die automatisch vermerkten Stellen über die aktuelle Sitzung hinaus gespeichert werden sollen, so dass sie beim nächsten Laden des VBA-Projekts wieder verfügbar sind. Diese Codestellen sind dann in der Liste mit einem Sternchen versehen. Dieses dauerhafte Speichern lässt sich auch ausschalten, indem der Haken bei der Option Sprungstellen beim Beenden speichern deaktiviert wird.
Praxis-Tipp
Das CodeHistory-Tool speichert die Einträge zu jeder Datenbank in einer eigenen Textdatei im gleichen Verzeichnis, in dem sich auch die .dll-Datei befindet. Da dies bei häufigem Arbeiten mit Access schnell eine größere Menge von Dateien hervorrufen kann, wählen Sie für die Installation des Tools besser ein eigenes Verzeichnis – und zwar ein anderes, als das für .dll-Dateien übliche Verzeichnis c:\windows\system32.
Bild 7: Einstellungen des CodeHistory-Tools
Für die Erstellung von Toolwindows benötigen Sie Microsoft Visual Studio und Visual Basic-Kenntnisse. Wenn Sie bisher nur mit Access und VBA gearbeitet haben, müssen Sie sich ein wenig umstellen: Die Entwicklung mit Visual Basic scheint weniger intuitiv zu sein und das Erstellen von Benutzerformularen geht anfangs nicht so flott von der Hand wie unter Access. Die mit der nachfolgend beschriebenen Technik erstellten Toolwindows lassen sich mit der VBA-Entwicklungsumgebung ab Version 2000 verwenden – Sie erinnern sich, das war der Start einer gemeinsamen VBA-Entwicklungsoberfläche für alle Office-Anwendungen. Dementsprechend können Sie COM-Add-Ins auch in Word, Excel und Co. verwenden – allerdings nur, wenn diese nicht speziell auf den Einsatz mit Access ausgelegt sind. Für das hier vorgestellte CodeHistory-Tool gilt das nicht, es ist universell einsetzbar.
Programmierung von COM-Add-Ins für den VBA-Editor
Für die Entwicklung von COM-Add-Ins gibt es in Microsoft Visual Basic eine spezielle Vorlage namens Addin. Wenn Sie ein neues Projekt auf Basis dieser Vorlage erstellen, legt Visual Basic direkt Verweise auf einige benötigte Bibliotheken an (Menüeintrag Projekt/Verweise, s. Abb. 8).
Bild 8: Notwendige Verweise für COM-Add-Ins
Außerdem stellt diese Vorlage bereits zwei Objekte bereit, die Sie im Projektexplorer vorfinden (Strg + R, s. Abb. 9).
Mit dem Connect-Objekt finden Sie dort auch schon das für die Verwendung eines COM-Add-Ins wichtigste Element. Um dessen Funktionsweise zu erläutern, sind einige Vorbemerkungen erforderlich:
Beim Erzeugen der .dll-Datei mit dem Menübefehl Datei ( MyAddin.dll erstellen… (der Name der .dll-Datei entspricht dem Projektnamen und kann leicht geändert werden) wird auf dem aktuellen Rechner direkt ein Eintrag über das COM-Add-In in der Registry vorgenommen.
Anwendungen, die grundsätzlich COM-Add-Ins einbinden (Visual Studio, Visual Studio for Applications, Access …), durchsuchen beim Start den Bereich in der Registry, in dem die COM-Add-Ins eingetragen sind, und laden die für sie vorgesehenen Add-Ins. Die COM-Add-Ins sind dann über den jeweiligen Add-In-Manager aufrufbar – in der VBA-Entwicklungsumgebung etwa wie in Bild 1.
Bild 9: Per Vorlage bereitgestellte Objekte
Interaktion
Nun sollen die COM-Add-Ins ja nicht irgendwelche nebenläufigen Aufgaben erledigen, sondern konkret mit der jeweiligen Benutzungsumgebung zusammenhängende Unterstützung bieten.
Dazu ist eine bestimmte Art von Interaktion zwischen der Benutzungsoberfläche und dem COM-Add-In erforderlich. Die Benutzungsoberfläche muss dem COM-Add-In beim Aufruf mitteilen, wer sie ist, damit das COM-Add-In seine Dienste dort anbieten kann.
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