ME. or ME! (1 Viewer)
- Thread starter tucker61
- Start date
boblarson
Smeghead
- Local time
- Yesterday, 18:52
- Joined
- Jan 12, 2001
- Messages
- 32,059
If you do a search on "Bang vs. Dot" you will see several posts about this.
But the quick explanation is this:
Use Me. (dot) when you want to refer to controls, properties or methods of the form.
Use Me! (bang) when you want to refer to fields in the form's recordsource.
Now it is a little more complex than that but if you go by that simple rule you should be fine.
Sorry Bob but that is incorrect.
The bang precedes objects which includes controls and fields:
Forms!formname
Me!controlname
Me!subformcontrolname
Me.Recordset!fieldname
The dot precedes Properties and Methods:
Me!controlname.Value
Me!subformcontrolname.Form!controlname.Value
Me!subformcontrolname.Form.Recordset!fieldname.Value
However Intellisense only works with the dot so it is best to use it (almost) everywhere.
VBA will tolerate the use of a dot where there should be a bang:
Forms.formname.controlname.Value
Me.controlname
It won't tolerate a bang where there should be a dot:
Forms!subcontrolname!Form!controlname (does not work)
If controls were meant to be preceded by a dot, Me!controlname would not work. The control is an object, not a property. Bang is strict, dot is tolerated.
The presence of a control by the name will take precedence with either a dot or a bang. Either of these will get the control called "fieldname".
Me!fieldname
or
Me.fieldname
However if there is no control by the name either the dot or the bang will get the field from the recordset (the property defined by the Recordsource property string).
To refer to a field in a forms's recordset where there is a control by the same name it must be spelt out in full.
For the field use:
Me.Recordset!fieldname
BTW This expression is actually shorthand using defaults for:
Me.Form.Recordset!fieldname.Value
The only place I have seen the bang absolutely required is when using the default shorthand to the recordset field in a subform.
The default property of a subformcontrol is:
.Form.Recordset
Consequently a field in the recordset can be referenced with:
Me!fieldname
Me.fieldname does not work in this case.
I presume this is simply because the programmers who wrote the dot-tolerant compiler forgot about the subformcontrol's default property because it was a two level expression.
boblarson
Smeghead
- Local time
- Yesterday, 18:52
- Joined
- Jan 12, 2001
- Messages
- 32,059
I said that it was more complex than I was letting on, but if the OP follows my rule of thumb it will ALWAYS work for them. How do I know that? Because I follow my own advice.
Last edited:
boblarson
Smeghead
- Local time
- Yesterday, 18:52
- Joined
- Jan 12, 2001
- Messages
- 32,059
Oh, and the reason why I boiled it down like that is that it can be difficult to understand all of the intricate details of the bang vs. dot arguments. So, like I said in my first post:
But they can search for the posts (like I said) and get a clearer understanding.
So my information is not incorrect, but only filtered for simplicity.
boblarson said:
So, as you will see, I made reference to the fact that what I was saying was not the complete story. I only boiled it down to an easy way to help someone who might be newer at using Access remember and be able to put it into practice. They will eventually come to know the entire thing but why confuse the hell out of them to begin with? Some concepts are such that if you go into the lengthy explanation and all of the exceptions, it loses people and they haven't learned anything.boblarson said:
But they can search for the posts (like I said) and get a clearer understanding.
So my information is not incorrect, but only filtered for simplicity.
I don't believe my explanation to be confusing. It is accurate and begins with the fundamental truth. Bangs before Objects. Dots before Properties and Methods. It then procedes in an orderly manner to explain why the dot can be used so extensively where bangs would be expected.
The reader could stop at any point and have gleaned the correct information.
While your information does provide a workable algorithm it is misleading. It would certainly confuse the reader who then went in search of more detail because it conflicts with the correct information.
boblarson said:
The Control is an object and should be preceded by a bang. Your syntactical system only works because the compiler is tolerant of dots used where there should technically be bangs.
Indeed after recommending dots before controls why recommend using the bang before fields? The dot-tolerant compliler will fix them both except in the single case of the shorthand default reference to a field in the recordset of a subformcontrol.
I carefully explained this single case in my post. Moreover this particularly expression is very obscure, not even being included in the most comprehensive reference syntax resource to be found on the Internet. Most new developers find it or are directed to it early in their learning curve.
http://www.mvps.org/access/forms/frm0031.htm
In this reference they use the bang before the controlname. Someone reading your advice to use the dot before controlnames will immediately be bewildered by the conflicting advice and still wonder about what actually governs the use of bang or dot.
What I also tried to clarify is the possible misinterpretation of your advice. It could easily be assumed that Me!somename would get a field from the recordset while Me.somename would reference the control.
The fact that the control takes precedence is crucial to the understanding of why either expression will sometimes return a control yet other times they will indeed return the field value.
BTW The real confusion for many is the concept of it being a choice between Me. and Me!
Me stands alone.
The operator is part of the next segment.
!controlname, !fieldname or .propertyname
The bang indicates object. The dot indicates propery or method. Put into this context with the correct information and the the issue becomes completely clear.
What intricate details? It is simple and consistent. Bang for objects. Dots for properties and methods.
There are no arguments except from those who don't really seem to understand but insist they do.
The confusion comes from online examples where the dot or bang seem to be used in exactly the same context and especially those where the poster apparently uses them at random because they believe controls should have dots and fields should have bangs.
Posters providing examples should either use the bang and dots in the strictly correct contexts or stick to using the dot everywhere.
Let's banish expressions like:
Me!subformcontrol.Form.controlname
Yes they do work but they are syntactically inconsistent.
ChrisO
Registered User.
- Local time
- Today, 11:52
- Joined
- Apr 30, 2003
- Messages
- 3,202
I dot unless it goes bang. 
What I dislike about the bang is that it prevents Intellisense.
Here is a reproducible clanger even in Access 2003.
That one seems curious to me because it was tolerated at the time and is still tolerated under a certain condition.
I think we have to ask ourselves; who wrote the code that tolerates it?
The answer would seem to be Microsoft or one of their contractors.
So another question arrises; was the difference between the bang and the dot always so clear cut?
Apparently not and even Microsoft had a re-think on the matter.
And another question; is there now a clear cut distinction between the bang and the dot.
Just a curious observation; the questions are rhetorical.
Chris.
What I dislike about the bang is that it prevents Intellisense.
Here is a reproducible clanger even in Access 2003.
Code:
Option Compare Database
Option Explicit
Sub TestIt()
Dim db As DAO.Database
Dim rs As DAO.Recordset
Set db = CurrentDb()
Set rs = db.OpenRecordset("tblTest")
With rs
Do Until .EOF
MsgBox .FirstName [color=green]' <<< dot .FirstName[/color]
.MoveNext
Loop
End With
rs.Close
Set rs = Nothing
db.Close
Set db = Nothing
End SubThat one seems curious to me because it was tolerated at the time and is still tolerated under a certain condition.
I think we have to ask ourselves; who wrote the code that tolerates it?
The answer would seem to be Microsoft or one of their contractors.
So another question arrises; was the difference between the bang and the dot always so clear cut?
Apparently not and even Microsoft had a re-think on the matter.
And another question; is there now a clear cut distinction between the bang and the dot.
Just a curious observation; the questions are rhetorical.
Chris.
Brianwarnock
Retired
- Local time
- Today, 02:52
- Joined
- Jun 2, 2003
- Messages
- 12,701
I dot unless it goes bang.
What I dislike about the bang is that it prevents Intellisense.
Chris.
Ditto.
I enjoyed Galaxiom's explanation, I'm learning so much now that I'm retired and have no use for it.
Brian
On further contemplation I think the crux of the matter is difference in the ways the Module object, Database object and Recordset objects expose their methods and properties.
The database and recordset are simple object models with collections of objects and properties inside. They are generally strict about the use of the bang or dot.
However the Module object is more complex. Somewhere inside the it understands all the objects and properties in the database but is in fact an abstraction of the database.
I suspect the objects in the database are exposed both as objects and as properties of the module object. Consequently they are recognised as both objects and properties and respond to either operator.
I would love to hear an expert's perspective on this.
The database and recordset are simple object models with collections of objects and properties inside. They are generally strict about the use of the bang or dot.
However the Module object is more complex. Somewhere inside the it understands all the objects and properties in the database but is in fact an abstraction of the database.
I suspect the objects in the database are exposed both as objects and as properties of the module object. Consequently they are recognised as both objects and properties and respond to either operator.
I would love to hear an expert's perspective on this.
ChrisO
Registered User.
- Local time
- Today, 11:52
- Joined
- Apr 30, 2003
- Messages
- 3,202
>>I enjoyed Galaxiom's explanation, I'm learning so much now that I'm retired and have no use for it. <<
I could not agree more, Brian. To me, the best time to learn is when there is no pressure to produce.
So if we think about the weekend as temporary retirement then perhaps people should come to site on the weekend to learn.
Chris.
<<I could not agree more, Brian. To me, the best time to learn is when there is no pressure to produce.
So if we think about the weekend as temporary retirement then perhaps people should come to site on the weekend to learn.
Chris.
ChrisO
Registered User.
- Local time
- Today, 11:52
- Joined
- Apr 30, 2003
- Messages
- 3,202
Bob and Galaxiom,
Many thanks for the explanation. I don't use subs so I hardly ever use Me! or Me. Instead I use CodeContextObject (I will confess it was so much easier than trying to work out the correct systax when referring to subForms) and I always use the [dot] rather then [bang] i.e. .[ControlName]. My question, yes I'm getting around to it, is there a preferable method? I remember something about late binding?
This is the type of discussion that deserves to be a sticky. Often we do things only because it works and it takes tucher61 to start a very good thread. Thanks
Simon
Many thanks for the explanation. I don't use subs so I hardly ever use Me! or Me. Instead I use CodeContextObject (I will confess it was so much easier than trying to work out the correct systax when referring to subForms) and I always use the [dot] rather then [bang] i.e. .[ControlName]. My question, yes I'm getting around to it, is there a preferable method? I remember something about late binding?
This is the type of discussion that deserves to be a sticky. Often we do things only because it works and it takes tucher61 to start a very good thread. Thanks
Simon
ChrisO
Registered User.
- Local time
- Today, 11:52
- Joined
- Apr 30, 2003
- Messages
- 3,202
Code:
Option Compare Database
Option Explicit
[color=green]'Here are another two for consideration.
'
'With all three in the same module…
'
'This works.[/color]
Sub TestIt_1()
Dim db As DAO.Database
Dim rs As DAO.Recordset
Set db = CurrentDb()
Set rs = db.OpenRecordset("tblTest")
With rs
Do Until .EOF
MsgBox .FirstName [color=green]'<<< dot .FirstName, I'm okay.[/color]
.MoveNext
Loop
End With
rs.Close
Set rs = Nothing
db.Close
Set db = Nothing
End Sub
[color=green]'This fails.[/color]
Sub TestIt_2()
With CurrentDb.OpenRecordset("tblTest")
Do Until .EOF
MsgBox .FirstName [color=green]'<<< Method or data method not found.[/color]
.MoveNext
Loop
End With
End Sub
[color=green]'This works.[/color]
Sub TestIt_3()
With CurrentDb.OpenRecordset("tblTest")
Do Until .EOF
MsgBox !FirstName [color=green]'<<< I'm okay.[/color]
.MoveNext
Loop
End With
End SubWhy?
The database has a specified reference to Microsoft DAO 2.5/3.5 Compatibility Library.
Because Sub TestIt_1() defines its variables as DAO.Database and DAO.Recordset it forces the use of the DAO Library as referenced. That reference tolerates using the dot for a field name as in .FirstName.
Sub TestIt_2() and Sub TestIt_3() do not use the defined reference of Microsoft DAO 2.5/3.5 Compatibility Library but instead use a hidden reference to Microsoft DAO 3.6 Object Library.
The hidden Microsoft DAO 3.6 Object Library does not tolerate using a dot as in .FirstName so Sub TestIt_2() fails.
Sub TestIt_3() is also using the hidden Microsoft DAO 3.6 Object Library but it is using a bang as in !FirstName so it works.
It would appear that somewhere along the line Microsoft made a decision to dissallow the dot with field names. It would also appear that the change was made between Microsoft DAO 2.5/3.5 Compatibility Library and Microsoft DAO 3.6 Object Library.
Now a question arrises in my mind; was that decision an arbitrary decision?
What I mean by an arbitrary decision is was it a necessity or was it just clean up, re-think, type of decision?
I don’t know, but it doesn’t appear to be a necessity because the Microsoft DAO 2.5/3.5 Compatibility Library can still handle both the dot and the bang in Access 2003.
Now if it wasn’t a necessity then it might have been a purely arbitrary decision. If it was a purely arbitrary decision then the use of either the dot or the bang may also be purely arbitrary in other situations.
However, Microsoft has made a decision be that decision a necessity or purely arbitrary.
What this could mean is that this discussion is not based on a necessity but is in fact purely arbitrary.
The meaning of that is that if it works then use it because if it doesn’t work, you can’t.
Chris.
ChrisO
Registered User.
- Local time
- Today, 11:52
- Joined
- Apr 30, 2003
- Messages
- 3,202
Simon, you seem to love that CodeContextObject.
As far as I understand it CodeContextObject is equivalent to Screen.ActiveControl.Parent
Both return a pointer to the parent of the Screen.ActiveControl.
Note: this is not the same as Screen.ActiveForm, but it could be.
On a Form with no sub-form, both Screen.ActiveControl.Parent and Screen.ActiveForm return a pointer to the Form.
On a Form with a sub-form and with a Control on that sub-form that has the focus; Screen.ActiveControl.Parent returns a pointer to the sub-form while Screen.ActiveForm returns a pointer to the outer most Form, not the sub-form.
CodeContextObject is more often seen in Macros that have been converted to VBA.
I would think, but can’t prove it, that CodeContextObject is just as reliable as Screen.ActiveControl.Parent.
But I prefer Screen.ActiveControl.Parent to CodeContextObject because, to me, CodeContextObject is less descriptive than Screen.ActiveControl.Parent.
Chris.
As far as I understand it CodeContextObject is equivalent to Screen.ActiveControl.Parent
Both return a pointer to the parent of the Screen.ActiveControl.
Note: this is not the same as Screen.ActiveForm, but it could be.
On a Form with no sub-form, both Screen.ActiveControl.Parent and Screen.ActiveForm return a pointer to the Form.
On a Form with a sub-form and with a Control on that sub-form that has the focus; Screen.ActiveControl.Parent returns a pointer to the sub-form while Screen.ActiveForm returns a pointer to the outer most Form, not the sub-form.
CodeContextObject is more often seen in Macros that have been converted to VBA.
I would think, but can’t prove it, that CodeContextObject is just as reliable as Screen.ActiveControl.Parent.
But I prefer Screen.ActiveControl.Parent to CodeContextObject because, to me, CodeContextObject is less descriptive than Screen.ActiveControl.Parent.
Chris.
Thanks Chris.
Yes, I did discover CodeContextObject converting macros but it all seemed sensible after moving all the sub routines and consolidating all the scripts into Functions. This was Access 1997 afterall.
Simon
Yes, I did discover CodeContextObject converting macros but it all seemed sensible after moving all the sub routines and consolidating all the scripts into Functions. This was Access 1997 afterall.
Simon
I think some of these decisions reflect the influence of the previous experience of design team members.
For example in SQL the properties of an object are not handled in dotted notations. Even though the Access query designer uses the dot, either the dot or bang can be used before an object. It will appear as an expression but it is fully understood by Jet.
A programmer coming from that background to work on DAO 2.5/3.5 might have continued with that interchangability, perhaps to the chagrin of a "bang for objects" purist.
Maybe the situation changed later when the dot tolerant leader moved on and the purist took charge.
Variations such as the case sensitvity in VB versus lack of it in VBA might have been driven the same way. Someone with a DOS background would have eschewed case sensitivity while a programmer with a Unix background would have taken it for granted.
ChrisO
Registered User.
- Local time
- Today, 11:52
- Joined
- Apr 30, 2003
- Messages
- 3,202
Well, it’s just a weekend discussion…
First up I must say that I like the way this thread is progressing.
It seems to me that it is moving away from some idea of absolute black and white into a more grey (gray, whatever) area.
From post #18…
>>I think some of these decisions reflect the influence of the previous experience of design team members.<<
My view, maybe, maybe not.
Not directed at post #18 but to all.
To explain my point of indecision I will need to digress away from the Me. Me! thing for a while.
When we look at code we are looking at a specific instance of that code. Here we are looking at VBA, not VB or SQL or DOS.
VBA is a different bucket of bolts altogether. Let’s digress and look at Option Explicit for a moment.
Because there is someone on this site (DWF) who disagrees with me when I say Option Explicit is off by default in VBA I will post some links.
http://msdn.microsoft.com/en-us/library/aa192490(v=office.11).aspx
http://www.fmsinc.com/free/NewTips/VBA/Option/index.html
http://www.cpearson.com/excel/DeclaringVariables.aspx
http://allenbrowne.com/ser-30.html
http://my.advisor.com/doc/17333
People should place their own importance on those links.
(And by the way, unloading Access and reloading Access does not change the last setting of ‘Require Variable Declaration’ that Access used for VBA. It seems to get the last setting from the registry, not from the reload of Access. In other words, if Access has ‘Require Variable Declaration’ set to True then when we unload and reload Access it will still be True, and the converse for False.)
So then why is Option Explicit important for this discussion?
VBA ships with Option Explicit turned off, whether we like it or not.
Why?
The reason, as I see it, is that VBA is not written for programmers, it is written for users. Be that a good or bad thing is open to interpretation.
When Option Explicit is turned off, and variables are not declared as anything in particular, then the user gets Variants. Variants can handle almost anything and, most of the time, the program works. (Or as someone once said to me; ‘it helps the phones stop ringing at Microsoft’. {That person has been trying to get Microsoft to default VBA Option Explicit to on for many years without success. He’s a good bloke but I disagree with him on this one.})
VBA is for people, not just programmers. The quicker those people get up to speed with it the better. People do not want ANSI ‘C’ with all warnings turned on; it would take months to get started. They want something they can use, and they want it now.
VBA is the syntax, fault tolerant solution to that requirement. (Programmers may now cringe but if they do then it’s up to them, not Microsoft, to turn Option Explicit on. They have been given the choice and they can {should} use it.)
Back to Me. And Me!
If we go for the implied requirement of VBA to be syntactically fault tolerant then we should expect, if the job has been done correctly, either Me. or Me! to be acceptable.
To that end, I don’t believe VBA can be reasonably compared with any other language. It has a dual roll in that out of the box it’s ready to go, admittedly with a great cringe factor from the purists. But if the purists want to turn Option Explicit on they get a different bucket of bolts altogether.
To that end even Microsoft may have done VBA a disservice.
The Microsoft DAO 2.5/3.5 Compatibility Library can handle the syntactically fault tolerance of Me. verses Me! whereas the later version of Microsoft DAO 3.6 Object Library can not.
So, if the aim of having Option Explicit default to off, presumably to get the users up and running quickly (syntax fault tolerance) then why was there a decrease in syntax fault tolerance between the Microsoft DAO 2.5/3.5 Compatibility Library and the later Microsoft DAO 3.6 Object Library? That is a question for Microsoft.
>>It’s just a weekend discussion…<< sounds like a good name for a new technical Forum but, then again, I’m biased.
Chris.
First up I must say that I like the way this thread is progressing.
It seems to me that it is moving away from some idea of absolute black and white into a more grey (gray, whatever) area.
From post #18…
>>I think some of these decisions reflect the influence of the previous experience of design team members.<<
My view, maybe, maybe not.
Not directed at post #18 but to all.
To explain my point of indecision I will need to digress away from the Me. Me! thing for a while.
When we look at code we are looking at a specific instance of that code. Here we are looking at VBA, not VB or SQL or DOS.
VBA is a different bucket of bolts altogether. Let’s digress and look at Option Explicit for a moment.
Because there is someone on this site (DWF) who disagrees with me when I say Option Explicit is off by default in VBA I will post some links.
http://msdn.microsoft.com/en-us/library/aa192490(v=office.11).aspx
http://www.fmsinc.com/free/NewTips/VBA/Option/index.html
http://www.cpearson.com/excel/DeclaringVariables.aspx
http://allenbrowne.com/ser-30.html
http://my.advisor.com/doc/17333
People should place their own importance on those links.
(And by the way, unloading Access and reloading Access does not change the last setting of ‘Require Variable Declaration’ that Access used for VBA. It seems to get the last setting from the registry, not from the reload of Access. In other words, if Access has ‘Require Variable Declaration’ set to True then when we unload and reload Access it will still be True, and the converse for False.)
So then why is Option Explicit important for this discussion?
VBA ships with Option Explicit turned off, whether we like it or not.
Why?
The reason, as I see it, is that VBA is not written for programmers, it is written for users. Be that a good or bad thing is open to interpretation.
When Option Explicit is turned off, and variables are not declared as anything in particular, then the user gets Variants. Variants can handle almost anything and, most of the time, the program works. (Or as someone once said to me; ‘it helps the phones stop ringing at Microsoft’. {That person has been trying to get Microsoft to default VBA Option Explicit to on for many years without success. He’s a good bloke but I disagree with him on this one.})
VBA is for people, not just programmers. The quicker those people get up to speed with it the better. People do not want ANSI ‘C’ with all warnings turned on; it would take months to get started. They want something they can use, and they want it now.
VBA is the syntax, fault tolerant solution to that requirement. (Programmers may now cringe but if they do then it’s up to them, not Microsoft, to turn Option Explicit on. They have been given the choice and they can {should} use it.)
Back to Me. And Me!
If we go for the implied requirement of VBA to be syntactically fault tolerant then we should expect, if the job has been done correctly, either Me. or Me! to be acceptable.
To that end, I don’t believe VBA can be reasonably compared with any other language. It has a dual roll in that out of the box it’s ready to go, admittedly with a great cringe factor from the purists. But if the purists want to turn Option Explicit on they get a different bucket of bolts altogether.
To that end even Microsoft may have done VBA a disservice.
The Microsoft DAO 2.5/3.5 Compatibility Library can handle the syntactically fault tolerance of Me. verses Me! whereas the later version of Microsoft DAO 3.6 Object Library can not.
So, if the aim of having Option Explicit default to off, presumably to get the users up and running quickly (syntax fault tolerance) then why was there a decrease in syntax fault tolerance between the Microsoft DAO 2.5/3.5 Compatibility Library and the later Microsoft DAO 3.6 Object Library? That is a question for Microsoft.
>>It’s just a weekend discussion…<< sounds like a good name for a new technical Forum but, then again, I’m biased.
Chris.
VilaRestal
';drop database master;--
- Local time
- Today, 02:52
- Joined
- Jun 8, 2011
- Messages
- 1,046
Sorry to bring this thread back to life but it was linked to in an active thread
But controls of a form are properties of that form: Property Let and Property Get functions that return or take an object.
It is more in-keeping with VB proper (any relatively modern version) to refer to them with a dot than a bang. And Access certainly allows you to: I've never had any code that does that fail.
Fields and collections are a special case (annoyingly so - they could be accessible by dots if MS had allowed it - as they can be in some cases).
All other objects can be accessed by dots from their parent and should be, in my opinion, to be consistent with VB syntax. Bangs only where unavoidable and/or inconsistent (fields and collections). Everything else dots.
But controls of a form are properties of that form: Property Let and Property Get functions that return or take an object.
It is more in-keeping with VB proper (any relatively modern version) to refer to them with a dot than a bang. And Access certainly allows you to: I've never had any code that does that fail.
Fields and collections are a special case (annoyingly so - they could be accessible by dots if MS had allowed it - as they can be in some cases).
All other objects can be accessed by dots from their parent and should be, in my opinion, to be consistent with VB syntax. Bangs only where unavoidable and/or inconsistent (fields and collections). Everything else dots.
Similar threads
