[AccessD] Bang and Dot operator in Runtimes.

I guess there must have been some bogus stuff in my code that caused it to
break. 
Thanks for all the info! 

John

-----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