Bang or dot (1 Viewer)

Djblois

Registered User.
Local time
Today, 06:10
Joined
Jan 26, 2009
Messages
598
Which is quicker and better to use? Bang (!) or dot (.) when referencing objects? Bang has the problem of no intellisense but is there other reasons to use it? Is there a speed difference between the two?
 

isladogs

MVP / VIP
Local time
Today, 13:10
Joined
Jan 14, 2017
Messages
18,186
There are many forum threads on this topic.
Rather than me reinvent the wheel, suggest you have a look at the similar threads listed below and try the forum search feature
 

Djblois

Registered User.
Local time
Today, 06:10
Joined
Jan 26, 2009
Messages
598
I will try; I tried a general google search which returned little.
 

Micron

AWF VIP
Local time
Today, 09:10
Joined
Oct 20, 2018
Messages
3,476
I will try; I tried a general google search which returned little.
Perhaps your search term was lacking something, because there's lots on the subject. However, the major difference is that ! provides late bound access to the default member of an object by passing the name that follows ! as an argument (string).

Consider a form for example. The default member of a form is the collection of controls. Thus Me!text255 is a late bound reference to text255. The compiler will not evaluate such references (because they are late bound) thus any spelling error of the name will not be caught until run time, generating a run time error. Plus as you noted, intellisense cannot work with ! which should now be obvious as to why.

The only time I'd use the ! is where it is required, and the only place I can think of is when referring to a recordset field using ! syntax as opposed to rs.Fields("fieldName")
 

arnelgp

..forever waiting... waiting for jellybean!
Local time
Today, 21:10
Joined
May 7, 2009
Messages
19,175
from what I read, the reference I cannot recall, you use dot (.) to access the natural property/method of an object.

bang (!) is used on those that you Add to the object.

example is when you first created a form in design view, it has already most of it's property, you use dot (.) on them.
then you add textbox and other controls, which are not originally a member of the form, you use bang (!) on them.

using bang and dot as impact on the app, but negligeable.
each one, bang and dot has their own "cabinet" pool (stack, whichever).
if you use dot on a textbox, it first searches the natural pool of the parent object if it is a member (which is not), when it cannot find it it then searches the other pool.
when you use bang on textbox, directly it will go to proper pool to search. in short it is a shortcut, telling the compiler not to look to any other place put directly look at another place.

so the general rule is whatever you add to the object, use bang. whaever you did not add use dot.
 

Djblois

Registered User.
Local time
Today, 06:10
Joined
Jan 26, 2009
Messages
598
Micron, since they will not be evaluated upon compile, does that mean they would also be slower?
 

theDBguy

I’m here to help
Staff member
Local time
Today, 06:10
Joined
Oct 29, 2018
Messages
21,358
Micron, since they will not be evaluated upon compile, does that mean they would also be slower?
I wonder how much speed do you think you would be gaining if that's the case?
 

Micron

AWF VIP
Local time
Today, 09:10
Joined
Oct 20, 2018
Messages
3,476
Micron, since they will not be evaluated upon compile, does that mean they would also be slower?
I'm not an expert on Access architecture but don't see why there'd be any performance issue. Even if there was, you would not notice the difference, I strongly suspect. When I write code, I frequently compile and can't imagine why I would risk misspelling an object name in a reference only to have it bomb out during use because I used ! over dot. Intellisense might be the best reason to use dot, but having my references compiled on demand is a close second.

With all due respect, that stuff about bang being for added things is just plain wrong.
 

MajP

You've got your good things, and you've got mine.
Local time
Today, 09:10
Joined
May 21, 2018
Messages
8,463
I have never seen anything that would suggest any difference in any real terms. Obviously Dot has more advantages with ability to use variable names and intellisense. Bang has only one advantage in that it is nice short hand. Bang does one thing. It causes the runtime to invoke the default member of an object and pass the name following the bang as a string argument. Thus
RS!FieldName is the same as RS.fields("FieldName") since fields is the default member of the recordset collection.

The dot is early-bound and the bang is late-bound, not sure what the impact is in pratical terms but that can cause problems with debugging.
me!name will compile and then error at runtime 'Not Desired
me.SomeMispelledControlname will not compile 'Desired
me!someMispelledControlName will compile 'Not Desired

They are not equivalent beyond that. The dot is the one and only way to access a named public member of an object (not through a collection).
 

isladogs

MVP / VIP
Local time
Today, 13:10
Joined
Jan 14, 2017
Messages
18,186
@djblois
Did you actually look in the similar threads for this topic - particularly this lengthy thread https://www.access-programmers.co.uk/forums/showthread.php?t=299717. It contain a lot of useful info before we all got side tracked.
The message from both this thread and the other is that for the vast majority of situations, it matters little which you use. Various posts have outlined the few cases where it makes any real difference
 

Pat Hartman

Super Moderator
Staff member
Local time
Today, 09:10
Joined
Feb 19, 2002
Messages
42,981
arnel is correct. The dot is used to separate properties or methods that are integral to Access and bang is used for objects that you create.

Forms!yourformname!yourcontrolname.property

Is just one example. There is an exception though and that is controls and fields in the bound recordset of a form or Report. Access adds these items to the form/report collection so they can be referenced using the dot and that will give you intellisense.

Me.cboSomeControlName.property = Me!cboSomeControlName.property except that the first expression is evaluated at design time and the second is evaluated at runtime. I have a strong preference for using dot whenever it is available to raise errors as soon as possible.

It would take a lot of code to cause speed differences. It is most important to use Me. or Me! to qualify every control and field name. Access will work out where unqualified names are defined but why make it? That does add overhead because Access has to search all loaded modules to find where each variable is defined and "Me" narrows that down immediately. I'm not sure what order the loaded modules are searched in but "Me" specifies the form/report class module where the code is actually located.
 

MajP

You've got your good things, and you've got mine.
Local time
Today, 09:10
Joined
May 21, 2018
Messages
8,463
bang is used for objects that you create
That is not a correct explanation. There are plenty of examples of objects that you create where bang cannot access them (the property is not the default method), and there are examples of objects that you did not create that are accessible through bang. The correct definition is what Micron and I provided earlier:
The bang operator causes the runtime to invoke the DEFAULT member of an object and pass the name following the bang as a string argument.
A great example is the database object which has tabledefs and querydefs. Tabledefs is the default property and querydefs is not.
Code:
Public Sub TestIt()
     Dim db As DAO.Database
     Set db = CurrentDb
    MsgBox db!tblPlayers.Name  'works because tabledefs is default member of database
     'MsgBox db!qryPlayers.Name 'does not work because querydefs is not default member.
    MsgBox db.QueryDefs!qryplayers.Name ‘works because item is default method of query defs
End Sub
You can call tabledef using bang because it is the default property. You cannot call querydefs with bang.
 
Last edited:

Pat Hartman

Super Moderator
Staff member
Local time
Today, 09:10
Joined
Feb 19, 2002
Messages
42,981
I don't take shortcuts with object references because you never know from version to version when some newbe at Access is going to change the code to enforce the rules. I'm sure if you've worked with Access long enough you've run into situations where working code fails when you change to a new version. It is almost always due to a shortcut in referencing an object.

Also, over the years, MS has changed the rules on ! vs . so it seems to currently be a free for all but it didn't used to be.
 

MajP

You've got your good things, and you've got mine.
Local time
Today, 09:10
Joined
May 21, 2018
Messages
8,463
There is one exception I know to the rules, and that is the field object of a form or report. To demo, add a field to a form/report and then change the name of the bound control different from the field name. I have never read any reason why this works, and I know of no similar example in any MS product. The default property of a form/report is the Controls collection. So the following works based on the rule.
MsgBox Me!txtSomeField.name 'default property of form/report
However, this also works for some reason.
MsgBox Me!SomeField.name
What is stranger about this is that there is not even a fields collection exposed by a form or report.
 

Pat Hartman

Super Moderator
Staff member
Local time
Today, 09:10
Joined
Feb 19, 2002
Messages
42,981
I think I mentioned earlier that Forms and reports add controls and the fields of the form's RecordSource to its fields collection. That gives you intellisense and you will see different sets of properties for the field and the control whenever they have different names.
Me.SomeField
Me.txtSomeField

Since I always name my controls with names different from the bound field, My code is always clear as to whether it is referring to the control or the field.

An example would be.
Me.ChangeDT = Now()
would not show the updated value in Me.txtChangeDT until AFTER the record is saved.
 

sonic8

AWF VIP
Local time
Today, 14:10
Joined
Oct 27, 2015
Messages
998
However, this also works for some reason.
MsgBox Me!SomeField.name
What is stranger about this is that there is not even a fields collection exposed by a form or report.
Whenever you change the recordsource of a form, Access will internally create an object of type AccessField for each field in the recordsource and add it to the Controls-Collection of the form. However, the Controls-Collection treats those special controls differently than controls created explicitly by the developer. They can be referenced by name only. They are not included in Controls.Count, cannot referred to by Index and are not returned by the iterator for the collection.

[Edit/PS]
I missed a detail. This:
MsgBox Me!SomeField.name
Does not work! The AccessField class only has a value property, not a name.
[/Edit]

Also, over the years, MS has changed the rules on ! vs . so it seems to currently be a free for all but it didn't used to be.
They did not really change the rules but refined and improved the mechanism described above. If I remember correctly, there was a time when that mechanism only worked when you changed the recordsource at design time but not at run time.

Furthermore, the above applies to forms only, not to reports. For reports the AccessField will only be created, when you explicitly add a control (bound to the field) to the report.
 
Last edited:

Users who are viewing this thread

Top Bottom