{"id":55000387,"date":"2023-10-01T00:00:00","date_gmt":"2023-10-19T13:10:29","guid":{"rendered":"http:\/\/access-im-unternehmen.aix-dev.de\/aiu\/?p=387"},"modified":"-0001-11-30T00:00:00","modified_gmt":"-0001-11-30T00:00:00","slug":"COMAddIns_registrieren","status":"publish","type":"post","link":"https:\/\/vbentwickler.de\/COMAddIns_registrieren\/","title":{"rendered":"COM-Add-Ins registrieren"},"content":{"rendered":"

\"\"<\/p>\n

Aus verschiedenen Gründen kann die Installation eines COM-Add-Ins für eine Office-Anwendung fehlschlagen – oder zumindest erreicht man damit nicht das gewünschte Ergebnis. Zum Beispiel könnte ein Benutzer das Setup mit dem COM-Add-In, das normalerweise für den aktuellen Benutzer installiert wird, im Kontext eines anderen Benutzers installieren – zum Beispiel als Administrator. Dann erscheint das COM-Add-In für den Benutzer jedoch nicht. In diesem Artikel zeigen wir zwei schnelle Wege, wie die Installation dennoch gelingt, sofern die DLL-Datei mit dem COM-Add-In vorliegt. Außerdem schauen wir uns an, wo in der Registry der Eintrag für ein COM-Add-In landet und was die verschiedenen Einträge bedeuten.<\/b><\/p>\n

Setups haben meist den Zweck, die Installation einer Software für den Benutzer so angenehm wie möglich zu machen. Manchmal klappt es allerdings einfach nicht wie gewünscht. Das hängt zum Beispiel damit zusammen, dass die Registry des Benutzers anders aufgebaut ist, als es das Setup erwartet. Dann werden die für den reibungslosen Betrieb erforderlichen Einträge in der Registry aus Sicht des Setups zwar an der richtigen Stelle vorgenommen, aber sie werden vom System nicht berücksichtigt.<\/p>\n

Es gibt nämlich bestimmte Registry-Bereiche, die Office-Anwendungen beim Start untersuchen, um zu erfahren, ob COM-Add-Ins oder andere Anwendungen vorliegen, die mit der Office-Anwendung gestartet werden sollen.<\/p>\n

In diesem Magazin haben wir bereits einige COM-Add-Ins vorgestellt, die selbst festlegen, an welche Stellen der Registry die notwendigen Einträge geschrieben werden sollen. In dem COM-Add-In aus dem Artikel COM-Add-In für Word: PDF-Export <\/b>(www.vbentwickler.de\/383<\/b>) legen wir das beispielsweise wie in Bild 1 fest. Die Konstante RootRegistryFolder_WORD <\/b>nimmt den Basispfad auf, die Funktion DllRegisterServer <\/b>legt die Einträge beim Registrieren der Anwendung in der Registry an.<\/p>\n

\"Anweisungen<\/p>\n

Bild 1: Anweisungen zum Anlegen der Registry-Einträge<\/span><\/b><\/p>\n

Wie landen die Einträge in der Registry?<\/h2>\n

Wenn wir wie in dem Artikel gezeigt mit twinBASIC entwickeln und die Anwendung kompilieren, startet twinBASIC automatisch die Prozedur DllRegisterServer <\/b>und trägt so die Einträge in die Registry ein.<\/p>\n

Wenn wir ein Setup mit InnoSetup erstellen, wie wir es in Installation mit Inno Setup: Die Basics <\/b>(www.vbentwickler.de\/382<\/b>) beschreiben, fügen wir dem Eintrag für die DLL-Datei noch den Zusatz regserver<\/b> unter Flags hinzu.<\/p>\n

Dadurch wird die Funktion DllRegisterServer <\/b>automatisch aufgerufen:<\/p>\n

[Files]\r\nSource: \"Build\\amWordPDFExport_win32.dll\"; DestDir: \"{app}\"; Flags: regserver ignoreversion; Check:Is32Bit <\/pre>\n
Hier kann das in der Einleitung beschriebene Szenario auftreten. Wenn die Funktion DllRegisterServer <\/b>in einen Bereich der Registry schreibt, der dem ausführenden Benutzer gehört, landen die Einträge auch in dem Bereich der Registry für diesen Benutzer.<\/p>\n
Andere Benutzer auf dem gleichen Rechner können das COM-Add-In somit nicht nutzen.<\/p>\n
Das Ergebnis sieht übrigens wie in Bild 2 aus.<\/p>\n
\"Die<\/p>\n
Bild 2: Die resultierenden Registry-Einträge<\/span><\/b><\/p>\n
Wenn die DLL jedoch schon auf dem Rechner ist, haben wir folgende Möglichkeiten:<\/p>\n