Bang Notation and Dot Notation in VBA

and MS-Access

While perusing an application that I'm documenting, I've run across some
examples of bang notation in accessing object properties/methods, etc. and in
other places they use dot notation for what seems like the same purpose.

up vote 11
down vote
favorite
3

Is there a difference or preference to using one or the other? Some simple

googling only reveals limited information on the subject with some people
actually using it in opposite cases. Perhaps there is a coding standards section
from MS somewhere that indicates the method of madness?
ms-access vba vb6 notation
asked May 27 '10 at 18:49
shareimprove this question
Nitrodist
772930
add a comment

2 Answers
active oldest votes
Despite the (formerly) accepted answer to this question, the bang is not in fact a
member or collection access operator. It does one simple and specific thing: The
bang operator provides late-bound access to the default member of an
object, by passing the literal name following the bang operator as a string
argument to that default member.

up vote 12
down vote
accepted

That's it. The object doesn't have to be a collection. It doesn't have to have a
method or property called Item. All it needs is a Property Get or Function
which can accept a string as the first argument.
For much more detail and proof, see my blog post discussing this: The Bang!
(Exclamation Operator) in VBA
shareimprove this answer

edited Apr 12 '13 at answered Apr 11 '13 at 21:14

21:50

Joshua Honig
6,32522042
+1 Nice one, Joshua. Your blog post is a very good distillation of knowledge
about the bang operator. I've had to find out this the hard way since the MS
1
documentation is so bad on this subject. I wish I had read all this 15 years
ago! Mark Bertenshaw Apr 12 '13 at 0:03
I don't work in VBA/MS Access any more so I can't really confirm your
findings... how sure are you? Do you want this to be the accepted answer?
Nitrodist Apr 12 '13 at 15:40
@Nitrodist I'm very sure. I work with VBA every day. My blog post
includes some proof-of-concept code as well. As to whether it should be the
accepted answer...only you can decide that :) Joshua Honig Apr 12 '13 at
16:34
@Nitrodist: I'm also very sure that Joshua is right. My answer makes the
same point without saying it as clearly ;-). See the footnote in my answer for
example. The first sentence in my answer really wasn't the best choice of
wording - I was stating a common use case but making it seem like I was
1
defining the bang operator's purpose/behavior, which wasn't intended. Still,
my answer only suggests that it invokes the object's default member, without
actually saying it, so this answer is definitely more to the point than mine
was. Mike Spross Apr 17 '13 at 21:35
I always wondered "how could an extension change the rules of the
language" when working with VB4. Johannes Kuhn Jan 4 '14 at 21:55
show 1 more comment

The bang operator (!) is shorthand for accessing members of a Collection or other
enumerable object, such as the Fields property of an ADODB.Recordset.
For example, you can create a Collection and add a few keyed items to it:
Dim coll As Collection
Set coll = New Collection
coll.Add "First Item", "Item1"

up vote coll.Add "Second Item", "Item2"

19
coll.Add "Third Item", "Item3"
down
vote
You can access an item in this collection by its key in three ways:
1. coll.Item("Item2")
This is the most explicit form.
2. coll("Item2")
This works because Item is the default method of the Collection class, so
you can omit it.
3. coll!Item2

This is short-hand for both of the above forms. At run-time, VB6 takes the text
after the bang and passes it as a parameter to the Item method.
People seem to make this more complicated than it should be, which is why it's hard
to find a straightforward explanation. Usually the complications or "reasons not to use
the bang operator" stem from a misunderstanding of how simple it actually is. When
someone has a problem with the bang operator, they tend to blame it instead of the
real cause of the problem they are having, which is often more subtle.
For example, some people recommend not using the bang operator to access controls
on a form. Thus, Me.txtPhone is preferred over Me!txtPhone. The "reason" this is
seen as bad is that Me.txtPhone will be checked at compile-time for correctness, but
Me!txtPhone won't.
In the first case, if you mistype the code as Me.txtFone and there is no control with
that name, your code won't compile. In the second case, if you wrote Me!txtFone,
you won't get a compile error. Instead, your code will blow up with a run-time error if
it reaches the line of code that used Me!txtFone.
The problem with the argument against the bang operator is that this problem has
nothing to do with the bang operator itself. It's behaving exactly the way it's supposed
to.
When you add a control to a form, VB automatically adds a property to your form
with the same name as the control you added. This property is part of the form's class,
so the compiler can check for typos at compile-time if you access controls using the
dot (".") operator (and you can access them using the dot operator precisely because
VB created a named control property for you).
Since Me!ControlName is actually short-hand for Me.Controls("ControlName")1, it
should not be suprising that you don't get any compile-time checks against mistyping
the control name.
Put another way, if the bang operator is "bad" and the dot operator is "good", then you
might think
Me.Controls("ControlName")

is better than
Me!ControlName

because the first version uses a dot, but in this case, the dot isn't any better at all, since
you are still accessing the control name via a parameter. It's only "better" when there
is an alternative way to write the code such that you will get compile-time checking.
This happens to be the case with controls due to VB creating properties for each
control for you, and this is why Me.ControlName is sometimes recommended over
Me!ControlName.

1. I had originally stated that the Controls property was the default property of

the Form class, but David pointed out in the comments that Controls isn't the
default property of Form. The actual default property returns a collection that
includes the contents of Me.Controls, which is why the bang short-hand still
works.
answered May 28 '10 at 2:17
shareimprove this answer

edited May 29 '10 at 5:09

Mike Spross
5,09532962
Me.Controls is not the default "property" of the form object. The default
collection for Me in a form or report is a union of the Controls and Fields
collections. In as standalone class module, there is no default collection.
Otherwise, and excellent answer that recapitulates an answer I posted a short
while ago that I'm too lazy to look up! David-W-Fenton May 29 '10 at 2:36
@David: Sorry about that, I was thinking VB6 when I posted my answer, where
the Form class doesn't have a Fields collection. I'll edit my answer to clarify.
But now that you mention it, technically Controls isn't the default proeperty of
Form in VB6 either: there is a hidden property called _Default that is listed as
the default member of the class. Not sure if it is a union of multiple collections
in VB6 or if it simply returns Controls. Good catch though. Now you've got me
wanting to solve this mystery :-) Mike Spross May 29 '10 at 4:22
And coll.Item("Item2") isn't always the full story either. In most contexts you
really mean coll.Item("Item2").Value, however in some places where an object
reference is acceptable the object's default property (.Value) won't be selected.
This can lead to hard to find errors, but it is rare. Note that this is not a failing of
the ! syntax itself however. Bob77 May 29 '10 at 9:20
@Bob: I considered adding that as another example where the bang operator is
sometimes incorrectly blamed. I've seen a few times where someone suggests
using rs.Fields("ColumnName").Value because rs!ColumnName "doesn't
always work", but as you point out, any problems are due to not being explicit
about using the Value property, in those situations where it does actually make a
difference. rs!ColumnName.Value would have just as easily solved the problem,
so just another case where the blame is misplaced, and the real issue is how and
when VB6 evaluates default properties. Mike Spross May 30 '10 at 1:36
I'm not sure if adding .Value will always work. Starting with A2000, there's been
a disconnect between the form/report and the underlying recordsource, and this
is reflected in the need to have a control with a controlsource for any field that
you refer to in code. That is, if MyField is in the recordsource, but there is no
control with it as ControlSource, referring to it in code is unreliable, not because
of . or ! or .Value, but because MS has mucked up the relationship between the
form/report and its Fields collection. David-W-Fenton May 30 '10 at 19:13