Subs im Makro-Menü Alt+F8 ausblenden

[d'r Bastler]

Moin allerseits,

damit Subs untereinander kommunizieren können, ob per Call (obsolet) oder Parameter darf man sie nicht als Private deklarieren. Dann sind sie (also die ohne Parameter) aber auch im Makro-Menü Alt+F8 sichtbar, was nicht unbedingt gewünscht ist. Folgender Trick hilft:

Option Private Module

nach dem obligatorischen

Option Explicit

in den ersten Zeilen eines Moduls und schon sind die Subs im Modul unsicht- aber ansprechbar.

Viel Spaß damit!

[xlKing]

Hi zusammen,

Option Private Module kann noch viel mehr als nur das Ausblenden aus dem Makromenü. Ich nutze es gern um zu vermeiden, dass im Modulkopf befindliche Globale Variablen von anderen Workbooks aus überschrieben werden können. Oder öffentliche Subs und Functions von einem anderen Projekt aus aufgerufen werden können. Diese sollen bei mir nur im aktuellen Projekt global sein. Damit entspricht diese Option in etwa dem Schlüsselwort Friend. Während das Schlüsselwort in Standardmodulen nicht funktioniert, klappt diese Alternative wunderbar und blendet das Modul sogar im Objektexplorer aus - sofern man sich in einem anderen Workbook befindet. Letztlich vermeidet das auch eventuelle Kompilierungsfehler, falls in zwei geöffneten VBA-Projekten eine Globale Variable gleichen Namens vorkommt. Außerdem vermeidet man so, dass eine für VBA bestimmte Public Function vielleicht als Worksheet-Function missbraucht wird und gar im Formel-Assistenten erscheint.

Merke: Globale Variablen, Konstanten und Funktionen, die nur im aktuellen Projekt gebrauch werden, gehören bei mir schon seit längerem in ein separates Modul vom Typ Option Private Module.

Gruß Mr. K.

[thowe]

Hallo Mr. K!

Danke für deinen - für mich, sehr - wertvollen Beitrag.
der das Motto hat: "write code for the joy of it". I love simple, elegant syntax to put amazing functionality at your/my fingertips...

Das mit Option Private Module kannte ich nicht.

Ich rufe, meiner Konvention folgend, beispielsweise - immer - so auf:

Code: Alles auswählen

'Call is obsolet, maybe depreciated
Call BOOTSRAP_MySystemSetting.GetDefaultParameter(param1 param2, [optionalParam1])

Meine Frage dazu:
Wenn ich derart Vorgehe, dann kann ich - doch - nicht eine globale Variable einer anderen Arbeitsmappe überschreiben, oder? Es sei denn, in der anderen Arbeitsmappe existiert auch ein Modul Namens BOOTSRAP_MySystemSetting mit der Prozedur GetDefaultParameter().

LG

[xlKing]

Hallo Thowe,

ich kann dich beruhigen. So leicht überschreibt man auch wieder nicht globale Variablen in anderen Arbeitsmappen. Das muss man schon bewusst wollen. Dazu muss zumindest ein Verweis auf das VBA-Project der anderen Mappe gesetzt werden. Oder die andere Mappe muss ein AddIn sein.

Außerdem darf die angesprochene Variable nur im anderen Projekt, nicht aber im eigenen vorhanden sein. sonst bevorzugt er immer die Public Variable im eigenen Projekt und lässt die andere in Frieden. Aber wenn es ganz dumm kommt und man hat eine Variable, die man nur mal eben als Variant verwendet, ohne sie zuvor zu deklarieren, kann es zu diesem Phänomen kommen, wenn die globale Variable gleichen Namens sich in einem verknüpften Workbook oder in einen AddIn befindet.

Gleiches gilt für deine Funktion. Wenn du zwei Module mit gleichem Namen in verschiedenen Mappen hast, bevorzugt er zuerst das eigene Modul und die eigene Funktion. Nur wenn im eigenen Projekt das Modul nicht exisitert greift er auf das entsprechende Modul im verknüpften Workbook zurück. Willst du hingegen immer das andere Modul ansprechen, auch wenn das eigene Projekt ein gleiches Modul hat, musst du den Namen des VBAProjekts davorschreiben: VBAProject2.Modul1.Hallo

Spiel einfach mal ein bisschen mit gleichen Namen in unterschiedlichen Projekten rum. Dann entfernst du bestimmte Namen und Module im eigenen Projekt wieder, lässt den Aufruf aber unangetastet und du wirst du sehen was ich meine.

Gruß Mr. K.