Office: (Office 2016) Control als Parameter an Prozedur übergeben

Kennt jemand die Ursache für nachfolgendes Verhalten bzw. wo liegt mein Fehler. Über die Klärung des Problems würde ich mich sehr freuen.

Gegeben
1. Steuerelement mit Namen Feld

2. Prozedur
Sub Test(Testfeld)
End Sub

3. Aufruf der Prozedur: Call Test(Me.Feld)

Die Intellisense-Liste für das Steuerelement Feld enthält z.B. den Eintrag Me.Feld.ControlType. Bei Verwendung des Control-Objektes als Referenz-Parameter der Prozedur Test wird innerhalb der Prozedur die Intellisense-Liste stark reduziert und enthält z.B. nicht mehr Testfeld.ControlType. Hier stellt sich mir die Frage, woran das liegt.

Es ist mir klar, dass das Problem durch Übergabe eines weiteren Parameters für ControlType möglich ist. Ein ähnliches Verhalten tritt auch beim Kopieren des Steuerelements auf
z.B. Set Feldkopie = Me.Feld

:)

 

Du must den Datentyp definieren in der Sub:

Sub Test(Testfeld As Control)

dann solltest du alle Feldeigenschaften durch die Intellisense bekommen

 

Und wenn "Feld" z.B. ein Textfeldsteuerelement ist, würde dir eine Variablendeklaration ala
Code:

direkt alle passenden Methoden und Ereignisse per Intellisense liefern.

Bei einer Deklaration als Control reduzieren sich die Intellisense-Einträge auf die für alle Steuerelemente gültigen.

 

Vielen Dank für Eure Antworten!
Ich meine, ohne Angabe des Datentyps wird die Referenz (ByRef) für den Parameter verwendet und warum stehen dann viele IntelliSense-Einträge nicht mehr zur Verfügung. Es wird doch Bezug auf die Quelle genommen. Für den Fall ByValue dürfte zusammen mit 'as Control' eine Kopie angelegt werden. Ich werde eure Vorschläge nochmal ausprobieren und melde mich dann sofort. Gruß Lateiner

 

Es werden nur die Eigenschaften und Methoden (egal ob das Argument als ByRef oder als ByVal übergeben wird) von VBA-Intellisense angezeigt, die der CoClass über ihr Default-Interface bekannt sind. Das kannst Du mit jedem TypeLib-Browser überprüfen. Wenn Du dann eine Eigenschaft verwendest, die das Interface nicht kennt, wird zuerst ein QueryInterface ausgeführt, damit die Methoden und Eigenschaften während der Laufzeit zur Verfügung stehen. Hier mal ein Beispielablauf: Code:

 

Hi nouba, vielen Dank für die ausführliche Antwort. Zunächst hast du mir TypeOf geliefert, was ich bisher nicht kannte und ich nun hervorragend verwenden kann. Verwundert bin ich über die zusätzlichen Angaben der Access-Einträge wie in ** Dim txt As Access.TextBox **. In normalen Modulen ist die Angabe sicher nicht erforderlich, möglicherweise in Schnittstellen, für die ich keine Erfahrung habe, schon gar nicht mit CoClass.

Ich kann nun in Bezug auch auf die vorangegangenen Antworten meine Frage genauer formulieren.

Was bringt die Angabe des Datentyps in Sub Test(c as Control), wenn bei Aufruf der Prozedur der Bezug auf eine Control-Variable sowieso hergestellt wird. Ohne Angabe As Control öffnet sich zwar keine Intellisense-Liste zur Variablen c, mit Angabe jedoch nur eine unvollständige, z.B. fehlt .ControlType. In allen Fällen funktioniert jedoch Debug.Print c.ControlType.

Gruß Lateiner

 

Das hat @Nouba eigentlich schon erklärt.
Du musst zwischen Laufzeit (wenn dein Code ausgeführt wird) und der Designzeit (wenn du den Code schreibst) unterscheiden.

Intellisense kann zu Designzeit nur die Methoden des jeweils deklarierten Typs darstellen. - Welche auch sonst.
Die Control-Klasse hat keine ControlType-Property, also wird diese auch nicht dargestellt. Die Methodenliste von Intellisense ist also nicht unvollständig. (Warum die Control-Klasse keine ControlType-Property hat, wäre allerdings eine berechtigte Frage, denn mir ist kein Control bekannt, dass die ControlType-Property nicht hat.)

Zur Laufzeit wird versucht die Property aufzurufen. Wenn die jeweilige Objektinstanz eine solche Methode hat, funktioniert das, wenn nicht kommt es zu einem Fehler.

Der grundsätzlichen Vorteil darin, den Typ einer Variable/eines Arguments zu definieren, besteht vor allem in größerer Klarheit des Codes. Erstmal für einen Menschen, der den Code liest, aber auch für den Compiler, der grobe Fehler im Code dadurch bereits feststellen kann und dich beim Kompilieren darauf aufmerksam macht. (In VBA ist dies leider etwas eingeschränkt, Objekt-Variablen werden nicht auf korrekte Typisierung überprüft.)

Beispiel:
Code:

Dieser Code kann nicht korrekt sein. - Mit der obigen Deklaration verweigert der Compiler mit einem "Type Mismatch" das Kompilieren. Du siehst sofort den Fehler.
Stände dort stattdessen deine Variant-Deklaration (Sub Test(Testfeld)), dann würde der Compiler das akzeptieren, denn es könnte ja vielleicht doch richtig sein. - Wenn aber dein Code innerhalb der Prozedur eine Control-Instanz erwartet, kommt es dort zwingend zu einem Laufzeitfehler. - Diese Fehler bemerkst du aber erst, wenn du den Code ausführst.

 

Hallo sonic8
Die Beschreibung für die sinnvolle Angabe von Parameter-Datentypen kann ich nachvollziehen. Bisher habe ich das so klar noch nie gelesen. Danke. Den Datentyp wie in deinem Beispiel habe ich bisher nur dann eingetragen, wenn der Aufruf mit einem konkreten Wert, als ohne Variable erfolgte. Ansonsten würde ja auch ein Fehler auftreten.

Der von mir festgestellte Unterschied der Intellisense-Listen im Test-Modus ist nach wie vor für mich nicht nachvollziehbar. Nachfolgende Ereignis-Prozedur mit dem Call zeigt die Testsituation. Vielleicht ist das auch ganz einfach zu verstehen. Über eine Erklärung würde ich mich freuen.
Gruß Lateiner

Code:

 

Du fragst, warum sich die von Intellisense angezeigten Methoden hier unterscheiden?
Weil sich "Feld" auf eine konkrete Steuerelementklasse bezieht, also vermutlich auf eine Textbox. Control ist eine gemeinsame Basisklasse aller Access Steuerelemente, die nur den kleinsten gemeinsamen Nenner der Methoden aller Steuerelementklassen implementiert.

Wenn du deine Prozedur als Sub Test (Testfeld as Textbox) deklarierst, sind die Intellisense-Listen für Me.Feld.? und Testfeld.? gleich.
Wenn du ausschließlich Textbox-Steuerelement in deiner Prozedur behandeln willst, würde ich auch empfehlen den Parameter explizit als Textbox zu deklarieren.

 

Hallo Lateiner,

hast Du Dir im VBA-Objektkatalog einmal die Eigenschaften und Methoden der Control-Klasse angesehen? Diese werden von Intellisense verwendet (wenn Du die vorborgenen Eigenschaften einblendest, kämen diese noch hinzu). So, VBA weiß nur, dass es sich um ein Control handelt und die Klasse fragt deshalb mittels QueryInterface (aber nur während der Laufzeit - das nennt man Late Binding), welche anderen Eigenschaften und Methoden in ihr stecken. Beim Identifizieren werden ihr danach sämtliche weitere Eigenschaften und Methoden zur Verfügung gestellt. Dabei wird dann auch die Standardeigenschaft festgestellt (hier Value - das gilt nicht für alle Controls), deren Wert ermittelt und ausgegeben.

Von Standardeigenschaften, das sind die, die man nicht ausschreiben muss, wird hier vielfach Gebrauch gemacht. Vollständig sieht die Kette so aus: Me.Controls.Item(Index oder Controlname).Value.

 

Hallo sonic8 und nouba, ganz ganz herzlichen Dank für eure ausführliche und nun für mich verständliche Darstellung des Sacherhalts. Im übrigen wird in meinen konkreten Prozeduren irgendein Steuerelement an Test übergeben und dann in Test auf ContolType geprüft.
Glückauf Lateiner

 

@Nouba: Hier mal am Rande ganz herzlichen Dank dafür, dass du hier TypeOf und QueryInterface im gleichen Zusammenhang erwähnt hast.
Ich suche nämlich seit langem latent eine Möglichkeit, um in VBA zu Prüfen ob eine Objektvariable ein bestimmtes Interface implementiert. - Und ich wie nach deinem Denkanstoss festgestellt habe, kann man auch genau das mit TypeOf überprüfen.
Bisher habe ich immer auf die auch von Dir erwähnte, etwas brachiale Methode
Code:

zurückgegriffen.