Control Object Reference (Me!)

[Denburt]

If you are in the VBA section of a form and want to refer to a control on that form then the quickest most efficient way of achieving a connection to this control would be the most direct Me!NewData.

(Copied from MS Access help file) also found here:
http://msdn2.microsoft .com/en-us/library/aa223099(office .11).aspx

' Implicitly refer to NewData control in Controls collection.
Me!NewData
		
' Use if control name contains space.
Me![New Data]
		
' Performance slightly slower.
Me("NewData")
		
' Refer to a control by its index in the controls collection.
Me(0)
		
' Refer to a NewData control by using the subform Controls collection.
Me.ctlSubForm.Controls!NewData
		
' Explicitly refer to the NewData control in the Controls collection.
Me.Controls!NewData
		
Me.Controls("NewData")
		
Me.Controls(0)

I know quite frequently I might need my field name to be dynamic so I do use the following in such circumstances:

Me(MyVariable)

There is a huge misconception that it is ok to reference a control object as Me.NewData there are many reasons not to use this style simply put it is wrong. In all my years I have yet to find a use for Me.MyControl. If you have one feel free to PM me.

If you use a period after Me then the program is looking for a property or method not an object although MS Access can be forgiving the one time it fails on you will probably be when you need it most (Murphy’s law).
Many people say that they do it that way because of the properties dropdown box, yeah when I was a noob I used the properties box but still went back and changed the period to the exclamation. Sometime later I found that after I type Me! I press Control and hold it then hit the space bar viola a dropdown I can use.

Remember that when you name your controls try to avoid anything that can be used by MS Access such as Date. Date is a function in MS Access so it is not wise to name a field that. I know I may here some arguments over the following however I have had issues with some of the following so I always recommend that people avoid spaces in field names and any odd characters such as underscores.

[NeoPa]

There is a huge misconception that it is ok to reference a control object as Me.NewData there are many reasons not to use this style simply put it is wrong. In all my years I have yet to find a use for Me.MyControl. If you have one feel free to PM me.

We've had this discussion before (Referencing Controls on a Form) and I never got an answer as to why an object property should be treated any differently from any other property. I still feel the correct way to reference any property on a form is to use the '.' rather than the '!' (Which, after all, simply indicates that a shortcut syntax is being used). If a control is a member of the defined class (Which it clearly is) then no shortcut is required. Until you can explain why this is not the case, I don't think you're in a position to say that the '.' is wrong, simply or otherwise.

[Denburt]

I do agree that the control is a property of the form however it is also an object in and of itself.

I could be mistaken but from everything I know Me! refers to an object and Me. refers to a property.

Do you set the focus to a property or to an object?
Do you change the height of a property or an object?

In closing I have spent a lot of time correcting inherited databases that used Me. and for whatever reason it failed or better yet hung up and gave a debug error. That is the only reason I took the bold stance I did when I stated that it was wrong even though I didn't provide documentation.

I feel like I wrote this much better the first time but by the time I was done I needed to relog in lol I forgot to copy it.

[NeoPa]

I can understand that last paragraph. That's happened to me so many times!
I'm starting to get where you're coming from with the object versus property stuff. I just couldn't follow what you meant by it before.
As far as I am aware though, a property can be a simple property (Integer; Boolean; String; etc) but it can also be any class (or object) defined as part of the holding class (or object). An object simply being an instance of a class.
My understanding of the '!' is that it is shorthand for another (more precise) way of referring to an item. For instance, Me.Controls("Ct rlName") can be shortened to Me.Controls!Ctr lName. The latter will actually be faster to execute as it can be early-bound by the compiler.
Don't get me wrong, I think you've done some good work here. I just didn't want anyone to think that this was a hard-and-fast fact. I still feel that it's open to a more definitive answer. I know why I think what I think (laid out here) but I'm not so sure Microsoft have followed my way of thinking (They'd be fools not to OBVIOUSLY), or even if they've followed one consistent way of thinking even.

[Denburt]

I'm starting to get where you're coming from with the object versus property stuff. I just couldn't follow what you meant by it before.

Good that makes me glad.

Don't get me wrong, I think you've done some good work here.

Thank you very much!

I just didn't want anyone to think that this was a hard-and-fast fact. I still feel that it's open to a more definitive answer. I know why I think what I think (laid out here) but I'm not so sure Microsoft have followed my way of thinking (They'd be fools not to OBVIOUSLY), or even if they've followed one consistent way of thinking even.

I completely agree, I have been looking for credible documentation on this topic for a long time now, I may just find it one day..... But until then :)

[Denburt]

I have been sending out emails in the hopes that I will find someone who has some documentation on this topic.

[LeRobert]

After trying to clarify this for myself since I came recently to Access from other programming languages I've come across an explanation. It is from the book Microsoft Office Access 2003 Inside Out by John L. Viescas.

Here is that part:

When to Use “!” and “.”

You’ve probably noticed that a complex, fully qualified name of an object or a property in Access or Visual Basic contains exclamation points (!) and periods (.) that separate the parts of the name.

Use an exclamation point preceding a name when the name refers to an object that is in the preceding object or collection of objects. A name following an exclamation point is generally the name of an object you created (such as a form or a table). Names following an exclamation point must be enclosed in brackets ([ ]) if they contain embedded blank spaces or a special character, such as an underscore (_). You must also enclose the name of an object you
created in brackets if the name is the same as an Access or SQL reserved word. For example, most objects have a Name property—if you name a control or field “Name,” you must use brackets when you reference your object.

To make this distinction clear, you might want to get into the habit of always enclosing in brackets names that follow an exclamation point, even though brackets are not required for names that don’t use blank spaces or special characters. Access automatically inserts brackets around names in property sheets, design grids, and action arguments.

Use a period preceding a name that refers to a collection name, a property name, or the name of a method that you can perform against the preceding object. (Names following a period should never contain blank spaces.) In other words, use a period when the following name is of the preceding name (as in the TableDefs collection of the Databases(0) object, the Count property of the TableDefs collection, or the MoveLast method of the DAO Recordset object).

This distinction is particularly important when referencing something that has the same name as the name of a property. For example, the reference

DBEngine.Worksp aces(0).Databas es(0).TableDefs (13).Name

refers to the name of the fourteenth TableDef object in the current database. In the Contacts .mdb database, if you use Debug.Print to display this reference, Visual Basic returns the value tblCompanyConta cts.
However, the reference

DBEngine.Worksp aces(0).Databas es(0).TableDefs (13)![Name]

refers to the contents of a field called Name (if one exists) in the fourteenth TableDef object in the current database. In the LawTrack Contacts database, this reference returns an error because there is no Name field in the tblCompanyConta cts table.

[FishVal]

I do agree that the control is a property of the form however it is also an object in and of itself.

I could be mistaken but from everything I know Me! refers to an object and Me. refers to a property.

Do you set the focus to a property or to an object?
Do you change the height of a property or an object?

Nice!

So the following expression is invalid for the same reasons.
MsgBox b * val(c)
Variable is multiplied by function and the result this goes to the screen. :-D

What concerns the use of Me.ControlName expression vs. Me![ControlName]:

• For each form Access creates its own class.
• Now somewhat speculative thing (I didn't check whether it is really so) - a default property for this class is one returning Form object, so Me![ControlName] appears to be shothand to Me.Form![ControlName]
• Default property of the Form class is Controls - so we have Me![ControlName] = Me.Form.Control s![ControlName]
• Default property of the Controls class is Item - Me![ControlName] = Me.Form.Control s.Item("Control Name")
• So its obvious that expression like Me![ControlName] actually calls a Controls collection Item method or property, which in its turn searches the collection and returns corresponding object
  

To the other hand expression like Me.ControlName calls the topmost class property, which in its turn returns an object of one particulary control. I'm not sure about the mechanism - whether it returns object directly or through Controls collection. In anyway it should be born in mind that using "Me." style expression is not worser and maybe even better than using "Me!" for static control referencing.

Best regards

[Denburt]

I would like to thank both of the preceding posters, especially for the reference to the book and the fine explanations.

[hunterpaw]

Much ado about nothing.

Here is a link that you might find interesting.

http://blogs.msdn.com/access/archive/2008/05/30/dot-or-bang.aspx

Here are some tests I ran using a timer. The only difference between the Bang Loops and the Dot Loops were the Bang and the Dot in the code. As you can see there is no practical difference in speed whether you use a Dot or a Bang.

Test 1:
Bang 1000 Loops Time = 360
Bang 1000 Loops Time = 360
Bang 1000 Loops Time = 343
Bang 1000 Loops Time = 360
Bang 1000 Loops Time = 360
Bang 1000 Loops Time = 375

Dot 1000 Loops Time = 391
Dot 1000 Loops Time = 359
Dot 1000 Loops Time = 360
Dot 1000 Loops Time = 391
Dot 1000 Loops Time = 375
Dot 1000 Loops Time = 375

Test 2:
Bang 10000 Loops Time = 531
Bang 10000 Loops Time = 563
Bang 10000 Loops Time = 547
Bang 10000 Loops Time = 547
Bang 10000 Loops Time = 531
Bang 10000 Loops Time = 546

Dot 10000 Loops Time = 547
Dot 10000 Loops Time = 563
Dot 10000 Loops Time = 547
Dot 10000 Loops Time = 547
Dot 10000 Loops Time = 547
Dot 10000 Loops Time = 547

Does it really matter which you use?

Patrick Wood