what's with the exclamation marks?

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi,

Apologies if this is a dumb question but I've been thrown in at the deep end
with Access/VBA and don't have a clear idea of the basics. Most of the code
I have written so far has referred to objects in the same form as the macro
so I've been using Me.object. I'm a bit confused how I should refer to
objects other forms - including when I need to use a '!' instead of a '.'.
I've had some success using forms.frmName.object an Form_frmName.Variable but
I'm not sure whether this is correct as it sonetimes doesn't work!

Tahnks,
Chris
 
exclamation marks refer to items in a collection.
dots refer to properties.

The rule of thumb is: If you named it, it follows
an exclamation mark. If Microsoft named it, it's
a property, an follows a dot.

The confusion you see with forms is because you
get a Code Object automatically built for every
form, and that Code Object has properties just
like an Code Object you write in VBA, and Access
adds a property to that object for every control
in the controls collection of the form.

You can use either the property or the member.
Using the property allows you to use intelsense,
and design-time error checking, but some people
think that using the member is less prone to
failure in Access 2000.

(david)
 
Thats good thanks. So how would I refer to a table item where there isn't a
control for it on the form? Is it possible to access this using
frmName!field?

Chris
 
Chris_h said:
Oh, where do the square brackets come in?!
Click to expand...

Names of objects that contain spaces or special characters must be surrounded
with the square brackets. Access will often throw them in automatically in
cases where they are technically not required.
 
The short answer: You can't refer to a table field from a form's module
unless the table field is bound to the form's control. If you don't want the
control to show, make its .visible property false.
Having done this, you can refer to the control from the form module by just
using its name, e.g [txtMy Field] or txtMyField.
From another module (the form has to be open, of course) try
Forms!MyForm![txtMy Field].value
The square brackets are necessary because of the space in the controlname.

The long answer has to do with unbound controls and functions such as
Dlookup. Used, for example to look up a field value in a table that is not
in the recordsource for your form.

HTH, UpRider
 
UpRider said:
The short answer: You can't refer to a table field from a form's
module unless the table field is bound to the form's control.
Click to expand...

This is not strictly true. You can, as a rule, refer to a field in the
form's recordsource without having a control on the form bound to it.
You can normally do this using either the bang (!) or the dot (.)
notation, because of the lengths that Access goes to to make it
possible. The exception to this is that you can't use the dot notation
if there is a built-in property or method of the form that has the same
name, because then the "dot" reference will be mapped to that property
or method.

In subform linkage, though, I believe that your Link Master Field must
be a control on the form, and I think it's also best of there's a
control on the subform bound to the Link Child Field. So for most
purposes, I agree that it's best to have a control on the form that is
bound to any field you want to manipulate.
 
Dirk Goldgar said:
This is not strictly true. You can, as a rule, refer to a field in the
form's recordsource without having a control on the form bound to it.
You can normally do this using either the bang (!) or the dot (.)
notation, because of the lengths that Access goes to to make it
possible. The exception to this is that you can't use the dot notation
if there is a built-in property or method of the form that has the same
name, because then the "dot" reference will be mapped to that property
or method.
Click to expand...

For REPORTS I have tried to do this (using bang notaion) wherein the field
is in the recordsource of the report, but not bound to any control on the
report. It seems not to work in this case.
 
User said:
For REPORTS I have tried to do this (using bang notaion) wherein the
field is in the recordsource of the report, but not bound to any
control on the report. It seems not to work in this case.
Click to expand...

Correct. It works for forms, but not for reports.
 
User said:
For REPORTS I have tried to do this (using bang notaion) wherein the
field is in the recordsource of the report, but not bound to any
control on the report. It seems not to work in this case.
Click to expand...

You're right. The behavior in reports is not the same as that in forms,
for some reason. For reports, there must be a control bound to the
field, though that control need not have the same name as the field.
With such a control on the report., you can still use either the bang or
the dot notation to refer to the field.
 
Dirk said:
You're right. The behavior in reports is not the same as that in forms,
for some reason. For reports, there must be a control bound to the
field, though that control need not have the same name as the field.
With such a control on the report., you can still use either the bang or
the dot notation to refer to the field.
Click to expand...


The reason is that in reports Access constructs its own
internal query that is only based on the report's record
source (plus such things as sorting, grouping and
aggregates). To optimize the query, only fields that are
bound to controls are included in that query's field list.
 
Back
Top