bang(!) information

  • Thread starter Thread starter Jim Evans
  • Start date Start date
Jim Evans said:
Can someone point me to a source of information regarding the bang and
it's usage?
Click to expand...


Here's my standard write-up on the subject.

--------- BANG (!) vs. DOT (.) ----------
It's not so much a question of one or the other being "proper syntax", but
that they mean different things that nevertheless almost always give the
same result. As I understand it, the bang (!) notation specifically denotes
that what follows is a member of a collection. In the case of a reference
such as Forms!FormName!ControlName, "FormName" is a member of the Forms
collection, and ControlName is a member of that form's default collection,
the Controls collection. If you were writing code for the codfe module of
form "FormName", you could write "Me!ControlName".

The dot (.) notation denotes that what follows is a property or method of
the preceding object. That would logically make the bang notation "proper"
for reference to form controls, and the dot notation improper.

But wait. Wherever possible, Access makes the controls on a form and the
fields in its recordsource all available as properties of the form. It also
makes the fields of the recordsource available via the bang notation. I'm
not sure exactly how it does this; maybe if a name is not found in the
Controls collection it checks the Fields collection of the form's recordset
as a fallback position. So for most practical purposes Me!ControlName and
Me.ControlName evaluate to the same thing, and the timing tests I've seen
suggest that there is little to choose between them as far as execution
efficiency is concerned. I seem to recall that there is a very slight
difference, but I can't remember which way the advantage lies, and it's not
much. There's a coding-time advantage, however, to using the dot notation,
as it makes the "intellisense" dropdown lists available. That's a strong
argument for using the dot notation, in my book.

But wait again! I said above that Access makes the controls available as
properties "wherever possible". There are cases where it can't do that.
Specifically, it can't do it when there is already a property of the same
name as the control in question. For example, if your form "Form1" has a
control or a field foolishly named "Name", currently displaying the value
"John Doe", then executing this statement in the form's code module:

Debug.Print Me!Name, Me.Name

will print

John Doe Form1

in the Immediate Window. So you must be careful not to use any reserved
words or built-in properties as names for your controls, if you want to use
the dot notation to refer to them. But then, you should avoid doing that
anyway, as it tends in general to confuse poor Access.
 
Thanks, Dirk.

--
Thanks,
Jim Evans

Dirk Goldgar said:
Here's my standard write-up on the subject.

--------- BANG (!) vs. DOT (.) ----------
It's not so much a question of one or the other being "proper syntax", but
that they mean different things that nevertheless almost always give the
same result. As I understand it, the bang (!) notation specifically
denotes that what follows is a member of a collection. In the case of a
reference such as Forms!FormName!ControlName, "FormName" is a member of
the Forms collection, and ControlName is a member of that form's default
collection, the Controls collection. If you were writing code for the
codfe module of form "FormName", you could write "Me!ControlName".

The dot (.) notation denotes that what follows is a property or method of
the preceding object. That would logically make the bang notation
"proper" for reference to form controls, and the dot notation improper.

But wait. Wherever possible, Access makes the controls on a form and the
fields in its recordsource all available as properties of the form. It
also makes the fields of the recordsource available via the bang notation.
I'm not sure exactly how it does this; maybe if a name is not found in
the Controls collection it checks the Fields collection of the form's
recordset as a fallback position. So for most practical purposes
Me!ControlName and Me.ControlName evaluate to the same thing, and the
timing tests I've seen suggest that there is little to choose between them
as far as execution efficiency is concerned. I seem to recall that there
is a very slight difference, but I can't remember which way the advantage
lies, and it's not much. There's a coding-time advantage, however, to
using the dot notation, as it makes the "intellisense" dropdown lists
available. That's a strong argument for using the dot notation, in my
book.

But wait again! I said above that Access makes the controls available as
properties "wherever possible". There are cases where it can't do that.
Specifically, it can't do it when there is already a property of the same
name as the control in question. For example, if your form "Form1" has a
control or a field foolishly named "Name", currently displaying the value
"John Doe", then executing this statement in the form's code module:

Debug.Print Me!Name, Me.Name

will print

John Doe Form1

in the Immediate Window. So you must be careful not to use any reserved
words or built-in properties as names for your controls, if you want to
use the dot notation to refer to them. But then, you should avoid doing
that anyway, as it tends in general to confuse poor Access.

--
Dirk Goldgar, MS Access MVP
Access tips: www.datagnostics.com/tips.html

(please reply to the newsgroup)
Click to expand...
 
hi Dirk,

Dirk said:
Here's my standard write-up on the subject.
Click to expand...
There is something important to add when talking about controls:

The dot binds at compile time, so IntelliSense and a compile error if
the control does not exist.

The bang enumerates a collection at runtime, so no IntelliSense and a
runtime error if the control does not exist.

E.g. place a TextBox called txtInput and a button called cmdBang on a
empty, unboound form. Add the following code:

Private Sub cmdBang_Click()

MsgBox Nz(Me!txtInput.Value, "NULL")

End Sub

Run debug and comile. Execute it. Rename the control and recompile.
Execute it.


mfG
--> stefan <--
 
In addition to Dirk's and Stefan's information, I've found some situations
in which Access throws an error when it encounters

Me.SomeControlName

but the error condition disappears if I use

Me!SomeControlName

As for the Intellisense issue, I've learned that if I type

Me!So

and press <Ctrl><Spacebar>, the names of the controls starting with "So"
and their attached procedures are displayed, Intellisense-style.

Good luck!

Regards

Jeff Boyce
Microsoft Access MVP

--
Disclaimer: This author may have received products and services mentioned
in this post. Mention and/or description of a product or service herein
does not constitute endorsement thereof.

Any code or psuedocode included in this post is offered "as is", with no
guarantee as to suitability.

You can thank the FTC of the USA for making this disclaimer
possible/necessary.
 
Stefan Hoffmann said:
There is something important to add when talking about controls:

The dot binds at compile time, so IntelliSense and a compile error if the
control does not exist.

The bang enumerates a collection at runtime, so no IntelliSense and a
runtime error if the control does not exist.
Click to expand...

Hi, Stefan -

I did mention intellisense. I should revise my write-up to mention the
advantage of compile-time checking.

It's worth bearing in mind that dot doesn't always bind at compile time. It
only does it when it can. For example, the following statement may give a
compile-time error:

Debug.Print Me.ctlNotOnThisForm

.... while this statement will not:

Debug.Print Forms(Me.Name).ctlNotOnThisForm

When interpreting the latter statement, the compiler knows what the
properties of a form are (and provides intellisense for them after you type
the dot), but it doesn't know what controls or user-defined properties or
methods may be on the form, and it doesn't reject the nonexistent control
name.
 
Most helpful. I often type out all my code using the "." to take advantage
of the "intellisense" feature, then go back and change them to "!" wherever I
feel it's necessary. It does speed things up a bit.
 
Back
Top