Go Premium for a chance to win a PS4. Enter to Win

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 2092
  • Last Modified:

When to dot . and when to bang !

OK dudes and dudettes, this one isn't really a question but a question of programming syntax.

In many questions, I've seen this:

Now, I always use Me!SomeControl as the syntax when referring to control objects. Why? Well, although you do get Intellisense when using the . operator, there are disadvantages to using it. The main disadvantage is confusion between controls and properties. The easiest example of this is if you create a textbox on a form called Name (although we all know better than to do that, right?). When you do this:
Me.Name returns the form's name
Me!Name returns the value in the textbox called Name.
(and your control should never be given the same name as the field, but that's a whole different matter).

I recall that the best method of referencing controls is actually Me("Name") since that is how Access tokenises the code anyway, so doing that requires no additional translation by the engine.

Thoughts, feelings, inputs, general abuse? Or other comments on Access programming style and syntax?
  • 5
  • 4
  • 4
  • +9
5 Solutions
well... I was always a . man for properties and ! when it came to controls... but I am starting to change a bit... mostly thanks to lazyness... in times when it doesn't really matter... I might easily forget what I called whatever control I was going for... in times like these, I regularly pull out the old . ...

Mike EghtebasDatabase and Application DeveloperCommented:
Once, one of the expers commented Me!txtName is supposed to be faster than Me.txtName.  I haven't verified it for myself.

Other than form controls, you know that in certain areas, DOTs and BANGs are not interchangable.  Like in rs.movenext or rs!CustName.

Rey Obrero (Capricorn1)Commented:
check this link
look for
How to Refer to Forms and Controls
Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

Rey Obrero (Capricorn1)Commented:
shanesuebsahakarnAuthor Commented:
Oh, I already know how to refer to controls - but there are many people on who post code using the . operator.

In addition, referencing forms using the Form_ syntax is a bad idea. This can lead to form corruption if you are not careful as it requires Access to create an instance of the form in order to retrieve the references. This is particularly the case in A2K and A2K2.
shanesuebsahakarnAuthor Commented:
Sorry, I should have been a little clearer. I'm not asking how to do this, but this is a general discussion question to provide information to the users of Access who post in this forum. Essentially, you should avoid using the . dot operator when referring to controls in all circumstances.
Generally, I prefer to use dots wherever possible.  There are pitfalls if you're sloppy though:

from Cap's first referred article:

>> An interesting sidelight to this syntactic structure is that you can have an object name that is the same as a property name, and use the appropriate syntax to refer to the desired item. Assume that you name a form control Filter, even though using reserved words as object names is not a good policy. The first syntax below would refer to the Filter control, while the second would refer to the form's Filter property:

Me!Filter ' Looks in the default collection (Controls) for the named control

Me.Filter ' Looks for a property with this name  <<

The bottom line follow what you have posted time and time again: don't use reserved words, collection names, property names, method names, etc as variable or object names.  Then you can safely use dots until the cows come home.  Suffice to say that recordset fields still require bang as per eghtebas above >>Like in rs.movenext or rs!CustName<<
im lazy and use the . as i love the intellisense.

Me.txtBox.Value 'I always use .Value too,  where as most ppl (i see here) just let it be cause it defaults to the value - thoughts on this (yes im stealing your Q points shane)??  

for rs is use rs(0) or rs("myField") for example, never realy used !


shanesuebsahakarnAuthor Commented:
Stealing my Q points? Nah, I posted this Q :-)

Personally, I never use .Value. It's uneeded and implicit in any case. It also, for the novice programmer, leads to confusion as in:
Me!MyComboBox.Column(0).Value   'This is incorrect and errors
I have, however, seen people using the .Text property instead, which is entirely unecessary. I can't, off the top of my head, think of a reason to *set* a control's value in this way (to retrieve it...maybe).

So far as rs(0), I personally use rs!, but that's as a matter of personal preference. Again though, I never use rs. for fieldnames, simply as a matter of preference. I don't use the rs(<number>) format - if I ever need to cycle through the fields, I'd use the For Each fld In rs.Fields...Next method.

I used the example of "Name" as the name of a control since many people make the mistake of using "Name" as a fieldname - and when you autocreate a form, the wizard names controls with the same name as the field.

I'd point one thing out though - many of the people who ask questions here are novice programmers who may make the mistake using reserved words or property names as field or control names - which will give them some very odd errors if they use the . operator.
for me the . is only for properties


with rs
me!textfield = !aValue
end with

me!aControl.visible = false

never use .value as well

works for me..

err..of course that's

try no .Value (or .toString / .Text) in .Net and you'll get used to it, you have to, so i guess i just got use to it, same goes for dots as opposed to bangs...maybe im teaching myself bad habbits...

>> Stealing my Q points? Nah, I posted this Q :-)

I was asking a Q within your Q... that's what i ment

Functionally, I don't see any difference between

s = Form1!myField
s = Form1!myField.Value
s = Form1.myField
s = Form1.myField.Value
s = Form_Form1.myField

(do all of these work and create the same result? They should, unless "myField" is a property).

In earlier versions, I tried to use the Form!Fieldname syntax when referring to a field of a form and the Form.Property syntax when referring to a property of the form. In the meantime, I've converted to .NET and I use form.whatever most of the time.

concerning the Form_... syntax: I like this because it gives me Intellisense support for references to other forms. In most cases, these forms need to be loaded anyway, so there's no harm in loading them a bit earlier. You mentioned several times that the Form_   syntax causes form corruption. What's the background of this statement? I've never experienced a problem with that, unless I use some fat OLE controls in a form which causes the form to break anyway sooner or later.

I would like to thank Shane for opening this question as it helps us to think of the bigger picture rather than just banging (pun intended) away at code.

Bang is for collections and dot is for properties and MS has made things that you think are collections (like controls) double as properties. My guess is that this was done only for intellisense. That being said ...   I sooooo like intellisense beause I like to spend my time writing code and getting results rather than fixing typos.

As to which is faster between accessing an item in a collection or a property ... that depends heavily on how it was coded under the hood and although I like to write tight code I doubt that referring to form controls is a process that take an appreciable amount of time and would never be noticed by a human being unless you were processing a bazillion iterations and then I would suggest that there is a opportuntity to modify the process.

In ADO (ADH tells us so) there is a conversion taking place when you use bang so you can get intellisense and less processing by using dot ....

rst.Fields("MyField").Value is faster than rst!MyField

again .. likely never noticable as the speed issues with recordsets is usually in connecting, opening and iterating records. If you are iterating records then I would suggest that there is an oppurtunity to write a SQL statement.

but if you really need speed obtaining a recordset field value use the hidden Collect property where you pass the field position .... rst.Collect(0)

Me.txtValue.Text is the uncommited value and is VERY necessary when you are capturing data type errors in the Form_Error event.

I digress ... you were speaking specifically about form controls ...


One of the things I strive for in my code is readability (I'll leave out my thoughts on commenting, indenting, variables, constants api declarations, headers, footers and error handling for now, maybe shane will open a question for each:-)

There is no doubt to what Me.Controls("txtField").Value is going to return but because I ALWAYS prefix my controls I know for certain that I can drop iterating the Controls collection shoot straight to Me.txtField.Value without any confusion between me or Access   ... I can't remember if the Controls collection is the default property of a form or if MS made it's items Public so we can talk directly to them but I think they are sitting straight up on the stack ripe for plucking because you can use simply txtField.

As for using .Value ... well ... I just simply like to :-)
OK ... different objects have different default properties or collections and although .Value is certainly the default property for a control object, I code with many different objects (don't we all) and usually type out the explicit property I want rather than accepting the default. Another reason to be as explicit as possible is that there is no such thing as a default anything in .NET.

Rey Obrero (Capricorn1)Commented:

Bang (!) versus Dot (.) versus Quotes ("")

The bang ("!") and dot (".") identifier operators help describe the relationships among collections, objects, and properties in an expression. They indicate that one part of an expression belongs to another.

In general, you follow the bang with the name of something you created: a form, report, or control. The bang also indicates that the item to follow is an element of a collection. You'll usually follow the dot with a property, collection, or method name. Actually, under the covers, the bang separator really says, "retrieve the following object from the default collection of the parent object." (See the section "Using Default Collections" later in this chapter.) For example, when working with forms, you can refer to a control on a form like this:

Set ctl = Forms("frmTest").Controls("txtName")

or, because Controls is the default collection of a form, you can abbreviate that as either of the following:

Set ctl = Forms("frmTest")("txtName")
Set ctl = Forms("frmTest")!txtName

You can also think of the uses of these operators this way: a bang (or parentheses and quotes) separates an object from the collection it's in (a field in a table, a form in the Forms collection, a control on a form), while a dot separates an object from a property, method, or collection of that object.

It turns out that, behind the scenes, the former style of dot-and-bang reference is translated to the latter style of parentheses-and-quotes reference when you execute such a statement. This means that, although using the bang operator will save you a bit of typing, you'll pay for it in a speed penalty. Our recommendation, and the style we've followed throughout this book, is to always use the parentheses and quotes format for referring to a member of a collection unless it's absolutely necessary to use the bang operator. In addition, if the object to which you're referring contains spaces (or other nonstandard characters), you'll have to treat these names specially when using the bang syntax—you'll need to surround the name in square brackets. If you use the parentheses/quotes syntax, all names are treated equally.


One place where the bang operator is necessary is in query parameters that refer to form fields. That is, you cannot avoid the Forms!FormName!ControlName syntax in this case.


It's a hard habit to break—we've been using "!" since Access 1. But the fact is, except in a very few places (query parameters is the one that comes to mind) you needn't ever use a bang and should probably think about weaning yourself from this syntax if you currently use it. It's important that you understand what it's doing and what it means when you see it, but we suggest you not use it in your VBA code.

Finally, one more reason to use "("")" rather than "!" in your code: when you use parentheses/quotes, you're using a string expression to identify an object. If you're using a string expression, you can just as easily use a string variable. Using this technique makes it possible to identify the object you want to work with at runtime, using a variable.

excerpt from

shanesuebsahakarnAuthor Commented:
> indenting

Now *there's* a topic worth discussing! Bad indentation makes me want to hit people with heavy, blunt objects.

A point on using .Text as the uncomitted value - I suppose I don't use it because of the way I code form validation. I tend to avoid table-level validation except for unique indexes so where I need it, I put in control-level validation but that's purely personal preference.

I also follow the general convention of prefixing controls, but for readibility purposes, I like the ! operator to clarify that I'm not referencing a public function on a form as well - that is, if I use:
it's immediately obvious to someone that I'm calling a function rather than referencing a control. A matter of style again, I think.

The Form_ causing corruption was a post by (I think) Albert Kallal on the comp.databases.msaccess newsgroup and I recall it was backed up by a couple of the other regular posters - I'll see if I can dig it up from Google groups.
Scott McDaniel (Microsoft Access MVP - EE MVE )Infotrakker SoftwareCommented:
My take is this:

Me!ControlName will "get" the control by way of Me.Controls("ControlName") ... the Controls collection is default on a form, therefore, that's the first place it looks.

Me.ControlName will "get" the control by way of the Properties collection (Me!Properties("ControlName").Value) of the form (which is NOT the default collection).

For example: If you have a control named "Name", and attempt to set a value in this control with Me.Name="bob" (say in the Open event) then you'll get the Property Is Readonly message ... however, if you use Me!Name="bob", the code works. This confirms that (a) the Dot "looks" at the properties collection first and (b) the Bang "looks" in the Controls collection first.

Therefore, you could say that the Bang syntax could be slightly faster. Does this matter with modern machines? Not really; the milliseconds (maybe??) you save by using the Bang are, IMO, far outweighed by the benefits of Intellisense. Does it matter with novice posters? To a point, I'd say it does. Different people using different styles to refer to the same thing is very confusing to the novice, but I don't see a solution to this. I'll say this; in all the applications I've reviewed over the past few years, the majority of them used the Dot syntax to refer to controls ... very few came in with Me!ControlName to refer to controls on a form or report.

In the end, there is really no difference between using either. You're receiving the same reference regardless of the method you use. One is not more "correct" than the other, and the feature benefits of one may(??) outweigh the performance benefits of another.

And I'd have to say you are probably correct ... Me("ControlName") is the fastest method, since Access doesn't have to interpret the Bang or Dot ... I have not data to back this up, it just makes sense that iterating the default collection (Controls) would be faster. FWIW, this opinon is gleaned from many, many readings of Newsgroup postings by TWKMTI (Those Who Know More Than I) in regards to this very issue (I've got a lot of spare time <g>).

For my use, I always code with the Dot when specifically referring to a control on a form or report, but use the ObjectCollectionName("ObjectName") when referring to a member of a collection in other areas:

etc etc

>>I have, however, seen people using the .Text property instead, which is entirely unecessary.
I don't entirely agree with this ... there are certainly times you need to know what the user typed (which is the .Text value) instead of the Value of the control ... of course, this issue mostly comes up in unbound applications, which are usually not a hot topic in the Access TA.

>> I'd point one thing out though - many of the people who ask questions here are novice programmers who may make the mistake using reserved words
>>  or property names as field or control names - which will give them some very odd errors if they use the . operator.

Agreed ... although I'd say that, especially to a novice programmer, the good outweighs the bad in terms of the Dot syntax ... with the Dot, the novice gets intellisense, and as we all know, it's easier when you're presented a list of options as opposed to having to memorize alll the properties/methods of an object. Again, urging new posters to adopt and use a Nameing Convention is the answer here.
I have tried to look for where i saw this but i cant find it.

! was apparently faster in 97, MS put time into speeding up the . and now (2000) its very comparible to the !, maybe faster now (not that you'd notice)???

Ill keep my eyes out to see if it see it again....

.Value -> Good "habit" to get into for VBA .Net..........?????????

As many others, I am using the . to refer to controls on my form out of laziness.  

I am using the .Value property however. This is required when you pass the control's value to an overloaded function (it can accept any type) because if you don't provide the .Value property, a reference to the control istself is passed instead of its value.  So I took the habit of using it every where.

To tell the truth, I have mixed feelings about default properties/collections.  Sure they make the coding easier but they can also make it a little harder to understand, debug and maintain.  I won't complain if default are not longer used.

As for the form_ references, I have been using it for many years without problems (that does not mean that there are none, absence of a thing is no proof of its inexistance...).  I like them not only for intelissence but also because early binding help coding a more robust application.  Furthermore, I am using custom events to pass information between my forms and this is only available when you use explicit form types.  Of course, variables cleanup is essential.
If I could go back to .Text for a moment ...

If your form is bound and the control is bound to a date field and the user types in a letter you only place you can catch this is in the Form_Error event, otherwise Access throws the "The value you entered for tblEmp.HireDate .... " error message which is not always helpful.

shanesuebsahakarnAuthor Commented:
This has been an interesting discussion so far - shall I leave it open for a little while longer?

I should probably say that .Text hasn't been necessary for me, but you're right, it is necessary under those circumstances. Most of the code I've seen using it posted here though has just been using it to retrieve a value (in the same way as .Value would have been used in the same circumstances).
Rey Obrero (Capricorn1)Commented:
There is always exception to the rule.
Scott McDaniel (Microsoft Access MVP - EE MVE )Infotrakker SoftwareCommented:
>> Most of the code I've seen using it posted here though has just been using it to retrieve a value (in the same way as .Value would have been used in the same >> circumstances).

Yes, this is very commonly mis-used ... especially by those coming from VB ...
In EE somewhere I read:

If you made it use a !
If Microsoft made it use a .

Featured Post

Free Tool: SSL Checker

Scans your site and returns information about your SSL implementation and certificate. Helpful for debugging and validating your SSL configuration.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

  • 5
  • 4
  • 4
  • +9
Tackle projects and never again get stuck behind a technical roadblock.
Join Now