<\/p>\n
ActiveX-Komponenten müssen, so sie unter VBA ansprechbar sein sollen, im System registriert werden. Dies erfordert administrative Rechte unter Windows, weshalb viele Administratoren solche externen Komponenten leider gar nicht gern sehen. Dass Sie manche ActiveX-Dateien jedoch auch ganz ohne Registrierung verwenden können, zeigen die Techniken dieses Beitrags.<\/b><\/p>\nVBA und die COM-Registry<\/h2>\n
Es gibt zunächst unter VBA zwei Möglichkeiten, um ein Objekt einer ActiveX-Komponente zu erzeugen. Die eine nutzt die Methode CreateObject<\/b>, der Sie die sogenannte ProgID<\/b> übergeben und das Resultat einer Objektvariablen zuweisen. Bei dieser kann es sich um den allgemeinen Typ Object<\/b> handeln. Dennoch lassen sich die Funktionen des Objekts namentlich über den Punkt-Operator ansprechen, obwohl Object<\/b> selbst ja keinerlei Methoden aufweist. Hier verwenden Sie Late Binding<\/b>.<\/p>\n
Late<\/b> deshalb, weil Windows hier den Methodennamen erst beim Aufruf auswerten muss, um an den Funktionszeiger zu gelangen, der schließlich angesprungen wird. Dieser Vorgang benötigt einige Zeit, weshalb Late Binding<\/b> die Performance erheblich herabsetzt. Dafür aber brauchen Sie immerhin keinen Verweis auf die Komponente zu setzen!<\/p>\n
Anders bei der zweiten Methode, die sich des Operators New<\/b> bedient. Nach dem Schreiben dieses Ausdrucks in eine VBA-Routine listet IntelliSense<\/b> gleich alle Klassen auf, die sich damit instanziieren lassen. Dabei kann VBA aber nur auf jene zugreifen, die es in den Verweisen des aktuellen VBA-Projekts findet. Demzufolge muss auf die gefragte ActiveX-Komponente ein Verweis gesetzt sein. VBA kennt dann aus dieser Type Library<\/b> den genauen Aufbau des Objekts, weshalb Sie es es einer Objektvariablen des dezidierten Klassentyps zuweisen können. Nun haben Sie Early Binding<\/b> vor sich. Technisch bedeutet dies, dass VBA nun bereits beim Kompilieren die Funktionszeiger ermitteln kann und eben diese in das PCode<\/b>-Kompilat einsetzt. Das steigert die Performance ungemein.<\/p>\n
Doch beiden Methoden zum Erzeugen des Objekts ist eines gemein: Sie funktionieren nicht ohne die Registrierung der ActiveX-Komponente unter Windows. Der Verweis auf eine Komponente macht es nötig, dass deren Type Library<\/b> (Bibliothek) und deren Interfaces<\/b> (Klassen) in den Zweigen HKEY_CLASSES_ROOT<\/b> und den Unterschlüsseln typelib<\/b>, interface<\/b> und clsid<\/b> eingetragen sind. Für CreateObject<\/b> braucht es zusätzlich Einträge unter HKEY_CLASSES_ROOT<\/b> direkt, wobei die ProgID<\/b> selbst den Schlüssel stellt und wiederum auf eine zugehörige clsid<\/b> verweist.<\/p>\n
Beispiel: Sie möchten den Ordnerpfad zum Windows-Desktop ermitteln. Dafür können Sie etwa die Shell<\/b>-Bibliothek verwenden. Sie wählen diese in der Liste der Verweise unter dem Eintrag Microsoft Shell Controls And Automation<\/b> aus. Die Bibliothek zeigt sich dann im Objektkatalog unter der Rubrik Shell32<\/b>. Mit diesem Code-Schnipsel erhalten Sie dann den Pfad:<\/p>\n Ohne VBA-Verweis auf die Shell<\/b>-Bibliothek geht es mit Late Binding<\/b> auch so:<\/p>\n Was passiert hier VBA sucht in der Registry unter HKEY_CLASSES_ROOT<\/b> und dem Schlüssel Shell.Application<\/b>. Dort wertet es den Unterschlüssel CLSID<\/b> aus, der die GUID<\/b> {13709620-C279-11CE-A49E-444553540000}<\/b> zurückgibt. Im Folgenden schreitet es zum Zweig HKEY_CLASSES_ROOT\\clsid<\/b> und sucht dort nach dieser GUID<\/b>. Es wird fündig und liest nun den Unterschlüssel InProcServer32<\/b> aus, der auf die ActiveX-Datei %SystemRoot%\\system32\\shell32.dll<\/b> verweist. Die kann VBA nun theoretisch schon laden und das Objekt über die GUID<\/b> und die allen COM-Komponenten eigene API-Funktion DLLGetClassObject<\/b> erzeugen. Allerdings weiß es dann noch nichts über das Objekt selbst. Dazu muss es einen zweiten Unterschlüssel Typelib<\/b> auswerten, der die GUID<\/b> zur Shell<\/b>-Bibliothek zurückgibt. Diese Bibliothek muss es nun ebenfalls laden, um dort nach der Klasse mit der zuvor ermittelten CLSID<\/b> zu suchen. Aus HKCR\\TypeLib\\ Es findet die zur CLSID<\/b> gehörige Klasse und erfährt nun erst, welches Standard-Interface<\/b> ihr eigen ist. Dabei sollte es sich ab Windows 7 um IShellDispatch5<\/b> oder IShellDispatch6<\/b> handeln. Nun nimmt es sich die Definition dieses Interfaces vor und kennt damit dessen Methoden. Das Interface selbst holt es sich über einen Aufruf der Standard-COM<\/b>-Methode QueryInterface<\/b> auf das zuvor per DLLGetClassObject<\/b> erzeugte Objekt. Erst jetzt kann VBA das Objekt einer Variablen zuweisen.<\/p>\n Sie sehen, dass VBA unter der Haube allerlei zu bewältigen hat, wenn es um Late Binding<\/b> geht. Dabei ist der Vorgang in Wirklichkeit noch deutlich komplizierter, als geschildert. Nachvollziehbar: die Performance geht dabei in die Knie. <\/p>\n Doch die beiden Methoden zum Erzeugen von Objekten sind ja eigentlich nicht Thema dieses Beitrags. Die Erläuterungen sind aber für das Verständnis der weiteren Ausführungen nützlich.<\/p>\n Der Sachverhalt ist jener: Es gibt nur wenig, was Sie unter C++<\/b> realisieren können, was sich nicht auch unter Visual Basic 6<\/b> oder VBA umsetzen ließe! Der Aufwand dafür allerdings ist ungleich höher. Denn mit normalem VBA-Code kommen Sie nicht weiter. Gerade dann, wenn es um COM<\/b> geht, benötigen Sie in der Regel wenigstens eine Bibliothek, wie die oleexp.tlb<\/b>, welche die Definition der grundlegenden Interfaces<\/b> enthält. Wir stellten diese Bibliothek bereits vor (Shortlink 1096<\/b>) und werden weitere Beiträge zum Umgang mit ihr veröffentlichen. Hier aber geht es ja gerade darum, die Zahl der Verweise im VBA-Projekt minimal zu halten, weshalb in der vorliegenden Lösung auf externe Bibliotheken komplett verzichtet wurde.<\/p>\n Zum Einsatz kommt dafür eine Handvoll standardisierter Windows-API-Funktionen und … etwas Assembler-Code<\/b>! Ja, Sie hören richtig! Tatsächlich kann mit einigen Tricks auch unter VBA Maschinen-Code ausgeführt werden. Sehr komfortabel ist das indessen nicht, aber diese Code-Teile sind in der Lösung auch nicht sonderlich umfangreich.<\/p>\n Untergebracht ist alles im Modul mdlCOMLoaderAsm<\/b> der Demodatenbank Regless.accdb<\/b>. Die Routine zum Erzeugen eines Objekts nennt sich darin GetCOMInstance<\/b>. Sie übergeben ihr als Parameter einerseits den Pfad zur ActiveX-Datei – die nicht registriert sein muss! – und andererseits die ProgID<\/b> des gewünschten Objekts. Alternativ können Sie statt der ProgID<\/b> auch direkt die CLSID<\/b> der Komponente angeben, wenn Sie diese kennen. <\/p>\n Wollten wir hier die genaue Funktionsweise der komplexen Prozedur erläutern, so könnte damit sicher die gesamte Ausgabe gefüllt werden. Deshalb beschränken wir uns nur auf die prinzipiellen Techniken. Ansonsten verwenden Sie das Modul einfach unbesehen und importieren es bei Bedarf in Ihre eigenen Datenbankprojekte. Es weist keine weiteren Abhängigkeiten auf und lief bisher in der vorliegenden Version in unseren eigenen Projekten anstandslos. Die Anwendung erfolgt also nach diesem Schema:<\/p>\n Die Objektvariable O<\/b> soll das Objekt aufnehmen, welches wir instanziieren möchten. In sFile<\/b> steht der volle Pfad zur ActiveX-Datei die das Objekt beherbergt. sProgIDCLSID<\/b> speichert die ProgID<\/b> oder wahlweise die CLSID der Komponente. Hier verwenden wir die shell32.dll<\/b> und in ihr die Objektklasse Shell<\/b>. Damit erhalten wir über den Aufruf von GetCOMInstance<\/b> dasselbe Objekt, wie mit dem eingangs vorgestellten Code. Typename<\/b> gibt korrekt die Interface<\/b>-Klasse IShellDispatch6<\/b> zurück. Statt TueDiesUndDas<\/b> könnten Sie nun eben den Pfad zum Desktop ermitteln:<\/p>\n Die Routine läuft schneller ab, wenn Sie statt der ProgID<\/b> die CLSID<\/b> einsetzen:<\/p>\n Sie finden diese in der Registry im Zweig HKCR\\Shell.Application\\CLSID<\/b>. Die Funktion muss dann nicht erst umständlich die ProgID<\/b> in die benötigte CLSID<\/b> umwandeln. Des Weiteren können Sie den vollen Pfad zur Datei auch abkürzen:<\/p>\n Das funktioniert in folgenden Fällen: Die Datei befindet sich entweder im Verzeichnis der Datenbank, oder im Suchpfad von Windows. Der besteht aus den Windows-Verzeichnissen und allen, die in der Umgebungsvariablen PATH<\/b> abgelegt sind.<\/p>\n Dass das Ganze funktioniert, können Sie übrigens mit der Funktion GetDesktopPath<\/b> im Modul mdlTest<\/b> der Demodatenbank nachvollziehen.<\/p>\n Einen dritten optionalen Parameter von GetCOMInstance<\/b> haben wir noch unterschlagen: Steht ClearCache<\/b> auf True<\/b>, dann ermittelt die Routine aus einer ProgID<\/b> die CLSID<\/b> immer neu.<\/p>\n Wird False<\/b> übergeben (Standard), so speichert das Modul die ermittelte CLSID<\/b> beim ersten Mal ab und verwendet sie fortan bei jedem Aufruf der Funktion mit derselben ProgID<\/b>.<\/p>\n Das beschleunigt die Sache dann deutlich. (Allerdings werden Sie die Instanziierung von Objekten auch nicht etwa fortlaufend in einer Schleife ausführen, so dass der Performance-Gewinn wohl nicht sonderlich zu Buche schlägt.)<\/p>\n Die erste Aktion besteht darin, die ActiveX-Datei zu laden. Das übernimmt an sich die API-Funktion LoadLibrary<\/b>, welcher Sie den Pfad übergeben und ein Handle<\/b> auf das Modul erhalten. Das aber ist nicht immer notwendig, denn die Datei kann sich bereits im Prozessraum von Access befinden. Bei der shell32.dll<\/b> etwa ist dies der Fall. Access benötigt sie selbst für seine internen Funktionen. Dann aber reicht die API-Funktion GetModuleHandle<\/b> aus:<\/p>\n Bei API-Funktionen ereignet sich in der Regel kein VBA-Fehler, wenn falsche Parameter übergeben wurden. Stattdessen definiert der Rückgabewert den Erfolg. Hier verhält es sich so, dass die in hModule<\/b> (Long-Wert) gespeicherte Rückgabe 0<\/b> ist, wenn die Funktion fehlschlug. Dann kommt LoadLibrary<\/b> zum Zug:<\/p>\n Findet die die Funktion auch hier die Datei nicht, weil deren Pfad nicht stimmt oder sie sich nicht im Windows-Suchpfad befindet, so kommt es zum letzten Versuch:<\/p>\n Hier wird das Datenbankverzeichnis auf Existenz der Datei befragt. Schlagen alle Methoden fehl, so löst die Routine einen VBA-Fehler aus und verlässt die Prozedur:<\/p>\n Wir gehen davon aus, dass die Datei erfolgreich geladen wurde. Nun geht es an den nächsten Test, der untersucht, ob die Datei ActiveX-kompatibel ist und die die API-Funktion DllGetClassObject<\/b> exportiert:<\/p>\n Der API-Funktion GetProcAddress<\/b> übergeben Sie das zuvor erhalten Handle<\/b> (hModule<\/b>) und den Namen einer Funktion. In der Long-Variablen pFunc<\/b> ist nun der Funktionszeiger gespeichert. Steht hier eine Null, so unterstützt die Datei diese Funktion nicht und es kommt ebenfalls zu einer Fehlermeldung und zum Verlassen der Routine.<\/p>\n Anhand des Funktionszeigers kann im Folgenden die Funktion DllGetClassObject<\/b> im Prinzip aufgerufen werden. Das allerdings kann VBA im Unterschied zu C++ keinesfalls! Hier kommt eine Hilfsfunktion CallPointerASM<\/b> zum Einsatz, die Ihnen garantiert kryptisch vorkommen wird, weil sie auf Umwegen Assembler<\/b>-Code generiert, der von der API-Funktion CallWindowProc<\/b> angesprungen wird. Sie ist so deklariert:<\/p>\n Mit dem Parameter fnc<\/b> setzen Sie den Funktionszeiger und in Params()<\/b> eine beliebige Anzahl von zu übergebenden Parametern, da diese Variable vom Typ ParamArray<\/b> ist. Die Prozedur erzeugt nun mit API-Funktionen, wie VirtualAlloc<\/b>, einen Speicherblock im RAM<\/b> und bringt dort die Parameter unter. Genauer pusht<\/b> es diese auf den virtuellen Stack<\/b>. Abschließend gibt es diesen Speicherblock auch gleich wieder frei (VirtualFree<\/b>). Zuvor jedoch wird die API-Funktion CallWindowProc<\/b> zweckentfremdet. Eigentlich ist sie dafür gedacht, um die Standard-Routine eines Windows-Fensters anzuspringen. Möglicherweise kennen Sie sie deshalb schon von Subclassing<\/b>-Routinen, wo Windows-Messages<\/b> an eine per AddressOf<\/b> erhaltene VBA-Modulfunktion geleitet werden und von dort aus weiter an die ursprüngliche Funktionsadresse über CallWindowProc<\/b>, damit das Windows-Fenster weiter funktioniert, wie gedacht. Tatsächlich aber weiß Windows nicht, ob die Funktionsadresse die eines Fensters ist, oder irgendetwas Anderes. Wir verwenden stattdessen nun den eben erzeugten Speicherblock als Adresse, welcher den Assembler<\/b>-Code enthält. Windows führt nun unmittelbar etwa die Funktion DllGetClassObject<\/b> aus!<\/p>\n Es kann sein, dass Sie ähnlichen Code im Netz finden, wenn Sie nach CallPointer VB<\/b> googeln. Die meisten Lösungen verwenden dabei einfach ein Byte-Array, in dem der Assembler<\/b>-Code abgespeichert wird. An CallWindowProc<\/b> wird dann die Adresse des Byte-Arrays geleitet. Das hat früher auch funktioniert, seit VBA 7<\/b> (Office 2010<\/b>) jedoch nicht, weil nun aus Sicherheitsgründen der allen Variablen zugrundeliegende RAM-Speicher nicht mehr mit dem Attribut PAGE_EXECUTE_READWRITE<\/b> ausgestattet ist, um Ungemach zu verhindern. Deshalb wurde die Routine CallPointerASM <\/b>komplett neu entwickelt.<\/p>\n Zurück zur Prozedur GetCOMInstance<\/b>! Bevor die API-Funktion DllGetClassObject <\/b>in ihr angesprungen werden kann, muss erst noch die CLSID<\/b> bereitstehen. Denn die API-Funktion hat folgende prototypische Definition:<\/p>\n Sie benötigt also die CLSID<\/b> des Objekts, welches man erhalten möchte. Außerdem muss die IID<\/b> eine GUID<\/b> aufweisen, die zu einem Interface<\/b> gehört, welches die Funktion zurückgeben soll. Für ein Objekt reicht hier das Standard-Interface<\/b> IUnknown<\/b> aus, für die Instanziierung muss aber das Interface<\/b> IClassFactory<\/b> her, weil erst dieses die endgültige Funktion CreateInstance<\/b> beherbergt.<\/p>\n Die Aufgabe, aus einer ProgID<\/b> eine CLSID<\/b> zu machen ohne dass die Klasse registriert ist (!), ist allerdings alles andere, als trivial. Die Hilfsroutine ScanCoClasses<\/b> übernimmt sie. Ihre Darstellung sprengte trotz der nur etwa 40 Zeilen endgültig den Rahmen dieses Beitrags. Sie simuliert über benutzerdefinierte Typen Interfaces der Abteilung ITypelib<\/b> und ITypeInfo<\/b>, deren Methoden sie abermals über CallPointerASM<\/b> aufruft. Dabei ermittelt sie alle CoClasses<\/b> der ActiveX-Datei und deren zugehörigen CLSIDs<\/b>, sowie ProgIDs<\/b>. Nachdem diese in einem Array abgespeichert sind, kann die Hauptroutine dieses durchlaufen und mit der übergebenen ProgID<\/b> vergleichen. Trifft ein Element zu, so haben Sie die CLSID<\/b> zur ProgID<\/b>. DllGetClassObject<\/b> kann nun ausgeführt und eine Instanz des gewünschten Objekts über die CreateInstance<\/b>-Methode von IClassFactory<\/b> erhalten werden.<\/p>\n Das ist alles nicht so einfach. Glückwunsch, wenn Sie das Kapitel bis zu diesem Punkt durchgehalten haben! Es ist tatsächlich nur für die Hartgesottenen unter Ihnen gedacht. Für den praktischen Einsatz des Moduls ist dieses Wissen nicht notwendig.<\/p>\n Im Download zum Beitrag finden Sie eine ActiveX-Datei mSimilarity.dll<\/b>, die unter anderem Strings auf ähnlichkeit untersuchen kann und aus eigener Feder stammt. Das ist ein Erfordernis, das gerade in Datenbanken oft benötigt wird. Aus einer Adressentabelle filtern Sie etwa jene Namen heraus, die bei falscher Schreibweise eines Suchbegriffs die ähnlichsten Treffer enthalten. Eine ähnliche Komponente kam im Beitrag Fehlertolerantes Suchen<\/b> (Shortlink 733<\/b>) bereits zum Einsatz. Dort ist auch der Umgang mit ihren Funktionen erschöpfend beschrieben. Die aktuelle DLL ist eine Weiterentwicklung mit mehr Methoden und verbesserter Performance. Eine bessere Alternative werden Sie wahrscheinlich vergeblich im Netz suchen… Und, bevor es wieder zu Nachfragen per E-Mail kommt: Ja, die DLL ist komplett Freeware<\/b> und darf ohne weitere Hinweise in eigenen Projekten eingesetzt und weitergegeben werden, ob privat oder kommerziell. Eine kleine Angabe zum Autor mossSOFT<\/b> an der einen oder anderen Stelle kann jedoch nicht schaden.<\/p>\n Sie registrieren die DLL über die begleitende Datei register_mSimilarity.bat<\/b>, welche Sie im Administrator-Kontext ausführen. Bei Weitergabe Ihres Datenbankprojekts entfiele dieser Schritt, weil wir Klassen der DLL regless<\/b> instanziieren werden. Für die Demodatenbank ist die Registrierung allerdings nötig, weil deren Routinen teilweise ihren Bibliotheksverweis ansprechen. <\/p>\n Hier ein Code-Schnipsel, welches die ähnlichkeitsmethode JaroWinkler<\/b> demonstriert:<\/p>\n Die gefragte Klasse in der DLL nennt sich CSimilarity<\/b>. Eine Objektinstanz auf sie landet in der Variablen C<\/b>. Zwei Begriffe in S1<\/b> und S2<\/b> weisen kleine Unterschiede in der Schreibweise auf. (Die erste ist korrekt!) JaroWinkler<\/b> vergleicht beide und gibt 92<\/b> als ähnlichkeitsfaktor aus. 100<\/b> wäre der Wert für komplette übereinstimmung. Als Limit für hinreichende ähnlichkeit nehmen Sie übrigens einen Wert zwischen 70<\/b> und 80<\/b>. Alles darunter ist eher fragwürdig.<\/p>\n Die Routine in Listing 1 testet nun die Performance der Methoden. Neben JaroWinkler<\/b> zieht sie zusätzlich die Alternative Ratcliff<\/b> heran. Die Variable n<\/b> speichert jeweils den ähnlichkeitswert. Beide Methoden werden in einer Schleife 1 Million Mal aufgerufen. Die dafür benötigte Zeit messen der VBA.Timer<\/b> und die Variable T<\/b>. Das Ergebnis auf meinem I7-5820<\/b>-Rechner:<\/p>\n <\/p>\n Listing 1: Dies ist der Standard-Code bei registrierter ActiveX-DLL<\/span><\/b><\/p>\n JaroWinkler<\/b> ist also geringfügig schneller, als Ratcliff<\/b>. Die zurückgegebenen ähnlichkeitswerte sind bei beiden fast identisch. Die Performance ist auch nicht schlecht: Jede Schleife auf die Funktionen wird in weniger als einer Sekunde durchlaufen. Sie können damit also eine Million Strings pro Sekunde vergleichen. Die Dauer, die VBA für die Schleife selbst benötigt, spielt übrigens keine Rolle. Ein Test auf eine Quasi-Null-Schleife in der folgenden Form gibt hier 0,0078 ms<\/b> für die Ausführungszeit aus. Das sind eine Milliarde Durchläufe pro Sekunde! VBA ist also alles andere als langsam:<\/p>\n Nun ersetzen wir in einer weiteren Routine die Instanziierung des Klassenobjekts per New<\/b> durch die regless<\/b>-Variante per GetCOMInstance<\/b>, wie in Listing 2. Sie übergeben hier in sFile<\/b> den Pfad zur Datei mSimilarity.dll<\/b> im Datenbankverzeichnis <\/b>und verwenden die ProgID<\/b> CSimilarity<\/b>. Den CLSID<\/b>-Cache des Moduls mdlCOMLoaderASM<\/b> leeren Sie mit übergabe von True<\/b> an den dritten Parameter ClearCache<\/b>. Der Rest der Prozedur ist identisch mit dem aus TestSimilarity1<\/b>. Wenig erstaunlich: die Performance ist auch nicht schlechter!<\/p>\n Listing 2: Und das ist die regless-Variante mit GetCOMInstance<\/span><\/b><\/p>\n Das liegt daran, dass erstens die Instanzierung des Objekts aus der Messung herausgelassen wurde – dafür messen wir gesondert etwa 90 ms<\/b> – und zweitens die Objektvariable C<\/b> als CSimilarity<\/b>-Typ deklariert ist, wodurch implizit Early Binding<\/b> auf die Verweisbibliothek mSimilarity<\/b> zum Einsatz kommt.<\/p>\n Ohne Verweis können Sie C<\/b> nur noch As Object<\/b> deklarieren, wodurch der Ausführungsmodus nach Late Binding<\/b> wechselt. Die hier nicht gelistete Routine TestSimilarity3<\/b> vollzieht dies. Für die Performance messen wir nun folgende Werte:<\/p>\n Tja, die ist nun um Größenordnungen geringer, als bei Early Binding<\/b>. Aber immerhin lassen sich auch damit etwa 250.000<\/b> Strings pro Sekunde vergleichen, was wohl noch hinzunehmen ist.<\/p>\n Es gibt jedoch noch eine alternative Methode, um die Funktionen der DLL aufzurufen und das Late Binding<\/b> zu umgehen. Die allerdings ist wieder ähnlich kompliziert, wie die Routine GetCOMInstance<\/b> …<\/p>\n Das Modul mdlCOMLoaderASM<\/b> enthält noch eine zusätzliche Prozedur CallCOMFunction<\/b>. Ihr übergeben Sie ein Objekt, die Adresse einer Methode und die ihr zu übergebenden Funktionsparameter. Als Ergebnis (Variant) erhalten Sie entweder nichts bei einer Sub<\/b>-Methode oder díe Rückgabe der Methode bei einer Funktion<\/b>. Listing 3 bildet die Prozedur ab.<\/p>\n Listing 3: Der Aufruf einer Methode eines Objekts erfolgt hier über die API-Funktion DispCallFunc<\/span><\/b><\/p>\n Im Kern bedient sie sich der API-Funktion DispCallFunc<\/b>. Die erwartet einen Zeiger auf das Objekt (Dim <\/span>oShell As <\/span>Shell32.Shell\r\nSet<\/span> oShell = New<\/span> Shell32.Shell\r\nDebug.Print<\/span> oShell.Namespace(0&).Self.Path<\/pre>\nDim <\/span>oShell As Object<\/span>\r\nSet<\/span> oShell = CreateObject(\"Shell.Application\")\r\nDebug.Print<\/span> oShell.Namespace(0&).Self.Path<\/pre>\nActiveX-Objekte per API erstellen<\/h2>\n
Dim <\/span>O As Object<\/span>\r\nDim <\/span>sFile As String<\/span>\r\nDim <\/span>sProgIDCLSID As String<\/span>\r\nsFile = \"c:\\Windows\\SysWOW64\\shell32.dll\"\r\nsProgIDCLSID = \"Shell\"\r\nSet<\/span> O = GetCOMInstance(sFile, sProgIDCLSID)\r\nDebug.Print<\/span> Typename(O) ''''-> IShellDispatch6\r\nO.TueDiesUndDas ...<\/pre>\nDebug.Print<\/span> O.Namespace(0&).Self.Path\r\nSet<\/span> O = Nothing<\/pre>\nsProgIDCLSID = \"{13709620-C279-11CE-A49E-444553540000}\"<\/pre>\nsFile = \"shell32.dll\"<\/pre>\n
GetCOMInstance-Funktion im Detail<\/h2>\n
hModule = GetModuleHandle(sFile)<\/pre>\n
If <\/span>hModule = 0 Then<\/span> hModule = LoadLibrary(sFile)<\/pre>\nIf <\/span>hModule = 0 Then<\/span> \r\n hModule = LoadLibrary(CurrentProject.Path & \"\\\" & sFile)\r\nEnd if<\/pre>\nIf <\/span>hModule = 0 Then<\/span>\r\n Err.Raise vbObjectError, , sFile & \" module not loaded\"\r\n Exit Function<\/span>\r\nEnd If<\/span><\/pre>\npFunc = GetProcAddress(hModule, \"DllGetClassObject\")\r\nIf <\/span>pFunc = 0 Then<\/span>\r\n Err.Raise vbObjectError, , _\r\n sFile & \" does not export DllGetClassObject\"\r\n FreeLibrary hModule\r\n Exit Function<\/span>\r\nEnd If<\/span><\/pre>\nPrivate Function <\/span>CallPointerASM( _\r\n ByVal fnc As Long<\/span>, ParamArray Params()) As Long<\/span>\r\n ...\r\nEnd Function<\/span><\/pre>\nDeclare Function DllGetClassObject( _\r\n Byval CLSID As <\/span>GUID, _\r\n ByVal IID As <\/span>GUID, _\r\n pResultingInterface As Long<\/span>) As Long<\/span><\/pre>\nBeispiel ActiveX-Datei zum ähnlichkeitsvergleich<\/h2>\n
Dim <\/span>C As <\/span>CSimilarity\r\nDim <\/span>S1 As String<\/span>, S2 As String<\/span>\r\nSet<\/span> C = New<\/span> CSimilarity\r\nS1 = \"Trowitzsch\"\r\nS2 = \"Trowitsch\"\r\nDebug.Print<\/span> C.JaroWinkler(S1,S2) ''''-> 92<\/pre>\nSub <\/span>TestSimilarity1()\r\n Dim <\/span>C As <\/span>New<\/span> CSimilarity\r\n Dim <\/span>I As Long<\/span>, n As Integer<\/span>\r\n Dim <\/span>S1 As String<\/span>, S2 As String<\/span>\r\n Dim <\/span>T As Single<\/span>\r\n S1 = \"Trowitzsch\": S2 = \"Trowitsch\"\r\n n = C.JaroWinkler(S1, S2)\r\n n = C.Ratcliff(S1, S2)\r\n DoEvents\r\n T = VBA.Timer\r\n For I = 1 To 1000000\r\n n = C.JaroWinkler(S1, S2)\r\n Next<\/span> I\r\n Debug.Print<\/span> VBA.Timer - T, n\r\n T = VBA.Timer\r\n For I = 1 To 1000000\r\n n = C.Ratcliff(S1, S2)\r\n Next<\/span> I\r\n Debug.Print<\/span> VBA.Timer - T, n\r\n Set<\/span> C = Nothing\r\nEnd Sub<\/span><\/pre>\n0,84375 s 92 \r\n0,9414063 s 91<\/pre>\n
For i = 1 To 1000000\r\n n = n\r\nNext<\/span> i<\/pre>\nSub <\/span>TestSimilarity2()\r\n Dim <\/span>sFile As String<\/span>\r\n Dim <\/span>C As <\/span>CSimilarity\r\n Dim <\/span>sCLSIDProgID As String<\/span>\r\n Dim <\/span>I As Long<\/span>, n As Integer<\/span>\r\n Dim <\/span>S1 As String<\/span>, S2 As String<\/span>\r\n Dim <\/span>T As Single<\/span>\r\n S1 = \"Trowitzsch\": S2 = \"Trowitsch\"\r\n sCLSIDProgID = \"CSimilarity\"\r\n sFile = CurrentProject.Path & \"\\mSimilarity.dll\"\r\n Set<\/span> C = GetCOMInstance(sFile, sCLSIDProgID, True<\/span>)\r\n ''''= CSimilarity\r\n n = C.JaroWinkler(S1, S2)\r\n n = C.Ratcliff(S1, S2)\r\n DoEvents\r\n T = VBA.Timer\r\n For I = 1 To 1000000\r\n n = C.JaroWinkler(S1, S2)\r\n Next<\/span> I\r\n Debug.Print<\/span> VBA.Timer - T, n\r\n T = VBA.Timer\r\n For I = 1 To 1000000\r\n n = C.Ratcliff(S1, S2)\r\n Next<\/span> I\r\n Debug.Print<\/span> VBA.Timer - T, n\r\n Set<\/span> C = Nothing\r\nEnd Sub<\/span><\/pre>\n3,929688 s 92\r\n4,199219 s 91<\/pre>\n
Direkter Methodenaufruf in ActiveX-Objekten<\/h2>\n
Function <\/span>CallCOMFunction(ByVal InterfacePointer As Long<\/span>, ByVal VTableOffset As Long<\/span>, _\r\n ByVal fuReturnType As <\/span>eCALLRETURNTUYPE, _\r\n ByVal Convention As <\/span>eCALLCONVENTION, _\r\n ParamArray fuParameters() As Variant<\/span>) As Variant<\/span>\r\n Dim <\/span>I As Long<\/span>, n As Long<\/span>, ret As Long<\/span>\r\n Dim <\/span>vParams() As Variant<\/span>\r\n Dim <\/span>vRtn As Variant<\/span>\r\n \r\n If <\/span>InterfacePointer = 0& Or VTableOffset < 0& Then<\/span> Exit Function<\/span>\r\n If <\/span>Not<\/span> (fuReturnType And &HFFFF0000) = 0& Then<\/span> Exit Function<\/span>\r\n vParams() = fuParameters()\r\n n = UBound<\/span>(vParams) + 1&\r\n If <\/span>n > 0& Then<\/span>\r\n For I = 0& To n - 1&\r\n vParamPtr(I) = VarPtr(vParams(I))\r\n vParamType(I) = VarType(vParams(I))\r\n Next<\/span>\r\n End If<\/span>\r\n ret = DispCallFunc(InterfacePointer, VTableOffset, Convention, _\r\n fuReturnType, n, vParamType(0), vParamPtr(0), vRtn)\r\n If <\/span>ret = 0& Then<\/span> ''''OK\r\n CallCOMFunction = vRtn\r\n Else<\/span>\r\n Debug.Print<\/span> \"Error h\" & Hex(ret) & \" at vtableoffset \"; VTableOffset\r\n End If<\/span>\r\nEnd Function<\/span><\/pre>\n