Exclamation Point in VBA for Access

J

Jim Evans

Can someone please explain the usage of ! in vba code dealing with Access.
How do you know if you should use the exclamation point or a dot (.)?

I have searched dozens of book indexes for this information and cannot find
one reference to !

A second question, please, what is the syntax to access a field on a
subform, from the main form, to perform a calculation on that field, a Sum
for example?

tia,

Jim Evans
 
J

Jeff Conrad

Hi Jim,

For your first question here is an excellent past post by MVP Dirk "Yoda" Goldgar on this subject:
The bang (!) notation specifically denotes that what follows is a
member of a collection. In the case of a form, it would denote a
member of the form object's default collection, the Controls
collection; in the case of a recordset, a member of the recordset's
Fields collection. The dot (.) notation denotes that what follows is
a property or method of the preceding object. So you can refer to
(form object).RecordSource, but not (form object)!RecordSource.

Most often when your question comes up, it has to do with which
operator to use in referring to the controls or properties of a Form
object. Logically, the bang notation would be "proper" to use in
referring to controls on a form, and the dot notation proper only for
referring to properties of the form.

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.
[/QUOTE][/QUOTE][/QUOTE]

For your second question see this link for help:

http://www.mvps.org/access/forms/frm0031.htm
 
R

Rick Brandt

Jim said:
Can someone please explain the usage of ! in vba code dealing with Access.
How do you know if you should use the exclamation point or a dot (.)?

I have searched dozens of book indexes for this information and cannot find
one reference to !

The ! is used when referring to a member of a the collection preceding
the !, so...

Forms!SomeForm

....refers to the form named SomeForm that is a member of the collection
Forms.

A dot (.) on the other hand is used to refer to a method or property of
the class preceding the dot, so...

SomeForm.Requery

....calls the Requery method of the class object that is SomeForm whereas...

SomeForm.RecordSource

....refers to the RecordSource property of the form named SomeForm.

Where there can be some confusion is when referring to fields or
controls in a form/report module. This is because there is a fields
collection and a controls collection (so you can use !), but Access also
exposes all fields and controls as properties of the form (so you can
also use .).

Many prefer the dot notation because it invokes code completion
automatically and mis-spellings are caught at compile time instead of at
runtime. Otherwise it is largely a matter of preference.
A second question, please, what is the syntax to access a field on a
subform, from the main form, to perform a calculation on that field, a Sum
for example?

Me.NameOfSubformControl.Form.FieldName
or
Me.NameOfSubformControl.Form!FieldName
 
J

Jim Evans

Dirk,

Thanks, good explanation for question 1!

Regarding question 2, I was viewing the page you reffed when your message
arrived. From the information on that page, I have formed the following
source:

=Sum(Me!fsubInvoices.Form!Total), but, all I get in the textbox is "#error".
What am I doing incorrectly?

Jim Evans

Jeff Conrad said:
Hi Jim,

For your first question here is an excellent past post by MVP Dirk "Yoda" Goldgar on this subject:

The bang (!) notation specifically denotes that what follows is a
member of a collection. In the case of a form, it would denote a
member of the form object's default collection, the Controls
collection; in the case of a recordset, a member of the recordset's
Fields collection. The dot (.) notation denotes that what follows is
a property or method of the preceding object. So you can refer to
(form object).RecordSource, but not (form object)!RecordSource.

Most often when your question comes up, it has to do with which
operator to use in referring to the controls or properties of a Form
object. Logically, the bang notation would be "proper" to use in
referring to controls on a form, and the dot notation proper only for
referring to properties of the form.

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.
[/QUOTE]

For your second question see this link for help:

http://www.mvps.org/access/forms/frm0031.htm

--
Jeff Conrad
Access Junkie
Bend, Oregon

Can someone please explain the usage of ! in vba code dealing with Access.
How do you know if you should use the exclamation point or a dot (.)?

I have searched dozens of book indexes for this information and cannot find
one reference to !

A second question, please, what is the syntax to access a field on a
subform, from the main form, to perform a calculation on that field, a Sum
for example?

tia,

Jim Evans
[/QUOTE]
 
J

Jim Evans

Thanks, Rick, Good and concise explanation.

Jim

Rick Brandt said:
The ! is used when referring to a member of a the collection preceding
the !, so...

Forms!SomeForm

...refers to the form named SomeForm that is a member of the collection
Forms.

A dot (.) on the other hand is used to refer to a method or property of
the class preceding the dot, so...

SomeForm.Requery

...calls the Requery method of the class object that is SomeForm whereas...

SomeForm.RecordSource

...refers to the RecordSource property of the form named SomeForm.

Where there can be some confusion is when referring to fields or
controls in a form/report module. This is because there is a fields
collection and a controls collection (so you can use !), but Access also
exposes all fields and controls as properties of the form (so you can
also use .).

Many prefer the dot notation because it invokes code completion
automatically and mis-spellings are caught at compile time instead of at
runtime. Otherwise it is largely a matter of preference.


Me.NameOfSubformControl.Form.FieldName
or
Me.NameOfSubformControl.Form!FieldName
 
R

Rick Brandt

Jim said:
Dirk,

Thanks, good explanation for question 1!

Regarding question 2, I was viewing the page you reffed when your message
arrived. From the information on that page, I have formed the following
source:

=Sum(Me!fsubInvoices.Form!Total), but, all I get in the textbox is "#error".
What am I doing incorrectly?

In a ControlSource expression you would not use the Me! reference. That
would only be used in VBA code. All you need is...

=Sum(fsubInvoices.Form!Total)
 
J

Jim Evans

Thanks, Rick!

Jim Evans

Rick Brandt said:
In a ControlSource expression you would not use the Me! reference. That
would only be used in VBA code. All you need is...

=Sum(fsubInvoices.Form!Total)
 
J

Jim Evans

In a ControlSource expression you would not use the Me! reference. That
would only be used in VBA code. All you need is...

=Sum(fsubInvoices.Form!Total)
Still no good... just "#error" in the control. There are two records
available in the subform for the first customer.

Jim Evans
 
J

Jeff Conrad

Just to add to Rick's post, I always like to add the Nz function so I always have zero for no
information.
Like so:

=Nz(Sum(fsubInvoices.Form!Total))
 
M

Marshall Barton

Jim said:
"#error".


Me!fsubInvoices.Form!Total is the correct reference to use
in the main form's VBA cade.

In a main form control source expression, you would drop the
Me! and just use fsubInvoices.Form!Total

However, the aggregate functions such as Sum on operate on
fields in the same form's record source table query (they
are unaware of controls on the form and certainly can not
get to a control on a subform).

You should use the Sum function in a text box in the
subform's header/footer. Then the main form can refer to
that text box to display the total.
 
R

Rick Brandt

Marshall said:
Me!fsubInvoices.Form!Total is the correct reference to use
in the main form's VBA cade.

In a main form control source expression, you would drop the
Me! and just use fsubInvoices.Form!Total

However, the aggregate functions such as Sum on operate on
fields in the same form's record source table query (they
are unaware of controls on the form and certainly can not
get to a control on a subform).

You should use the Sum function in a text box in the
subform's header/footer. Then the main form can refer to
that text box to display the total.

Yeah, I shouldn't have missed that. :(
 
J

Jim Evans

Don't worry about it, guys, it didn't help either. Finally gave up, created
2 sub queries, a main query from them and a subform from it. that worked.
What I was trying to do was calculate a current account balance by
calculating total invoices issued, less total payments received. The subform
does the job but, I thought the original attempt would be a cleaner way to
accomplish it...Oh, Well!!!

Jim Evans
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top