Discussion: Dot Versus Bang (Again)

[zmbd]

{Mod Comment - This was moved here as it developed into a discussion that was extra to what was required for the original question, which can be found at Is it Possible to Reference a SubForm in DoCmd.SearchFor Record?}

OK,
I guess....
Back from the deep dark recesses of my mind back to the 1997

IMHO they fixed this in the 2003 wherein the dot and bang appear to cover the same ground in that controls are now expressed as properties of the form unless a reserved word is used as a control or a bound field name and that name is used as a property of the form, i.e. "name," in which case you really have to use the bang to get the right return (YAR not to use reserved names and special characters and anything except alphanumerics and reserved words).

SO, if I remember right from my classes: dot = property, bang = member of collection.

So using that concept we build the generic reference:
Form!frmMainPar ent!sFrmSubForm .FORM!control_o r_recordfield_n ame

SO to move on to what I coded (still generic reference):
Form!frmMainPar ent!sFrmSubForm .FORM.Recordset .FindFirst [conditional string]
I think that in English I'm saying:
In the collection of "FORMS"
find the item "frmMainPar ent"
within the collections of "frmMainPar ent"
find the item "sFrmSubFor m"
that has a property "FORM"
that has a property "Recordset"
that has a property "FindFirst"
that requires a agument [conditional string] that acts on this described object.

Make me head hurt... I go watch pretty colours lab now...

[NeoPa]

I don't believe that is correct Z. Bang (!) is shorthand for various defaults generally. It only means Member of Collection when referring to an item in a collection and is shorthand for the fuller expression of how to reference a member in a collection. It is also shorthand for other defaults in various scenarios.

In the case of controls on a form within a subform, the full expression is SubformName.For m.ControlName. The shorthand expression, because .Form is the default item when referring to a subform control, is SubformName!Con trolName. That isn't what I was asking about, as I already know that fairly certainly (See the linked article for more examples).

What I was asking for was an explanation, within that understanding, of why the shorthand reference to the .Recordset object property doesn't appear to be valid.

[zmbd]

one thought on the dot-v-bang(http://blogs.msdn.com/b/frice/archiv.../18/75685.aspx

As for Form being the default property of the subform. I do not believe that you are correct... instead is it not the controls collection the default property of the form? http://msdn.microsoft.com/en-us/libr.../ff195841.aspx

Each Form object has a Controls collection, which contains all controls on the form. You can refer to a control on a form either by implicitly or explicitly referring to the Controls collection. Your code will be faster if you refer to the Controls collection implicitly.

Why the explict FORM for a Subform? Because we are refering to the FORM property of the subform CONTROL http://msdn.microsoft.com/en-us/libr.../ff194652.aspx

So we have SubformName.For m.controls!Cont rolName
or to use MSDN's: Forms!OrderForm .ctlSubForm.For m!Controls.NewD ata which is equivalent to Forms!OrderForm .ctlSubForm!New Data



Although I am sure the the bang has many other uses... how I understand it and the dot was explained to me by fairly knowledgeable person (he's about 20yrs my senior) is that, in general, if you use the "('x')" construct ie: (obj.item("name ")) then, usually only then, you can replace it with the bang (obj!x). Of course I've found exceptions to that rule and I expected to do so when he used the terms "usually" and occationally even he has mis-understood a thing or two.

[NeoPa]

Thanks for the links. I've studied many over the years - very few of which agree with others (Always the way). In this case, the fact that FRice seems unable, or unwilling, to differentiate between what is handled by the bang (!) and what is an effect of the default property of an object, leads me not to place too much weight on his understanding of the matter. In the case of Forms!MyForm!My TextBox, the bang does not tell it to use the default property of the form. That is inherent in the concept of the default property of the form itself (which is the Controls collection of course).

The second link interestingly states that :

1. Forms are members of the Forms() collection. Not too reliable as subforms are not.
2. Using the implicit version is faster than the explicit one. I've heard this before but would be very interested to understand why. Possibly simply related to the time taken to interpret the code itself.
3. You can use or bypass the .Form part of a subform reference, but not why.

Tantalisingly intersting points that are referred to, but not explained. And all this from MS.

You'll see much of what we've discussed included in my linked article about how to refer to subform items from post #16 (Referring to Items on a Sub-Form), and like your mentor, I have also been searching for a fuller understanding of Exactly what it means and where and when it's best to use each, even having a long discussion with Denburt about this some years ago. What I'm after is a full understanding of the issue, and knowing that it generally refers to collections, while perfectly true, is not something I'm satisfied by. I'll continue searching.

[zmbd]

Wherein you find "Tantalisin g" I find very annoying... one would think they'd either standardize the use, or get rid of one or the other.
Personally, form my sanity, I try to use the bang only when dealing the recordset level of the forms or an open recordset with VBA and use the dot elsewhere.

However, it looks like we've gone slightly off topic... maybe split this out with reference starting around post#22?

[NeoPa]

Z:
Wherein you find "Tantalisin g" I find very annoying... one would think they'd either standardize the use, or get rid of one or the other.

I certainly find it irritating that the situation is never explained clearly anywhere, such that even many very experienced Access developers are unaware of the full story. I feel more comfortable understanding and following the Rules, rather than simply bungling through in ways that can be got to work.