Bangs and Dots

  • Thread starter Thread starter Damien
  • Start date Start date
D

Damien

I nearly always use dots when working with forms and
controls

eg Me.cmdExit

but should I be working with Bangs instead ? Are they
faster ?

eg Me!cmdExit

I tend to use bangs for Recordset fields

eg rst!user_name

but what are the general rules for bangs and dots ?


Thanks


Damien
 
but what are the general rules for bangs and dots ?

Bangs are for separating objects from their collection,
e.g.,

Forms!frmDataInput!txtCustomerID

Periods are to separate an object from its properties or
methods, e.g.,

Me!txtCustomerID.Enabled = True

Although periods may work, bangs make your code easier to
read and avoid some backward compatibility issues.

HTH
Kevin Sprinkel
 
Hi Damien,

Bangs are marginally faster when used to refer to a control but unless you
have hundreds of control references I doubt that you'll see much impact on
performance.

Recordset fields can be referenced using either the bang or by using the
parentheses and quotes style of reference:

debug.print rst.fields("MyField")

Which is best? It tends to be a matter a preference so you'll have to decide
for yourself. I believe that Microsoft (and many developers) will advocate
that the bang style is more accurate. In practice, many developers use and
prefer the dot. I'm sure others will jump in to give their opinions :-) In
case they don't, just Goggle on "Bang vs Dot" and you'll get the idea.

Here's my standard newsgroup reply on this issue -

--------------------------------------------

Bang (!) is used to denote a member of a collection. Controls on a form are
members of the form's controls collection and thus we can reference a
control on a form by using the bang notation me!MyControl to refer to
MyControl on the form in which the code is executing.

Dot is used to refer to a property or method of a class (the form is a
class). Me.visible would refer to the Visible property of the form.

Where it gets confusing is that by default, Access creates a property for
every control on a form. This has the caveat of allowing the developer to
use the dot notation as another way of referencing a control on a form. So
you can refer to a control using me.MyControl

Underneath the covers, both types of control references are converted to the
fully qualified control reference via the form's controls collection -

So:

me!MyControl
me.MyControl

both get converted to

me.controls("MyControl")

What's the best notation to use? You'll have to decide for yourself but I'd
suggest you do the search on google and read what I and others have already
written. I prefer the Dot style notation primarily for two reasons - first
it makes my job easier because I can type in 'me.' and then select my
control name from the property list. Second and perhaps more importantly,
the compiler will catch invalid property references

me.CtlNotHere will not compile
me!CtlNotHere will compile but will create a runtime error

A few cautions if you are going to use dots instead of bangs
----------------------------------------------------------------------------
-
You can not avoid using the bang in a query parameter that references a
control on a form - you must use bang notation in queries.

For example - in the SQL for a query, this is the correct reference to the
cboCustid control on MyForm:

Select * from tblCustomers where Custid=forms!MyForm!cboCustid

Also, if your control or field has the same name as a property of the Form
object (e.g., a control named "Name"), then you must use the bang to refer
to the control or field, and dot to refer to the property. You should avoid
Access Keywords and common property names anyway but if you use them for
control names, be sure to use the bang instead of the dot to refer to the
control.

Also, if you're referring to a subform you can not take advantage of the
shortened reference to a subform control which allows you to omit the form
property.

For example you can not write:

Forms!MainForm.Subform1.ControlOnSubform

You have to write it as either

Forms!MainForm.Subform1!ControlOnSubform

or

Forms!MainForm.Subform1.Form.ControlOnSubform

For further reading on the topic (after your own Google search) Here's a
link to a good article on this subject by MVP Andy Baron:

"Cleaner Coding: Bang vs. Dot "
http://www.advisor.com/Articles.nsf/aid/BAROA06

The Access Developer's Handbook (2000 and probably 2002) (Litwin, Getz,
Gilbert) also has a good discussion on this issue.
 
Bangs are evil! ;o)

--
Paul Overway
Logico Solutions, LLC
www.logico-solutions.com


Sandra Daigle said:
Hi Damien,

Bangs are marginally faster when used to refer to a control but unless you
have hundreds of control references I doubt that you'll see much impact on
performance.

Recordset fields can be referenced using either the bang or by using the
parentheses and quotes style of reference:

debug.print rst.fields("MyField")

Which is best? It tends to be a matter a preference so you'll have to decide
for yourself. I believe that Microsoft (and many developers) will advocate
that the bang style is more accurate. In practice, many developers use and
prefer the dot. I'm sure others will jump in to give their opinions :-) In
case they don't, just Goggle on "Bang vs Dot" and you'll get the idea.

Here's my standard newsgroup reply on this issue -

--------------------------------------------

Bang (!) is used to denote a member of a collection. Controls on a form are
members of the form's controls collection and thus we can reference a
control on a form by using the bang notation me!MyControl to refer to
MyControl on the form in which the code is executing.

Dot is used to refer to a property or method of a class (the form is a
class). Me.visible would refer to the Visible property of the form.

Where it gets confusing is that by default, Access creates a property for
every control on a form. This has the caveat of allowing the developer to
use the dot notation as another way of referencing a control on a form. So
you can refer to a control using me.MyControl

Underneath the covers, both types of control references are converted to the
fully qualified control reference via the form's controls collection -

So:

me!MyControl
me.MyControl

both get converted to

me.controls("MyControl")

What's the best notation to use? You'll have to decide for yourself but I'd
suggest you do the search on google and read what I and others have already
written. I prefer the Dot style notation primarily for two reasons - first
it makes my job easier because I can type in 'me.' and then select my
control name from the property list. Second and perhaps more importantly,
the compiler will catch invalid property references

me.CtlNotHere will not compile
me!CtlNotHere will compile but will create a runtime error

A few cautions if you are going to use dots instead of bangs
-------------------------------------------------------------------------- --
-
You can not avoid using the bang in a query parameter that references a
control on a form - you must use bang notation in queries.

For example - in the SQL for a query, this is the correct reference to the
cboCustid control on MyForm:

Select * from tblCustomers where Custid=forms!MyForm!cboCustid

Also, if your control or field has the same name as a property of the Form
object (e.g., a control named "Name"), then you must use the bang to refer
to the control or field, and dot to refer to the property. You should avoid
Access Keywords and common property names anyway but if you use them for
control names, be sure to use the bang instead of the dot to refer to the
control.

Also, if you're referring to a subform you can not take advantage of the
shortened reference to a subform control which allows you to omit the form
property.

For example you can not write:

Forms!MainForm.Subform1.ControlOnSubform

You have to write it as either

Forms!MainForm.Subform1!ControlOnSubform

or

Forms!MainForm.Subform1.Form.ControlOnSubform

For further reading on the topic (after your own Google search) Here's a
link to a good article on this subject by MVP Andy Baron:

"Cleaner Coding: Bang vs. Dot "
http://www.advisor.com/Articles.nsf/aid/BAROA06

The Access Developer's Handbook (2000 and probably 2002) (Litwin, Getz,
Gilbert) also has a good discussion on this issue.

--
Sandra Daigle
[Microsoft Access MVP]
For the benefit of others please post all replies to this newsgroup.

I nearly always use dots when working with forms and
controls

eg Me.cmdExit

but should I be working with Bangs instead ? Are they
faster ?

eg Me!cmdExit

I tend to use bangs for Recordset fields

eg rst!user_name

but what are the general rules for bangs and dots ?


Thanks


Damien
Click to expand...
Click to expand...
 
Thank you for your discussion; this issue is more complex
than I was aware.

Kevin Sprinkel
 
Paul Overway said:
Bangs are evil! ;o)
Click to expand...
Dots what you think.

Bangs and dots are a lot like the problem with using reserved words as field
names.
You will get away with a field named Date often enough so that when you do
run into a problem with it, it will take a long time to find.
 
Paul, thank you for posting this link to Andy Baron's article.
He is always good value.

I particularly enjoyed this bit:
<quote>
When you refer to a field in the recordsource of a bound Access form as
Forms!FormName!FieldName, where FieldName isn't also the name of a control,
what collection is FieldName a member of? Darned if I know. Something
undocumented is going on behind the scenes.
</quote>

My personal preference is for the dot, because the compiler then reports an
error if the name changes. Anything that reduces bugs gets my vote.

However, there are rare cases where Access spits the dummy and refuses to
recognise Me.MyField unless there is also a control named "MyField". It's
weird: the same code that worked for years can suddenly stop compiling for
some unobvious reason. This is common enough that I have started using
Me!MyField whenever I am referring to a field that is not represented by a
control (e.g. a foreign key field in a subform does not need a control).
 
Allen:

I have found that Access not recognizing a field within a form or report
(and consequently refusing to compiling) is often some issue with the
underlying recordsource. I also see this problem occasionally, but if I
reselect the recordsource, the problem goes away.

I am also very diligent about naming controls with LNC prefixes...which
eliminates the opportunities for Access to become confused as to whether I
am referring to a control vs a field. There is a free Control Namer wizard
on my web site under Add-ins/Extras that I use for this purpose.
 
Back
Top