Kapselung von VBA Code

Betrifft: Kapselung von VBA Code
von: Frank S.
Geschrieben am: 25.09.2020 17:06:30
Hallo liebes Forum,
für unsere Firma habe ich inzwischen so 4-5 Tools auf Excelbasis (GUI) programmiert, welche sehr gut ALLEINE laufen. Trotz meiner Meinung nach guter und korrekter Referenzierung im Code, gibt es Probleme, sobald eine zweite Mappe mit VBA-Code geöffnet ist.
Habt ihr Tipps oder Tricks, um jede Mappe wasserdicht gegeneinander zu kapseln?
Ein Beispiel ist: Alle Tools haben ein Startblatt mit grafischen Elementen, denen dann über Rechtsklick ein bestimmtes Makro zugewiesen wurde. Also Start dieses und Start jenes. Die Makronamen sind nie doppelt. Trotzdem kommt es häufug vor, dass bei einer als zweites geöffneten Mappe angeblich der Code nicht verfügbar wäre oder nicht gefunden wird.
Auch presse ich zu Beginn oder direkt im Workbook.open Event jede Mappe in eine Variable um vorallem Schreibarbeit beim Referenzieren zu sparen (z.B. twb = Thisworkbook in Mappe 1 und ewb = Thisworkbook in Mappe 2).
Hilft nur leider nichts, wenn 2 Mappen offen sind.
Wäre über Antwort sehr dankbar,
Frank

Betrifft: AW: Kapselung von VBA Code
von: ralf_b
Geschrieben am: 25.09.2020 17:13:31
es sollte keine Probleme geben wenn du das so strikt durchgezogen hast. Aber das du schon erfahren bist, kannst du doch an den Fehlerstellen die Debuggerinfos zu Rate ziehen. Welches Workbook oder Fenster gerade aktiv ist und was Thisworkbook gerade beinhaltet.
Ich habe aktuell in ähnliches Problem wenn eine Mappe ausgeblendet ist und nur die UF sichtbar bleibt. Ist eine zweite Mappe offen passen auch die Referenzen von z.b. Worksheets() nicht mehr.

Betrifft: In solchen Fällen verwendet man auch nicht ...
von: Luc:?
Geschrieben am: 25.09.2020 20:30:51
…
ThisWorkbook, Frank & Ralf,
sondern
ActiveWorkbook, denn Ersteres ist stets der Mappe vorbehalten, die das jeweilige VBA-Projekt enthält (falls sie auch gemeint ist!). Außerdem ist es allemal besser, die
internen Namen der beteiligten
Workbooks und ggf auch ihrer
Sheets so zu ändern, dass sie eindeutig sind. (Die kann man dann auch statt der Mappen- und BlattBezeichner verwenden.)
Gruß, Luc :-?
„Die universelle Befähigung zur Unfähigkeit macht jede menschliche Leistung zu einem unglaublichen Wunder.“ Stapps ironisches Paradoxon
Nichtsdestotrotz Durchblick verbessern mit …

Betrifft: AW: In solchen Fällen verwendet man auch nicht ...
von: ralf_b
Geschrieben am: 25.09.2020 20:59:08
@Luc deshalb frage ich das zu Beginn ab ob Thisworkbook = Activeworkbook. Entsprechend wird aktiviert.
Bis jetzt klappt das so.

Betrifft: AW: In solchen Fällen verwendet man auch nicht ...
von: Frank_S
Geschrieben am: 25.09.2020 21:41:37
Hi Ralf,
wie genau sieht dein Code denn aus für, 'ob Thisworkbook = Activeworkbook ist'?

Betrifft: einfach ne if - then abfrage drum rum owt
von: ralf_b
Geschrieben am: 25.09.2020 23:09:35

Betrifft: AW: In solchen Fällen verwendet man auch nicht ...
von: Frank_S
Geschrieben am: 25.09.2020 21:39:56
Hallo Luc,
kannst du deine Tipps bitte noch etwas näher erläutern? Was meinst du z.B. mit interne Namen ändern?
Bei mit hat eigentlich jedes Blatt Blatt seinen individuellen Namen, auch wenn er sich nur leicht unterscheidet.
Und wenn ich ehrlich bin, weiß ich nie ganz genau, wann ich 'Thisworkbook' und wann ich 'Activeworkbook' nutzen muss. Es heißt, die Mappe mit dem Code sollte Thisworkbook sein. Aber alle meine Mappen haben Code/UFs/Module.
Gruß, Frank

Betrifft: Mit 'internen Namen' sind die 'CodeName's ...
von: Luc:?
Geschrieben am: 26.09.2020 16:15:54
…gemeint, Frank,
die auch in der VBE-Hilfe zu finden sind. Allerdings bezieht sich das dortige Bsp unter
Workbook.CodeName nur auf
Worksheets (Xl14/2010), gilt aber analog auch für
Workbooks (Dateien) und ebenso für ihre
VBAProjects. Zitat:
Der Wert, der im Fenster Eigenschaften in der Zelle rechts neben (Name) angezeigt wird, ist der Codename des ausgewählten Objekts. Sie können den Codenamen eines Objekts während der Entwurfszeit ändern, indem Sie diesen Wert ändern. Eine programmgesteuerte Änderung dieser Eigenschaft während der Ausführung des Programms ist nicht möglich.
Solche Änderungen (besonders zum
VBAProject) sind zwingend erforderlich, wenn man auf Prozeduren eines anderen
VBAProjects zurückgreifen will und deshalb einen Verweis auf dieses im ggw per VBE setzen muss. Die von xlVBA vorgegebenen
CodeNames sind nämlich nur Default-Namen, quasi als Platzhalter. Für einen Verweis wdn aber eindeutige Namen benötigt, weil es sonst zu unerlaubter Namensredundanz kommen würde.
Diese Namen sind auch echte Namens
Objekte und haben nichts mit Titeln/Bezeichnungen auf TabellenLaschen oder als PfadBestandteile zu tun. Einzige Gemeinsamkeit ist, dass sie gleiche physische Objekte wie Dateien (Mappen) und TabBlätter (ggf auch deren VBA-Projekte) bezeichnen.
Im Prinzip ist es ganz einfach,
ThisWorkbook meint immer das
Workbook, dessen VBA-Projekt den jeweils aktiven PgmCode enthält. Handelt es sich dabei um ein
AddIn (.xla~), das niemals
ActiveWorkbook sein kann (auch, wenn seine Pgmm gerade ausgeführt wdn), wird es selbst angesprochen, nicht das gerade aktive
Workbook. Genauso ist es bei normalen
Workbooks (.xls~). Wird durch eine Prozedur des einen
Workbooks ein anderes
Workbook aktiviert, bezieht sich
ThisWorkbook immer noch auf das
Workbook des Prozedur-Standorts, was bei Prozeduren in UFs idR auch so sein darf. Soll aber immer das aktive
Workbook angesprochen wdn, egal ob der PgmCode darin steht oder nicht, muss zwingend
ActiveWorkbook verwendet wdn. Eigentl sagen das ja schon diese Bezeichnungen, zumal
ThisWorkbook (dt
DieseArbeitsmappe) ja auch als Default-
CodeName für ein
Workbook verwendet wird.
IdR muss man also auch nicht
ThisWorkbook mit
ActiveWorkbook vgln, sondern einfach nur die richtige Ansprache verwenden. Es sei denn,
ThisWorkbook soll stets, aber in Abhängigkeit von seinem Aktivitätsstatus unterschiedlich behandelt wdn.
Luc :-?

Betrifft: AW: Mit 'internen Namen' sind die 'CodeName's ...
von: Frank S.
Geschrieben am: 28.09.2020 14:19:48
Hallo Luc,
vielen Dank für deine ausführliche Erklärung. Mal sehen, ob das in der Praxis immer so leicht durchschaubar ist.
Viele Grüße, Frank

Betrifft: Na, dann guten Durchblick! ;-) owT
von: Luc:?
Geschrieben am: 30.09.2020 19:23:21
:-?