Suchergebnisse

Wenn das funktioniert, dann habt ihr wohl alle Excel-Sicherheitsfunktionen ausgeschaltet. Aber das kann mir egal sein. "self modifying code" ist hässlich. Ich würde eher den Weg eines zentral verwalteten Excel-AddIns gehen. msdn.microsoft.com/en-us/libra…g597509(v=office.14).aspx

Eigentlich schon. Kurz: Anstatt Code-Modifikation würde ich auf zentralverwaltete Module setzen.

Letztendlich ist ein AddIn eine ganz normale Excel-Datei, deren (Public) Module und Klassen mit Code gefüllt sind. Das speicherst du ab an einer firmenweit zugänglichen Stelle mit der Extension .xlam. (z.B. CompanyVbaLibrary.xlam). In allen Excel-Dateien, wo du den Code benötigst, trägst du in der IDE als Verweis diese Datei ein. Dann kannst du die Methoden und Funktionen ganz normal aufrufen. Fertig. Ich würde das Projekt der xlam-Datei mit einem Passwort schützen, damit nicht jeder User die Bi…

Zitat von Hotdogxxxx: „Anstelle von 'Call Modul' muss ich doch sicherlich 'Call Addin Modul' nutzen.“Call ist sowieso obsolet. Ein Methode ruft man einfach durch deren Namen auf. Du kannst die AddIn-Methoden wie lokale Methoden aufrufen. Du musst halt in deinem VBA-Projekt einen Verweis auf die xlam setzen. Du solltest dein Library-Codeprojekt halt nicht gerade VBAProject nennen, sonst beisst es sich mit dem Standard. Für einen eindeutigen Aufruf kannst du auch direkt adressieren: <libraryprojec…

Das bedeutet wohl, dass du in deiner Bibliothek keine Klassenmodule veröffentlichst. Da hätte ich sonst eine Rückfrage erwartet. Jedenfalls viel Spaß mit der Lösung.