[AccessD] Bang and Dot operator in Runtimes.

JWColby jwcolby at colbyconsulting.com
Wed Aug 23 22:03:58 CDT 2006


Wow!

John W. Colby
Colby Consulting
www.ColbyConsulting.com

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Ken Ismert
Sent: Wednesday, August 23, 2006 3:17 PM
To: accessd at databaseadvisors.com
Subject: Re: [AccessD] Bang and Dot operator in Runtimes.


(Resending... sorry about the delay... sorting out my AccessD email
settings)

Ahh, the old "Dot vs. Bang" chestnut. I gotta weigh in, and respond to
certain points John, A.D., Susan, Erwin and Dan brought up:

First, thanks A.D. for your code demonstrating the interchangability of .
and ! 
in common situations.

The Me reference
----------------
Me is just the default internal reference to the object. In the case of a
Form or Report, there is a hidden declaration header in the class module
that makes all your controls available as properties of the class. So,
within the Form class module,
  Me.txtDate
is as valid as:
  Me!txtDate
which is just as valid as:
  txtDate
So, John, if you are getting an error in your runtime, it is not because of
'bad' syntax. It is either an error in the interpreter, or an earlier error
manifesting itself at that line of code.

Default Properties and Collections
----------------------------------
The classes we commonly work with in Access make heavy use of two time
saving
shortcuts: Default Properties and Default Collections.
The default property is one that is exposed when an assignment is made using
an object with no qualifying property:
  txtDate = #1/1/2006#
  varDate = txtDate
In each instance, the default property Value is being implicitly referenced.
So, the above code is exactly the same as:
  txtDate.Value = #1/1/2006#
  varDate = txtDate.Value
Dan has to explicitly specify lblName.Caption in his example, because the
Label object has no default property.

More importantly for our discussion, Access classes also expose default
collections. So the following code is equivalent:
  rForm("txtDate")  ' rForm is a Form object
  rForm.Controls("txtDate")
  rRS("RowID")  ' rRS is a Recordset object
  rRS.Fields("RowID")
You can easily see that a collection is the default member of the Form and
Recordset objects.

Comparing Dot and Bang
----------------------------------------------
What are the differences between Dot and Bang, really?

Dot:
* Can be used for early or late-bound references to object properties and
methods
* Cannot be used in queries (conflicts with SQL Table.Field syntax)

Bang:
* Is resolved only at runtime, exactly like Collection("Element")
* Can only access members of collections
* Can be early or late-bound, depending on the parent of the collection

Try it: you just can't get Bang to access a non-collection property of an
object. But you can use Bang to access members of plain collections,
provided you name with with a non-numeric name.

So, a reference like:
  Forms!frmTest!txtDate
Can be read as:
  "In the Forms collection, get the "frmTest" element, then get the
"txtDate" 
element from frmTest's default collection. Finally, return the default
property value of object txtDate"
That compact syntax does a lot.

Binding and Efficiency
----------------------
When are Bang references early-bound? When the parent resolves to a specific
class. These references are early-bound (Intellisense works):
   Form_frmTest!txtDate
   Me!txtDate
   rRS!DateField
These references are late-bound:
   Forms!frmTest!txtDate
   Reports!rptTest!txtDate

You really can't compare Dot and Bang in terms of efficiency. Dot is for
members of objects, and Bang is for members of collections. The real
question is whether a Collection!Element reference is as efficient as
Collection("Element").

Susan is right that in common usage there is no noticeable difference in
performance between the two.

Use in Forms
------------
In form modules, Me!txtDate is more work, because you're accessing the
control through the Controls collection, rather than referencing the
property directly as you would with Me.txtDate or just txtDate.

Erwin's example is most intriguing: while Me!txtDate usually refers to a
control named "txtDate", if no such control exists, it will return the value
of a field named "txtDate". What is surprising is that Me!txtDate doesn't
return a DAO.Field object, as you might expect, but something called an
AccessField object.

Summary
-------
* Dot is useful for ordinary object property and method references
* Bang is useful as a shortcut for specifying elements of collections whose
members won't be known until runtime, or in situations where Dot won't work,
i.e. queries.

-Ken


--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com




More information about the AccessD mailing list