Wenn man mit VBA programmiert, kommt man nicht um das Referenzieren von Formularen und Steuerelementen herum. Dabei gibt es verschiedene Schreibweisen, verschiedene Ziele und auch noch verschiedene Ausgangspunkte. Bei den Schreibweisen scheiden sich die Geister, ob man Punkte oder Ausrufezeichen verwendet und wie detailliert oder kurz es sein soll. Die Ziele sind Formulare, Unterformulare und die darin enthaltenen Steuerelemente mit oder ohne Datenbindung. Und warum gibt es verschiedene Ausgangspunkte? Weil man einerseits vom Klassenmodul eines Formulars selbst auf die enthaltenen Steuerelemente zugreifen möchte, andererseits aber auch von Formularen auf die Elemente anderer Formulare oder auch von Prozeduren aus Standardmodulen. Wie all dies zusammenhängt und wie die Ausdrücke für die verschiedenen Konstellationen formuliert werden müssen, zeigen wir in diesem Beitrag.<\/b><\/p>\n
Beispieldatenbank<\/h2>\n
Als Beispiel verwenden wir eine Datenbank, die verschiedene Tabellen zum Speichern von Kunden, Projekten und Mitarbeitern enthält.<\/p>\n
Hier nutzen wir zunächst das Formular frmKundenUndProjekte <\/b>mit dem Unterformular sfmKundenUndProjekte<\/b>, wobei das Unterformular-Steuerelement zur besseren Unterscheidung sfm <\/b>genannt wurde (siehe Bild 1).<\/p>\n
![\"Formular](\"..\/fileadmin\/_temp_\/2025_01\/Snag_c7114d.png\")
<\/p>\n
Bild 1: Formular zum Anzeigen von Kunden und Projekten<\/span><\/b><\/p>\n Je nachdem, von wo aus wir auf Formulare, Unterformulare und Steuerelemente zugreifen wollen, können wir unterschiedliche Ausdrücke zum Referenzieren des jeweiligen Elements verwenden.<\/p>\n Dabei gibt es allgemeine Ausdrücke, die wir grundsätzlich von überall aus nutzen können, aber auch solche, die nur von speziellen Orten aus funktionieren.<\/p>\n Wenn wir also beispielsweise ein Steuerelement in einem Formular von einem Standardmodul aus oder von einem Klassenmodul eines anderen Moduls aus referenzieren wollen, werden wir üblicherweise die Forms<\/b>-Auflistung nutzen, darüber den Formularnamen angeben und schließlich über die Steuerelemente-Auflistung das Steuerelement referenzieren.<\/p>\n Einen solchen Ausdruck können wir beispielsweise auch vom Direktbereich aus nutzen. Dieser sieht wie folgt aus:<\/p>\n Wir nutzen also zunächst die Forms<\/b>-Auflistung, greifen über die Items<\/b>-Auflistung auf das Formular frmKundenUndProjekte <\/b>zu und über dessen Controls<\/b>-Auflistung auf das Steuerelement namens Vorname<\/b>.<\/p>\n Diesen Ausdruck können wir grundsätzlich von überall aus verwenden, denn er ist absolut und nicht relativ. Einen relativen Ausdruck könnten wir innerhalb des Klassenmoduls des Formulars platzieren.<\/p>\n Innerhalb des Klassenmoduls können wir auf das Formular mit dem Schlüsselwort Me <\/b>zugreifen. Dabei ersetzen wir den Bezug zum Formular, nämlich Forms.Item(„frmKundenUndProjekte“) <\/b>durch Me<\/b>. Der Rest bleibt gleich:<\/p>\n Ähnlich verhält es sich, wenn wir auf ein Element im Unterformular zugreifen wollen. Um die Bezeichnung des aktuell markierten Projekts zu ermitteln, können wir von überall aus diesen Ausdruck verwenden:<\/p>\n Vom Hauptformular aus kürzen wir den Ausdruck wie zuvor ab:<\/p>\n Vom Unterformular aus hingegen reicht dieser Ausdruck:<\/p>\n In den ersten Beispielen haben wir die jeweils längste Form des benötigten Ausdrucks verwendet. Es gäbe nur noch eine Steigerung, denn die Forms<\/b>-Auflistung ist eigentlich eine Eigenschaft der Application<\/b>-Klasse von Access. Das können wir wie folgt im Direktbereich herausfinden:<\/p>\n Es ist aber erst dann zwingend notwendig, einen Verweis auf das Application<\/b>-Objekt von Access anzugeben, wenn wir von einer anderen Anwendung aus eine Access-Instanz fernsteuern wollen.<\/p>\n Wir schauen uns nun die möglichen Kurzformen an und beginnen mit dem ersten Ausdruck, diesmal ohne Debug.Print<\/b>:<\/p>\n Hier können wir als Erstes auf die Value<\/b>-Eigenschaft verzichten. Value <\/b>ist nämlich die Standardeigenschaft des Textbox<\/b>-Steuerelements und vieler weiterer Steuerelemente. Das heißt, wenn wir keine Eigenschaft angeben, wird in der Regel Value <\/b>als Eigenschaft verwendet.<\/p>\n Warum „in der Regel“? Weil es auch hier eine Ausnahme gibt. Wenn wir nämlich wie folgt eine Objektvariable des Typs TextBox<\/b> definieren und das Textfeld zuweisen, wird logischerweise nicht der Inhalt der Standardeigenschaft zugewiesen, sondern ein Verweis auf das TextBox<\/b>-Element.<\/p>\n Wenn wir jedoch eine Operation durchführen wie Debug.Print <\/b>oder den Wert einer String<\/b>-Variablen zuweisen, dann liefert der Ausdruck den Wert der Standardeigenschaft.<\/p>\n Woher wissen wir das? Dazu öffnen wir den Objektkatalog des VBA-Editors, suchen nach TextBox<\/b>, wählen das Ergebnis aus und suchen unter Elemente von “TextBox“<\/b> nach einem Element mit einem abweichenden Icon. Dieses sieht wie in Bild 2 aus.<\/p>\n Bild 2: Standardeigenschaft einer Klasse im Objektkatalog<\/span><\/b><\/p>\n Damit landen wir bei der ersten Verkürzung, denn den Wert unseres Textfeldes können wir nun auch wie folgt ausgeben:<\/p>\n Und auf der gleichen Basis können wir noch zwei weitere Verkürzungen vornehmen. Genau wie Value <\/b>für das TextBox<\/b>-Element ist Item <\/b>die Standardeigenschaft sowohl der Forms<\/b>– als auch der Controls<\/b>-Auflistung. Auch davon kann man sich im Objektkatalog überzeugen.<\/p>\n Damit landen wir direkt bei einer sehr viel kürzeren Version des vorherigen Ausdrucks:<\/p>\n Dieser Ausdruck ist bereits wesentlich übersichtlicher als die erste und die zweite Variante.<\/p>\n Doch es geht noch weiter. Mit Forms(„frmKundenUndProjekte“) <\/b>referenzieren wir nämlich ein Formular, also ein Element des Typs Form<\/b>.<\/p>\n Und welche Standardeigenschaft hat das Form<\/b>-Element? Richtig: die Controls<\/b>-Auflistung!<\/p>\n Damit können wir auch diese weglassen und erhalten diesen noch kürzeren Ausdruck:<\/p>\n Und es geht noch weiter, denn es gibt sogar noch eine Abkürzung für das Referenzieren des gewünschten Auflistungselements. Dabei lassen wir die öffnende und schließenden Klammern und Anführungszeichen weg. Stattdessen stellen wir ein Ausrufezeichen voran. Das machen wir der Übersicht halber in zwei Schritten, als Erstes für das Steuerelement:<\/p>\n Und schließlich können wir die gleiche Vereinfachung auch noch für das gewünschte Element der Forms<\/b>-Auflistung erledigen:<\/p>\n Damit wäre alles gut und schön. Wir hätten mit dem Ausrufezeichen ein eindeutiges Zeichen, um eine Abkürzung für Auflistungen zu schreiben. Allerdings können wir auch die folgenden Notationen nutzen, um den Inhalt des Feldes Vorname <\/b>auszugeben:<\/p>\n Allerdings funktioniert die Eingabe der Punkte nicht für IntelliSense. Der Grund ist ganz einfach: Die Forms<\/b>-Auflistung weiß während des Entwurfs nicht, welche Elemente sie beinhaltet. Und auch die Controls<\/b>-Auflistung weiß das nicht. Wie aber können wir dennoch unter bestimmten Umständen per IntelliSense auf Steuerelemente zugreifen? Das schauen wir uns im folgenden Abschnitt an.<\/p>\n Wie erwähnt, ist es manchmal möglich, über den Punkt per IntelliSense auf Steuerelemente zuzugreifen.<\/p>\n Das gelingt allerdings nur in den folgenden beiden Situationen. Die erste dürfte die weitaus bekanntere sein. Hier verwenden wir das Me<\/b>-Schlüsselwort gefolgt von dem Punkt. Dies liefert wie in Bild 3 beispielsweise die Steuerelemente KundeID <\/b>und Land<\/b>.<\/p>\n Bild 3: Steuerelemente als Eigenschaften<\/span><\/b><\/p>\n Lassen wir uns hier den Vornamen ausgeben, um beim bisherigen Beispiel zu bleiben, verwenden wir also den folgenden Ausdruck:<\/p>\n Auch hier funktioniert übrigens die Notation mit dem Ausrufezeichen:<\/p>\n Diese Ausdrücke sind übrigens wieder identisch mit den folgenden:<\/p>\n Bevor wir zu den Unterschieden zwischen der Punkt- und der Ausrufezeichen-Notation kommen, schauen wir uns noch den zweiten und weniger häufigen Fall an, bei dem wir über IntelliSense auf die Steuerelemente zugreifen.<\/p>\n Diese Methode unterscheidet sich vor allem dadurch, dass wir nicht nur vom Klassenmodul des jeweiligen Formulars per IntelliSense auf die Steuerelemente zugreifen können, sondern auch vom Direktbereich, von Standardmodulen oder von anderen Klassenmodulen aus.<\/p>\n Dazu müssen wir den Namen des Klassenmoduls des jeweiligen Formulars kennen. Dieser setzt sich aus der Zeichenkette Form_ <\/b>und dem Formularnamen zusammen. Im Falle des Formulars frmKundenUndProjekte <\/b>heißt das Klassenmodul folglich Form_frmKundenUndProjekte<\/b>.<\/p>\n Damit können wir sogar vom Direktbereich per IntelliSense auf die Steuerelemente zugreifen und beispielsweise ihren Inhalt ausgeben:<\/p>\n In Bild 4 sehen wir ein Beispiel dafür. Warum werden die Steuerelemente aber überhaupt per IntelliSense angezeigt?<\/p>\n Bild 4: Zugriff per IntelliSense auf ein Steuerelement<\/span><\/b><\/p>\n Der Grund ist: In dem Moment, wo wir einem Formular ein Steuerelement hinzufügen, wird die Formularklasse um dieses Element erweitert. Und damit erhält die Formularklasse eine Eigenschaft, die den gleichen Namen wie das Steuerelement trägt.<\/p>\n Das lässt sich einfach reproduzieren, indem man beispielsweise ein neues Steuerelement namens cmdTest <\/b>hinzufügt. Sobald man über die Eingabe von Me<\/b> oder Form_frmKundenUndProjekte <\/b>plus Eingabe des Punktes IntelliSense aktiviert, wird das neue Steuerelement dort aufgelistet.<\/p>\n Der Einsatz des Schlüsselwortes Me <\/b>wirkt sich immer nur auf das Klassenmodul aus, in dem es verwendet wird. Das ist logisch – wo sollte man es nutzen können? Letztlich ist es eine Abkürzung für Form_ <\/b>plus Formularname. Wir können auch innerhalb des Klassenmoduls eines Formulars zum Beispiel Form_frmKundenUndProjekte <\/b>nutzen. Das hat allerdings folgenden Nachteil: Wenn man einmal den Namen des Formulars ändert, läuft diese Referenz ins Leere und löst einen Fehler aus.<\/p>\n Außerhalb von Formularklassenmodulen können wir Me <\/b>logischerweise nicht einsetzen. Wenn wir hier per IntelliSense auf die Steuerelemente des Formulars zugreifen wollen, müssen wir also beispielsweise Form_frmKundenUndProjekte <\/b>referenzieren und können dann nach Eingabe des Punktes IntelliSense nutzen.<\/p>\n Es gibt allerdings einen entscheidenden Unterschied: Sowohl Me als auch Form_frmKundenUndProjekte <\/b>greifen auf eine Instanz der Klasse Form_frmKundenUndProjekte <\/b>zu. Dafür muss aber auch eine solche Klasse vorhanden sein! Davon können wir bei Verwendung von Me <\/b>ausgehen, denn Me <\/b>kann nur vom Klassenmodul selbst auf die Eigenschaften zugreifen. Wenn wir jedoch über Form_frmKundenUndProjekte <\/b>von außerhalb des Klassenmoduls auf seine Elemente zugreifen wollen, und es ist noch keine Instanz vorhanden, dann wird nun eine neue Instanz erstellt beziehungsweise das Formular geöffnet.<\/p>\n Damit haben wir nun zwei Methoden, um von außerhalb eines Formulars auf ein Formular zuzugreifen. Die erste verwendet die Forms<\/b>-Auflistung und kann so aussehen, wobei wir hier den Namen des Formulars mit der Name-Eigenschaft ausgeben:<\/p>\n Mit Form_ <\/b>sieht der Zugriff wie folgt aus:<\/p>\n Hier sehen wir einen weiteren Unterschied:<\/p>\n Beides kann zu unterwarteten Ergebnissen führen. Deshalb sollten wir vorher prüfen, ob das jeweilige Formular bereits geöffnet ist und erst dann auf die Inhalte zugreifen. Anderenfalls erhalten wir im besten Fall einen Fehler, wenn das Formular noch nicht geöffnet ist und wir über die Auflistung darauf zugreifen wollen.<\/p>\n Im schlechtesten Fall greifen wir über den Namen des Klassenmoduls des Formulars darauf zu und erstellen das Formular neu, obwohl dieses eigentlich gerade gar nicht geöffnet sein sollte.<\/p>\n Wie wir herausfinden, ob ein Formular gerade geöffnet ist, schauen wir uns im Beitrag Prüfen, ob ein Formular geöffnet ist <\/b>(www.access-im-unternehmen.de\/1537<\/b>) an.<\/p>\n Kurz gefasst: Bevor wir über den Namen des Klassenmoduls eines Formulars auf dieses zugreifen wollen, könnten wir in einer einfachen If…Then<\/b>-Bedingung und einer Hilfsfunktion prüfen, ob dieses überhaupt geöffnet ist:<\/p>\n Nur, wenn das Formulare geöffnet ist, sollten wir auch mit dem Klassennamen darauf zugreifen, weil wir es sonst neu erstellen.<\/p>\n Interessanterweise liefern der Zugriff über die Auflistung Forms als auch der über den Klassennamen beide ein Element des Typs der Formularklasse zurück – hier zunächst für die Forms<\/b>-Auflistung:<\/p>\n Wenn wir direkt auf das Klassenmodul zugreifen, erhalten wir das gleich Ergebnis:<\/p>\n Wenn wir die Auflistungen verwenden wollen, können wir wie folgt auf die Steuerelemente eines Unterformulars zugreifen – hier in der vereinfachten Form mit Ausrufezeichen:<\/p>\n Hier ist zu sehen, dass wir diesmal das Unterformular-Steuerelement namens sfm <\/b>als Steuerelement der Steuerelementliste des Hauptformulars nutzen. Um das darin enthaltene Formular zu referenzieren, verwenden wir die Form<\/b>-Eigenschaft. Dies liefert zwar einen Verweis auf das Klassenmodul, aber dennoch können wir nicht mit IntelliSense auf die enthaltenen Steuerelemente zugreifen.<\/p>\n Stattdessen müssen wir diese wieder erst nachschauen oder aus dem Gedächtnis eingeben.<\/p>\n Wenn wir auch für das Unterformular IntelliSense für den Zugriff auf die enthaltenen Steuerelemente nutzen wollen, müssen wir dieses zuerst mit einer Variablen referenzieren, die den Typ der Formularklasse hat:<\/p>\n Dann setzen wir einen Verweis auf das Form<\/b>-Element in dem in der Steuerelement-Auflistung enthaltene Unterformular-Steuerelement:<\/p>\n Danach können wir auch auf die Steuerelemente im Unterformular per IntelliSense zugreifen (siehe Bild 5).<\/p>\n Bild 5: IntelliSense für Unterformulare<\/span><\/b><\/p>\n Bisher haben wir die ganze Zeit mit gebundenen Steuerelementen gearbeitet, die genauso heißen, wie die Felder, an die sie gebunden sind. Das ist der Standard, wenn man die Felder nach dem Festlegen der Datensatzquelle aus der Feldliste in das Formular zieht. Access vergibt automatisch die Feldnamen als Namen für die Steuerelemente.<\/p>\n Aus unserer Sicht ist es wesentlich einfacher, Steuerelemente so umzubenennen, dass sie zwar noch den Namen des gebundenen Feldes enthalten, aber ein Präfix aufweisen, das dem Typ des Steuerelements entspricht. Die wichtigsten sind dabei:<\/p>\n Sie können natürlich auch andere Präfixe verwenden – wichtig ist, dass sie konsistent sind. Der Grund ist, dass bei Verwendung von IntelliSense natürlich auch alle Textfelder, Kombinationsfelder, Kontrollkästchen, Listenfelder und so weiter immer an der gleichen Stelle gefunden werden sollen.<\/p>\n Aber können wir eigentlich gezielt entweder auf das Steuerelement oder das gebundene Feld zugreifen, wenn beide den gleichen Namen haben?<\/p>\n Wenn wir beispielsweise den Typ des Textfeldes Vorname <\/b>ausgeben, erhalten wir folgendes Ergebnis:<\/p>\n Aber können wir überhaupt auf das Feld selbst zugreifen, statt auf das daran gebundene Steuerelement? Und welchen Objekttyp hat ein solches Feld in einem Formular eigentlich? Das finden wir heraus, indem wir das Steuerelement Vorname <\/b>einmal in txtVorname <\/b>umbenennen. Danach erhalten wir beim Zugriff auf das Element Vorname <\/b>den folgenden Datentyp:<\/p>\n Hier erhalten wir beispielsweise den Datentyp AccessField<\/b>. Was ist nun genau der Unterschied zwischen den beiden? Dieser ist riesig: Während die Steuerelementtypen TextBox<\/b>, ComboBox<\/b>, CheckBox<\/b>, ListBox <\/b>et cetera einige Eigenschaften aufweisen, mit denen sich alles programmieren lässt, was wir benötigen, weist der Datentyp AccessField <\/b>lediglich eine einzige Eigenschaft auf!<\/p>\n Schauen wir uns das einmal im Objektkatalog an, finden wir diesen Datentyp über die Suche zunächst einmal gar nicht (siehe Bild 6).<\/p>\n Bild 6: Der Datentyp AccessField existiert anscheinend gar nicht.<\/span><\/b><\/p>\n Der Grund ist, dass es sich hier um einen verborgenen Objekttyp handelt. Diesen decken wir auf, indem wir im Objektkatalog mit der rechten Maustaste das Kontextmenü öffnen und dort den Befehl Verborgene Elemente anzeigen <\/b>betätigen. Danach finden wir dort den Eintrag AccessField<\/b>. Markieren wir diesen und schauen uns die Liste der Elemente an, finden wir lediglich den Eintrag Value<\/b> (siehe Bild 7).<\/p>\n Bild 7: Der Datentyp taucht erst auf, wenn wir die verborgenen Elemente einblenden.<\/span><\/b><\/p>\n Warum müssen wir das überhaupt wissen? Das ist zum Beispiel dann wichtig, wenn Sie nicht gleich zu Beginn der Entwicklung Wert darauf legen, Präfixe für die Steuerelemente festzulegen und dies später nachholen wollen.<\/p>\n Wenn man nämlich bis dahin zum Beispiel die folgende Zeile verwendet, um den Standardwert des Steuerelements namens Vorname <\/b>zu ermitteln, gelingt dies zunächst problemlos:<\/p>\n Wenn wir nun den Namen des Steuerelements von Vorname zu txtVorname <\/b>ändern und diese Zeile erneut aufrufen, erhalten wir einen Fehler:<\/p>\n Die entsprechende Fehlermeldung ist in Bild 8 abgebildet.<\/p>\n Bild 8: Fehler beim Versuch, nicht vorhandene Eigenschaften eines AccessField-Elements zu lesen<\/span><\/b><\/p>\n Weiter oben sind wir mit der folgenden langen Form zum Referenzieren eines Steuerelements gestartet:<\/p>\n Nachdem wir gesehen haben, dass wir es auch so kurz schreiben können:<\/p>\n Oder dass wir auch direkt über Form_frmKundenUndProjekte <\/b>sogar mit IntelliSense auf die Steuerelemente zugreifen können.<\/p>\n Wieso sollten wir dann überhaupt die Variante mit der Auflistung mit Klammern und Anführungszeichen verwenden?<\/p>\n Der erste Grund ist, dass wir vielleicht nicht den Namen des Formulars oder Steuerelements angeben wollen, sondern diesen in einer Variablen gespeichert haben.<\/p>\n Wenn wir beispielsweise eine Variable wie die folgende deklarieren:<\/p>\n Und dann den Namen zuweisen:<\/p>\n Dann können wir diese Variable in der Anweisung zum Referenzieren des Formulars einbauen:<\/p>\n Warum sollte man das tun? Zum Beispiel, weil man in mehreren Anweisungen hintereinander auf das Formular zugreift und bei einer Änderung des Formularnamens die Änderung nur an einer Stelle in der Prozedur durchführen möchte.<\/p>\n Es gibt noch andere Anwendungsfälle, die wir nur über die Auflistungen lösen können. Wenn wir beispielsweise viele gleichartige Steuerelemente in einem Formular platzieren, beispielsweise um einen Kalender abzubilden, dann werden wir diese vermutlich mit Namen nach einem bestimmten Schema mit numerischen Anteilen versehen, zum Beispiel txt001<\/b>, txt002<\/b>, txt003 <\/b>und so weiter.<\/p>\n Wenn wir diese nun durchlaufen wollen, um ihre Eigenschaften entsprechend des darzustellenden Kalenders anzupassen, können wir die Controls<\/b>-Auflistung nutzen und dabei dynamisch zusammengesetzte Bezeichnungen nutzen:<\/p>\n Nach den vielen verschiedenen Beispielen für den Zugriff auf Formulare und die enthaltenen Unterformulare und Steuerelemente stellt sich nun noch die Frage, wann nun welche Option am sinnvollsten ist. Auch dazu gibt es ein paar Richtlinien, aber leider keine eindeutigen.<\/p>\n Ganz klar: Wenn Sie auf Elemente in dem Formular zugreifen wollen, in dessen Formularklassenmodul Sie gerade programmieren, dann verwenden wir immer das Schlüsselwort Me<\/b> für den Zugriff auf Elemente des aktuellen Formulars.<\/p>\n Aber referenzieren wir die Steuerelemente dann über den Punkt oder das Ausrufezeichen?<\/p>\n Ganz ehrlich: Bisher habe immer das Ausrufezeichen verwendet, einfach um benutzerdefinierte Elemente von Eigenschaften unterscheiden zu können. <\/p>\n Aber im Rahmen der Recherche zu diesem Beitrag ist deutlich geworden, dass dies Nachteile haben kann. Auch wenn sich diese Nachteile in meinem Programmieralltag sehr selten bemerkbar gemacht haben.<\/p>\n Der Nachteil entsteht, wenn man ein Steuerelement nachträglich umbenennt, das bereits anders heißt als das gebundene Feld (also zum Beispiel beim Feld Vorname<\/b>, das im Textfeld txtVorname <\/b>angezeigt wird). Wir schauen uns ein Beispiel an, bei dem wir die folgende Prozedur für die Schaltfläche cmdVornameAusgeben <\/b>hinterlegt haben:<\/p>\n Solange das Steuerelement txtVorname <\/b>heißt, liefern beide Zeilen das korrekte Ergebnis.<\/p>\n Wenn wir jedoch den Namen des Textfeldes im Formularentwurf auf txtFirstname <\/b>ändern, wird es interessant. Wir bekommen dann nämlich zwei unterschiedliche Fehler. Wir schauen uns erst einmal den ersten Fehler an. Dabei handelt es sich gleich um einen Kompilierfehler, der in der Zeile auftaucht, wo wir die Punktsyntax verwendet haben (siehe Bild 9). Warum ein Kompilierfehler? Weil wir hier über die Punktsyntax auf die Eigenschaft zugreifen und nicht auf ein Element einer Auflistung. Die Eigenschaft ist nicht vorhanden und deshalb kann die Prozedur nicht kompiliert werden.<\/p>\n Bild 9: Kompilierfehler<\/span><\/b><\/p>\n Auf diesen Fehler würden wir auch stoßen, wenn wir das VBA-Projekt mit Debuggen|Kompilieren von Datenbankname <\/b>kompilieren würden oder wenn wir versuchen würden, eine .accde<\/b>-Datei aus der Datenbank zu erstellen.<\/p>\n Wenn wir diesen Fehler behoben haben und die Prozedur erneut ausführen, sehen wir den nächsten Fehler bei der Zeile mit der Ausrufezeichen-Syntax. Hier handelt es sich allerdings um einen Laufzeitfehler (siehe Bild 10).<\/p>\n Bild 10: Laufzeitfehler<\/span><\/b><\/p>\n Warum ist es in diesem Fall nun sinnvoller, die Punkt-Syntax zu verwenden? Weil wir so bereits beim Kompilieren erkennen können, ob es noch Fehler durch falsch benannte Elemente gibt.<\/p>\n Wenn wir die Ausrufezeichen-Syntax verwendet hätten, wäre dieser Fehler erst beim Testen oder, noch schlimmer, bei Kunden aufgefallen.<\/p>\n Damit kommen wir zur Situation, dass wir nicht von innerhalb des gleichen Formularklassenmoduls aus programmieren. Auch hier sollte nun das Ziel sein, auf die Steuerelemente als Eigenschaften zuzugreifen, um eventuelle Probleme mit falsch benannten Referenzen direkt als Kompilierfehler zu erkennen.<\/p>\n Dies ist allerdings nur möglich, wenn wir bereits bei den Formularen nicht wie bei Form!frmKundenUndProjekte <\/b>die Auflistung verwenden, sondern direkt mit dem Klassennamen die Formularklasse referenzieren, also Form_frmKundenUndProjekte<\/b>.<\/p>\n Bei einem Ausdruck wie Form_frmKundenUndProjekte.txtVorname <\/b>können wir durch Kompilieren gleich zwei Fehlern vorbeugen – sowohl einem geänderten Formular- als auch einem geänderten Steuerelementnamen.<\/p>\n Wenn wir die Unterschiede schon so genau unter die Lupe nehmen, sollten wir auch noch einen Blick auf die Performance werfen.<\/p>\n Hier wollen wir die folgenden Funktionen untersuchen, in denen wir einerseits über die Klasseninstanz auf das Objekt zugreifen und andererseits über die Auflistung:<\/p>\n Bild 11 zeigt das Ergebnis. Die Variante mit der Objektinstanz ist zwischen 15% und 20% schneller als die andere Variante.<\/p>\nVerschiedene Ausgangspunkte<\/h2>\n
Debug.Print<\/span> Forms.Item(\"frmKundenUndProjekte\").Controls.Item(\"Vorname\").Value<\/pre>\nDebug.Print<\/span> Me.Controls.Item(\"Vorname\").Value<\/pre>\nDebug.Print<\/span> Forms.Item(\"frmKundenUndProjekte\").Controls(\"sfm\").Form.Controls(\"Projektbezeichnung\")<\/pre>\nDebug.Print<\/span> Me.Controls(\"sfm\").Form.Controls(\"Projektbezeichnung\").Value<\/pre>\nDebug.Print<\/span> Me.Controls(\"Projektbezeichnung\").Value<\/pre>\nLang und kurz<\/h2>\n
Debug.Print<\/span> TypeName(Forms.Parent)\r\nApplication<\/pre>\nForms.Item(\"frmKundenUndProjekte\").Controls.Item(\"Vorname\").Value<\/pre>\n
Die Standardeigenschaft einer Klasse<\/h2>\n
![\"Standardeigenschaft](\"..\/fileadmin\/_temp_\/2025_01\/Snag_db9fff.png\")
<\/p>\nForms.Item(\"frmKundenUndProjekte\").Controls.Item(\"Vorname\")<\/pre>\n
Item ist ebenfalls eine Standardeigenschaft<\/h2>\n
Debug.Print<\/span> Forms(\"frmKundenUndProjekte\").Controls(\"Vorname\")<\/pre>\nDebug.Print<\/span> Forms(\"frmKundenUndProjekte\")(\"Vorname\")<\/pre>\nDebug.Print<\/span> Forms(\"frmKundenUndProjekte\")!Vorname<\/pre>\nDebug.Print<\/span> Forms!frmKundenUndProjekte!Vorname<\/pre>\nDebug.Print<\/span> Forms.frmKundenUndProjekte.Vorname<\/pre>\nKlassen als Eigenschaften<\/h2>\n
![\"Steuerelemente](\"..\/fileadmin\/_temp_\/2025_01\/pic_1535_003.png\")
<\/p>\nDebug.Print<\/span> Me.Vorname<\/pre>\nDebug.Print<\/span> Me!Vorname<\/pre>\nDebug.Print<\/span> Me.Vorname.Value\r\nDebug.Print<\/span> Me.Controls(\"Vorname\").Value<\/pre>\nZugriff auf Steuerelemente als Eigenschaften von außerhalb des Klassenmoduls<\/h2>\n
![\"Zugriff](\"..\/fileadmin\/_temp_\/2025_01\/pic_1535_004.png\")
<\/p>\nEinsatz von Me vs. Name des Formularklassenmoduls<\/h2>\n
Forms!frmKundenUndProjekte vs. Form_frmKundenUndProjekte<\/h2>\n
Debug.Print<\/span> Forms!frmKundenUndProjekte.Name\r\nDebug.Print<\/span> Forms(\"frmKundenUndProjekte\").Name<\/pre>\nDebug.Print<\/span> Form_frmKundenUndProjekte.Name<\/pre>\n\n
If <\/span>IstFormularGeoeffnet(\"frmKundenUndProjekte\") = True<\/span> Then<\/span>\r\n Debug.Print<\/span> Form_frmKundenUndProjekte.Name\r\nElse<\/span>\r\n Debug.Print<\/span> \"Formular nicht geöffnet\"\r\nEnd If<\/span><\/pre>\n TypeName(Forms!frmKundenUndProjekte)\r\nForm_frmKundenUndProjekte<\/pre>\n
TypeName(Form_frmKundenUndProjekte)\r\nForm_frmKundenUndProjekte<\/pre>\n
IntelliSense für Steuerelemente bei Unterformularen<\/h2>\n
Debug.Print<\/span> Forms!frmKundenUndProjekte!sfm.Form!Projektbezeichnung<\/pre>\nDim <\/span>objSfmKundenUndProjekte As <\/span>Form_sfmKundenUndProjekte<\/pre>\nSet<\/span> objSfmKundenUndProjekte = Form_frmKundenUndProjekte.sfm.Form<\/pre>\n![\"IntelliSense](\"..\/fileadmin\/_temp_\/2025_01\/pic_1535_005.png\")
<\/p>\nSteuerelement oder Feld der Datensatzquelle?<\/h2>\n
\n
Debug.Print<\/span> TypeName(Forms!frmKundenUndProjekte!Vorname)\r\nText<\/span>Box<\/pre>\nDebug.Print<\/span> TypeName(Forms!frmkundenundprojekte!Vorname)\r\nAccessField<\/pre>\n![\"Der](\"..\/fileadmin\/_temp_\/2025_01\/pic_1535_006.png\")
<\/p>\n![\"Der](\"..\/fileadmin\/_temp_\/2025_01\/pic_1535_007.png\")
<\/p>\nDebug.Print<\/span> Forms!frmKundenUndProjekte!Vorname.DefaultValue<\/pre>\nDebug.Print<\/span> Forms!frmKundenUndProjekte!Vorname.DefaultValue<\/pre>\n![\"Fehler](\"..\/fileadmin\/_temp_\/2025_01\/Snag_af02ecd.png\")
<\/p>\nWozu eigentlich die ausführliche Form?<\/h2>\n
Debug.Print<\/span> Forms.Item(\"frmKundenUndProjekte\").Controls.Item(\"Vorname\").Value<\/pre>\nDebug.Print<\/span> Forms!frmKundenUndProjekte!Vorname<\/pre>\nDim <\/span>strFormularname As String<\/span><\/pre>\nstrFormularname = \"frmKundenUndProjekte\"<\/pre>\n
Debug.Print<\/span> Forms(strFormularname)!Vorname<\/pre>\nDim <\/span>lngControl As Long<\/span>\r\nFor lngControl = 1 To 42\r\n Me.Controls(\"txt\" & Format(lngControl, \"000\")).Value = lngControl\r\nNext<\/span> lngControl<\/pre>\nWas nun?<\/h2>\n
Me im eigenen Klassenmodul ist gesetzt<\/h2>\n
Punkt oder Ausrufezeichen?<\/h2>\n
Private Sub <\/span>cmdVornameAusgeben_Click()\r\n Debug.Print<\/span> Me!txtVorname\r\n Debug.Print<\/span> Me.txtVorname\r\nEnd Sub<\/span> <\/pre>\n![\"Kompilierfehler\"](\"..\/fileadmin\/_temp_\/2025_01\/pic_1535_008.png\")
<\/p>\n![\"Laufzeitfehler\"](\"..\/fileadmin\/_temp_\/2025_01\/pic_1535_009.png\")
<\/p>\nForms-Auflistung oder Formularklassenname?<\/h2>\n
Performancefrage<\/h2>\n
Public Function <\/span>Objekt()\r\n Dim <\/span>strVorname As String<\/span>\r\n strVorname = Form_frmKundenUndProjekte.txtFirstname\r\nEnd Function<\/span>\r\nPublic Function <\/span>Liste()\r\n Dim <\/span>strVorname As String<\/span>\r\n strVorname = Forms!frmKundenUndProjekte!txtFirstname\r\nEnd Function<\/span><\/pre>\n![\"Performancevergleich\"](\"..\/fileadmin\/_temp_\/2025_01\/pic_1535_010.png\")
<\/p>\n