ME. or ME!

[Galaxiom]

But controls of a form are properties of that form: Property Let and Property Get functions that return or take an object.

In the first instance the controls on a form are items in the Controls Collection. They are then exposed as properties of the form. This is quite similar to a private collection exposed as properties of a custom class in VBA using Property Let and Get. The difference is these workings in the Access Form Class are not visible.

Fields and collections are a special case (annoyingly so - they could be accessible by dots if MS had allowed it - as they can be in some cases).

In the case of the DAO 3.6 recordset object model, items in the field collection have not been exposed as properties so can only be referred to with the bang. As you say, maybe it would have been nice of Microsoft to do so. ChrisO's earlier post suggests it had been in DAO 2.5/3.5

However Collections of the Access Form Class object are exposed as a property. Otherwise Me.Controls("controlname") would not work. Maybe it is different in VB.

The best argument for sticking with dots whereever possible is they work with Intellisense and bangs don't. I think that is a bigger pity. It would be very useful if Intellisense showed objects when a bang was used.

 

[isladogs]

To make this easier to find in future, I've just made it a sticky thread.
Thanks to all who contributed their wisdom on the tooic

 

[MajP]

This has been answered many times but most of the explanations are incorrect, incomplete, or simply a consequence of the below. Bang does one thing only

It causes the runtime to invoke the default member of an object and pass the name following the bang as a string argument.

I can find many exceptions to other explanations posted in this thread, I know of no exception to this rule or not covered by this rule.

I have never seen anything that would suggest any difference in any real terms. Obviously Dot has more advantages with ability to use variable names and intellisense. Bang has only one advantage in that it is nice short hand. In certain "expressions" such as queries, calculated controls, and conditional format you have to use this form. Bang does one thing. It causes the runtime to invoke the default member of an object and pass the name following the bang as a string argument. Thus

RS!FieldName is the same as RS.fields("FieldName")
since fields is the default member of the recordset collection.

The dot is early-bound and the bang is late-bound, not sure what the impact is in practical terms but that can cause problems with debugging.

me!name will compile and then error at runtime 'Not Desired
me.SomeMispelledControlname will not compile 'Desired
me!someMispelledControlName will compile 'Not Desired

They are not equivalent beyond that. The dot is the one and only way to access a named public member (property, method) of an object not through a default collection. This also mean you cannot use bang when the default member is not a collection. The default member of a control is "value", but since it is not a collection you cannot do
Me.SomeControl!value

The one seemingly apparent exception is the fields on a form. The default member of a form is the controls collection and there is not even a fields collection. This was explained by Sonic8 in that the fields of the recordsource are added to the default controls collection as a pseudo control in a special way. They do not appear in the control count

 

[NauticalGent]

On a whim, I asked ChatGPT how MS came to name the keyword "Me". Whether this is accurate or not, I found it interesting:

The use of the keyword "Me" in Microsoft Access VBA (Visual Basic for Applications) and in other programming languages has its roots in object-oriented programming concepts.

In object-oriented programming (OOP), the "this" keyword is commonly used to refer to the current instance of a class. The idea is to have a reference to the object on which a method or property is being invoked. When Microsoft introduced VBA, they adopted the convention of using "Me" instead of "this" to represent the current instance of the form or report.

The choice of "Me" is likely a simplification and abbreviation of "this." The term "Me" is concise, easy to remember, and makes the code more readable. While it might seem arbitrary, the goal in programming language design is often to create syntax that is both intuitive and efficient for developers.

So, in the context of Microsoft Access VBA, "Me" is a shorthand way of referring to the current instance of the form or report, and it aligns with the broader usage of "this" in object-oriented programming.

 

[theDBguy]

On a whim, I asked ChatGPT how MS came to name the keyword "Me". Whether this is accurate or not, I found it interesting:

Do you remember exactly what was the question you asked ChatGPT? The answer seems to be focused on Access, so you probably asked about Access. I noticed that interesting point because I think Excel still uses "this" in its VBA code.

 

[NauticalGent]

I did, I assumed Access would be the only Office app that used Form instances.

 

[theDBguy]

I did, I assumed Access would be the only Office app that used Form instances.

Good point. Excel has UserForms; I wonder if it uses Me too.

 

[Galaxiom]

Good point. Excel has UserForms; I wonder if it uses Me too.

Excel User Forms use VBA which of course includes Me.

Do you remember exactly what was the question you asked ChatGPT? The answer seems to be focused on Access, so you probably asked about Access. I noticed that interesting point because I think Excel still uses "this" in its VBA code.

Excel uses ThisWorkbook but not 'This'.

 

[theDBguy]

Excel User Forms use VBA which of course includes Me.

Excel uses ThisWorkbook but not 'This'.

Ah, that's correct. I guess I remembered wrong. Thanks!