Autor: Peter Haserodt --- Aus Excel VBA - Gruppe:
TutorialsModule und VBAProject
Autor: Peter Haserodt - Erstellt: -- - Letzte Revision: --
Wasser oder wasser nicht sagt
Stellen wir uns einen Haufen Wasser vor.
Nun, wenn wir Wasser kochen wollen, kommts in den Kochtopf
Wenn der Putzmann welches braucht, kommt es in den Putzeimer
Wenn Mr. Spül es benötigt - ab damit in die Spülschüssel
und so weiter ...
Dann haben wir noch irgendeinen Behälter für den allgemeinen Gebrauch - nennen wir ihn IrgendSchüssel
Auf jedenfall brauchen wir für unser kostbares Nass immer einen Behälter - Container, sonst zerinnt es uns wie Wasser in den Händen.
Genau so ist es mit Code. Er braucht immer einen Container.
Und genauso wie wir oben alle Behältisse erstmal als Wasserbehälter benennen können, haben wir auch ein Wort für die Code-Container, nämlich Modul - Module.
Code steht grundsätzlich in einem Modul und je nachdem für was ein Modul genutzt wird, erhält es noch eine Zusatzbezeichnung. Da gibt es das Klassenmodul für Userformen, das Klassenmodul für ein Tabellenblatt, das allgemeine Modul und und und ...
Und stören Sie sich nicht an dem geheimnisvollen Wort Klasse. Das hat nichts anderes zu sagen, als dass das Modul zu einem bestimmten Objekt gehört oder selbst ein Objekt ist.
Häh???
Unser Kochtopf ist ein Klassenbehälter - er gehört zum Herd
Unser Putzeimer ist ein Klassenbehälter - er gehört zum Putzmann
IrgendSchüssel ist kein Klassenbehälter, gehört zu nichts - alle können sich daraus bedienen.
Wichtig ist hier - wie immer - zu verstehen, dass dies nur Bezeichnungen sind und man vor Bezeichnungen keine Angst haben darf.
Und dass wir einfach Container benötigen, in denen wir unser Wasser- äh Code - aufbewahren können und zwar wenn nötig gebrauchsspezifisch.
Mehr dazu dann weiter unten - aber wir brauchen auch einen Container für unsere Container.
VBA Projekt - Container der Module
Bevor wir uns mit den einzelnen Modultypen beschäftigen, wollen wir auf das VBA Projekt eingehen.
Letztendlich ist ein Workbook in zwei Bereiche aufgeteilt:
Der Excel Teil: Alles was ich in der Excelanwendung anstelle
Der VBA Teil: Alles was ich per Code mache.
Für den VBA Teil habe ich in der Entwicklungsumgebung mein VBA Projekt, dieses besteht aus den einzelnen Modulen, die mir z.T. standardmäßig von Excel zur Verfügung gestellt werden (Tabellenblattmodule, Arbeitsblattmodul etc...) und solche die ich selbst hinzufügen kann (z.B. Userform)
Wichtig ist hierbei zu verstehen, das z.B. ein Tabellenblattmodul letztendlich nichts anderes ist als ein Userformmodul.
Es wird in dem Moment erzeugt, indem ich ein Tabellenblatt hinzufüge und gelöscht, indem Moment in welchem ich das Tabellenblatt lösche.
Zusammengefasst sind alle im VBA Project, welches sich rein optisch nur nochmals aufteilt.
|
|
VBAProject | | | | Microsoft Excel Objekte | | | | Diese Arbeitsmappe | | | Tabelle1 | | | Tabelle2 | | Formulare | | | | UserForm1 | | | UserForm2 | | Module | | | | Modul1 | | | Modul2 | | Klassenmodule | | | | Klasse1 | | | Klasse2 | |
|
Ein VBA Project gehört immer zur Arbeitsmappe.
Damit haben wir den übergeordneten Container: Die Arbeitsmappe.
Die Modultypen:
Eigenlich brauchen wir nur zwei Typen unterscheiden, Klassenmodul und allgemeines Modul.
Und alle Module die nicht unter der Rubrik Module stehen sind Klassenmodule, was immer dies auch bedeuten mag.
Vergessen wir für diesen Beitrag die Rubrik Klassenmodul, alleinstehende Klassenmodule. Diese werden in der Gruppe Klassenmodule in Online Excel gesondert behandelt.
Der Hauptunterschied zwischen allgemeinem Modul und den anderen ist die Zugehörigkeit zu einem Objekt !
Das Modul Userform1 gehört zum Objekt (Steuerelment, ActiveX ) Userform1 und ist das Klassenmodul der Userform1
Das Modul DieseArbeitsmappe gehört zum Objekt Arbeitsmappe und ist das Klassenmodul von DieserArbeitsmappe.
Dase Modul Tabellenblatt1 gehört zum Objekt Tabellenblatt1 und ist das Klassenmodul von Tabellenblatt1 (Wobei hier zu beachten ist, dass das Tabellenblatt anders heißen kann, hier gilt der CodeName des Tabellenblattes)
In diesen Modulen werden mir Ereignisse des Objektes oder Bestandteilen(Steuerelemente) des Objektes zur Verfügung gestellt!
Bevor die Profis sich jetzt beschweren:
YEP, man kann Ereignisse auch in Klassenmodulen der Rubrik Klassenmodul abfangen aber dies ist ein anderes Thema.
Beispiele:
-
DieseArbeitsmappe: z.B. Workbook_Open
-
Tabelle1: z.B. Worksheet_SelectionChange (Für das Tabellenblatt)
-
Userform1: z.B. UserForm_Initialize (Bezogen auf die Userform)
oder CommandButton1_Click (Für einen CommandButton auf der Userform mit dem Namen)
Weiterhin stehen mir die Objekte ohne Elternbezeichnung zur Verfügung!
Was bedeutet dies nun?
Wenn ich eine TextBox1 in einer Userform1 habe, kann ich einfach schreiben:
TextBox1.Text = "Hallo", wenn der Code sich im Modul der Userform befindet.
Wollte ich dies von anderer Seite ansprechen, müsste ich schreiben : Userform1.TextBox1.Text = "Hallo"
Das allgemeine Modul - der besondere Kick
In allgemeinen Modulen lagere ich Codes aus, die nicht Objektspezifisch sind, bzw. gegebenenfalls dem gesamten VBA Projekt zur Verfügung stehen sollen.
Weiterhin dienen sie dazu, wiederverwenbaren Code zu kapseln.
(Nehmen wir an, Sie schreiben Prozeduren, die Sie in vielen Projekten benötigen können. Diese werden Sie dann in ein Modul auslagern, welches Sie dann jederzeit in ein anderes Projekt exportieren können)
(Und auch hier sei angemerkt, bevor sich die Klassenfetischisten ereifern: Ja, programmiertechnisch ist eine Klasse für soetwas vorzuziehen aber seid ihr glücklich mit euren Klassen und lasst dem normalen Anwender seine allgemeinen Module)
Wichtig ist hier der Gedanke der Wiederverwendbarkeit, auch innerhalb eines Projektes.
Es gibt keinen Sinn, in allen möglichen Objektmodulen eine Funktion zu schreiben, die z.B. Hexzahlen erzeugt.
Solch eine Funktion wird man auslagern.
Weiterhin stehen in diesen allgemeinen Modulen auch die Userformaufrufe.
Eine weitere wichtige Möglichkeit ist hier, Variable Projektweit zur Verfügung zu stellen, indem ich diese im allgemeinen Modul als Public deklariere.
Hier will ich doch einen kleinen Hiweiskasten einbauen:
Vielen Super-Experten dreht sich der Magen um, wenn diese Public Variable hören oder öffentliche Funktionen oder ...
VB Dot Net will (wollte) damit auch weitgehend aufräumen aber wird dies wirklich geschehen?
Selbstverständlich kann man über Klassen, Parameter etc... dies vermeiden. Sicherlich ist dies im Sinne der reinen Programmierung auch der Liebling aller Theoretiker.
Ob es aber wirklich praxisnah ist, wage ich vehement zu bezweifeln.
Und nochmal zusammengefasst:
|
|
Diese Arbeitsmappe | | Tabelle1 | Codes, die sich auf das Objekt diese Arbeitsmappe beziehen. | | Codes, die sich auf das dazugehörige Tabellenblatt beziehen oder Ereignisse bzw. Steuerelemente des Objektes auswerten | | Modul1 | | | Projektcodes, die nicht Objektspezifisch sind | | UserForm1 | | | Codes, die sich auf die dazugehörige Userform beziehen oder Ereignisse bzw. Steuerelemente des Objektes auswerten | | | |
|
Weitere Artikel der Gruppe: Tutorials Aus Excel VBA
Nach oben