VBA-Code verwalten und verteilen

VBA ist eine nette Sache, die Integration in der Anwendung ist gut und kleine Ergebnisse lassen sich einfach und schnell realisieren. Bei der Sicherheit ist VBA aber nicht so prickelnd, wird es doch als Einfallstor für Schädlinge missbraucht. Da kann man aber mit bisschen Struktur gegenhalten. 🙂

Wo der Kram liegt

VBA-Code sollte gesammelt abgelegt werden, am besten in einer zentralen Vorlagen-Datei, die dann von allen Vorlagen und Dokumenten benutzt wird. Code sollte tunlichst nicht in fertigen Dokumenten liegen und ebenso wenig per Mail und Co verschickt werden. Im besten Fall filtert der Virenscanner sowas direkt raus und der Empfänger hat nix in den Händen.

Entwickelt man für sich allein, kann ein lokaler Ordner genutzt werden. In Firmen sollen ja aber mehrere Leute mit den Funktionen arbeiten, da bietet sich ein Netzlaufwerk an. Die Grundstruktur ist aber in beiden Fällen gleich, zwei Unterordner für Word und Excel, die z. B . in einem „startup“ Ordner liegen damit der Bezug klarer wird.

Angelegte Ordner für VBA

In diese Ordner kommen jetzt die Templates mit Makros. Wer ein Sammelsurium an VBA-Code hat, darf hier gern von Null anfangen und die Funktionen schrittweise in die neue zentrale Datei importieren. Man putzt ja gern. 🙂

Word dotm Template und Excel AddIn in getrennten Ordnern

Den Kram einbinden

Fast fertig, jetzt müssen wir Word und Excel nur noch verraten 1.) wo die Dateien liegen und 2.) das sie geladen werden dürfen. Fangen wir mal bei Word an:

1. In den Word Optionen bei Erweitert werden die Dateispeicherorte geöffnet und der neue startup-Pfad eingetragen
2. Jetzt noch im Trust Center den Pfad als vertrauenswürdig eintragen, bei Netzwerkordnern muss zusätzlich der Haken dafür gesetzt werden. Wird direkt der startup-Ordner mit Unterordnern zugelassen, sind die VBA-Umgebungen gegenseitig nutzbar.
3. Die Makrosicherheit kann scharf geschaltet werden, es werden nur die vertrauenswürdigen Orte zugelassen.

Für Excel läuft das fast identisch ab.

1. Einstellen des „alternativen“ startup-Ordners.
2. Der startup-Ordner wird meistens automatisch selber eingetragen, Kontrolle schadet aber nicht.
3. Auch bei Excel wird die Makrosicherheit verschärft.

Test Test Test

So, wenn wir jetzt keinen Blödsinn angestellt haben, dann sollte das funktionieren. Kann man auch mit einer beliebigen VBA-Datei testen, die im Ordner liegt. Hier mal veranschaulicht mit der alten iox-Programmierung:

Tada, it works! Jubelgeschrei

Und nu?

Ja nu benutzt man das einfach und freut sich des Lebens. Ein paar Hinweise aber noch:

  • Wird die VBA-Umgebung in einem Unternehmen genutzt, erhalten alle Benutzer ausschließlich Leserechte auf den zentralen startup-Ordner. Nur Entwickler und Admins dürfen dort schreiben um neue Versionen abzulegen. Eintwickler sollten niemals auf dem zentralen Pfad arbeiten, sondern woanders!
  • Der administrative Part mit den Pfaden und der Sicherheit sollte in Domänennetzwerken per GPO erledigt werden. Dafür braucht es die administrativen Office Templates (ADMX).
  • Wenn die Programmierung in Word geändert werden soll, dann muss die dotm per Rechtsklick -> Öffnen bearbeitet werden. Sonst hat man keinen Zugriff. Excel ist das egal.
  • Code sollte nicht direkt ausführbar sein, es sei denn er reagiert auf Events. Die Programme feuern den Code ab wenn sie starten und speziell Excel öffnet einfach alles im Ordner. Da sollte sonst nix liegen. Deshalb sind Word und Excel auch getrennt abgelegt.
  • Der startup-Pfad in Office kann nur gesetzt aber nicht entfernt werden. Soll der weg, dann entweder einen leeren Ordner sonstwo nehmen ooooder in der Registry löschen: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Word\Options wobei 16.0 die Version ist und der Eintrag STARTUP-PATH heißt.
  • Outlook ist ne blöde Diva und hat keinen startup-Pfad den man setzen könnte. Vielmehr muss man die VBA-Datei ersetzen und alle Makros aktivieren. Ein klasse Idee seitens Microsoft, ich würde auch aus anderen Gründen dringend davon abraten.

Ähnliche Beiträge