By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
458,114 Members | 1,574 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 458,114 IT Pros & Developers. It's quick & easy.

dot vs. bang (again!!)

P: n/a
I know this subject has been discussed many times and I do not wish to
go over all the ground again but I have a particular problem.

In the code for a Form I always use the dot notation to refer to a
field in the Form's Record Source or to a control on the Form. For
example Me.CustomerID is the value of CustomerID in the Record Source
even if there is no control on the Form whose name is CustomerID. If
I place a control on the Form with its Control Source as CustomerID, I
would name it CustomerID as well.

So far, so good.

When I use Me.CustomerID to refer to a Record Source field without
having a corresponding control on the Form, it works correctly on my
computer (and on a number of others) but when I send the code to one
particular person, it does not work - the usual 'Method or data member
not found' occurs. We then need to place a control named CustomerID
on the Form and make it invisible. This seems to be so unnecessary.

What should I look for on this other machine to get it to work as I
expect? Is there some (hidden) setting in Access which affects this?
I know that I could use ! but do not want to (for well trodden
reasons). I want to understand this specific problem.
Nov 13 '05 #1
Share this Question
Share on Google+
22 Replies


P: n/a
Keith Tizzard wrote:
I know this subject has been discussed many times and I do not wish to
go over all the ground again but I have a particular problem.

In the code for a Form I always use the dot notation to refer to a
field in the Form's Record Source or to a control on the Form. For
example Me.CustomerID is the value of CustomerID in the Record Source
even if there is no control on the Form whose name is CustomerID. If
I place a control on the Form with its Control Source as CustomerID, I
would name it CustomerID as well.

So far, so good.

When I use Me.CustomerID to refer to a Record Source field without
having a corresponding control on the Form, it works correctly on my
computer (and on a number of others) but when I send the code to one
particular person, it does not work - the usual 'Method or data member
not found' occurs. We then need to place a control named CustomerID
on the Form and make it invisible. This seems to be so unnecessary.

What should I look for on this other machine to get it to work as I
expect? Is there some (hidden) setting in Access which affects this?
I know that I could use ! but do not want to (for well trodden
reasons). I want to understand this specific problem.


Why bother attempting to bypass potential errors. If I had a solution
that worked on all computers vs one that works on some, I'd use the one
that works on all.

By excluding fields, are you attempting to to save 5 or 6 bytes of disk
space? The form looks ugly if you have hidden fields on it?

Maybe your question will genenerate a discusstion on control sources,
object naming, sorts, filters and the like. In my case, I simply see a
problem easily corrected in your situation. Again, I'd sooner have
something that worked all the time that something that worked part time.
Nov 13 '05 #2

P: n/a

"Keith Tizzard" <in***************@foobox.com> wrote in message
news:3d**************************@posting.google.c om...
I know this subject has been discussed many times and I do not wish to
go over all the ground again but I have a particular problem.

In the code for a Form I always use the dot notation to refer to a
field in the Form's Record Source or to a control on the Form. For
example Me.CustomerID is the value of CustomerID in the Record Source
even if there is no control on the Form whose name is CustomerID. If
I place a control on the Form with its Control Source as CustomerID, I
would name it CustomerID as well.

So far, so good.

When I use Me.CustomerID to refer to a Record Source field without
having a corresponding control on the Form, it works correctly on my
computer (and on a number of others) but when I send the code to one
particular person, it does not work - the usual 'Method or data member
not found' occurs. We then need to place a control named CustomerID
on the Form and make it invisible. This seems to be so unnecessary.

What should I look for on this other machine to get it to work as I
expect? Is there some (hidden) setting in Access which affects this?
I know that I could use ! but do not want to (for well trodden
reasons). I want to understand this specific problem.

Nov 13 '05 #3

P: n/a
"Keith Tizzard" <in***************@foobox.com> wrote in message
news:3d**************************@posting.google.c om...
I know this subject has been discussed many times and I do not wish to
go over all the ground again but I have a particular problem.

In the code for a Form I always use the dot notation to refer to a
field in the Form's Record Source or to a control on the Form. For
example Me.CustomerID is the value of CustomerID in the Record Source
even if there is no control on the Form whose name is CustomerID. If
I place a control on the Form with its Control Source as CustomerID, I
would name it CustomerID as well.


I think that the fact this has worked so far for you is fortuitous - it
sounds like a recipe for disaster. I know you were not looking for people to
say "don't do this" but I'll bet that every response you get will say
exactly that - it's not a good idea.

Nov 13 '05 #4

P: n/a
Having the control and field both with the same name can cause you problems.
If I have a field called CustomerID, I'll usually name the textbox
txtCustomerID. That way there is no ambiguity as to which I'm referring to.
It also reminds me what type of control it is.

That being said, if something works on all but one computer, it is usually a
References problem on the troublesome computer. See this link for more
information.

http://members.iinet.net.au/~allenbrowne/ser-38.html

--
Wayne Morgan
MS Access MVP
"Keith Tizzard" <in***************@foobox.com> wrote in message
news:3d**************************@posting.google.c om...
I know this subject has been discussed many times and I do not wish to
go over all the ground again but I have a particular problem.

In the code for a Form I always use the dot notation to refer to a
field in the Form's Record Source or to a control on the Form. For
example Me.CustomerID is the value of CustomerID in the Record Source
even if there is no control on the Form whose name is CustomerID. If
I place a control on the Form with its Control Source as CustomerID, I
would name it CustomerID as well.

So far, so good.

When I use Me.CustomerID to refer to a Record Source field without
having a corresponding control on the Form, it works correctly on my
computer (and on a number of others) but when I send the code to one
particular person, it does not work - the usual 'Method or data member
not found' occurs. We then need to place a control named CustomerID
on the Form and make it invisible. This seems to be so unnecessary.

What should I look for on this other machine to get it to work as I
expect? Is there some (hidden) setting in Access which affects this?
I know that I could use ! but do not want to (for well trodden
reasons). I want to understand this specific problem.

Nov 13 '05 #5

P: n/a
Thank you Wayne for your advice on naming. The references appear to be
OK.

The problem I posed is where there is no control on the form and I
simply
wish to use the value of a field CustomerID. Why does Me.CustomerID
work
in one system and not in another?

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!
Nov 13 '05 #6

P: n/a
There are several things that can cause this, but usually it is References
(even if they look ok). The link I gave will walk you through some things to
verify them.

If the References are ok, then patch levels would be the next thing to
check. Verify that all Windows, Office, MDAC, and Jet patches are up to
date.

http://office.microsoft.com and choose Check for Updates
http://www.microsoft.com/data
http://windowsupdate.microsoft.com

--
Wayne Morgan
MS Access MVP
"Keith Tizzard" <in***************@foobox.com> wrote in message
news:41**********************@news.newsgroups.ws.. .
Thank you Wayne for your advice on naming. The references appear to be
OK.

The problem I posed is where there is no control on the form and I
simply
wish to use the value of a field CustomerID. Why does Me.CustomerID
work
in one system and not in another?

Nov 13 '05 #7

P: n/a
Wayne Morgan wrote:
Having the control and field both with the same name can cause you problems.
????

If I open a form in design mode and drag a field down, both the control
source and field name are the same. That appears to be the default.

If I drop a field in a TextBox onto the form and set the control source
to EmployeeID, I make the name the same. Otherwise I might end up with
a bunch of Text0...Text99 and I have no idea which source it references.
If I have a field called CustomerID, I'll usually name the textbox
txtCustomerID. That way there is no ambiguity as to which I'm referring to.
It also reminds me what type of control it is.


txtCustomerID is far better when you are writing code vs Text0.
Nov 13 '05 #8

P: n/a
"Salad" <oi*@vinegar.com> wrote in message
news:fv*****************@newsread3.news.pas.earthl ink.net...
Wayne Morgan wrote:
Having the control and field both with the same name can cause you problems.


????

If I open a form in design mode and drag a field down, both the control source
and field name are the same. That appears to be the default.

If I drop a field in a TextBox onto the form and set the control source to
EmployeeID, I make the name the same. Otherwise I might end up with a bunch
of Text0...Text99 and I have no idea which source it references.
If I have a field called CustomerID, I'll usually name the textbox
txtCustomerID. That way there is no ambiguity as to which I'm referring to.
It also reminds me what type of control it is.


txtCustomerID is far better when you are writing code vs Text0.


I always (except when using an expression) make my control names the same as the
field names and have never encountered any issues with it. I've always wondered
if there were problems with this in older versions and the idea that it should
be avoided has just carried over.
--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com
Nov 13 '05 #9

P: n/a
"Keith Tizzard" <in***************@foobox.com> wrote in message
news:41**********************@news.newsgroups.ws.. .
Thank you Wayne for your advice on naming. The references appear to be
OK.

The problem I posed is where there is no control on the form and I
simply
wish to use the value of a field CustomerID. Why does Me.CustomerID
work
in one system and not in another?


As mentioned, the reason is likely a reference problem.

however, do be aware that if you program change the record source of the
form, then often use me.whatever will fail.

In fact, try removing the record source for the form..and then compile your
code. It will NOT compile. Why, because me.CustomerID does not now exist.
So, if you form has a table, or query...*usually* me.CustomerID will work.
however, if you via code set, or change the forms reocrdsouce, then you
can't guarantee that me.CustomerID will exist. For this reason, if the value
your are working with is NOT placed as control on the screen,then you have
to use

me!CustomerID

The above code will compile regardless if the form has a actual value, or
not.

So, the possible reason why it might be failing is that you change the
source of the form..and if you do that..then ms-access can't know, or
guarantee the me.CustomerID will exist. You have to two choice in this case:

1) put a control on the form that is called CustomerID. I used to do this
until I learned the above.
2) use me!CustomerID when you can't be sure of the sql, or data source for
a form.

So, normally you *can* use me.customerID. However, if your code changes the
sql, or data source of the form, then you can't use this syntax..since the
form may, or may not actually have a cutomerID...
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pl*****************@msn.com
http://www.attcanada.net/~kallal.msn
Nov 13 '05 #10

P: n/a
"Rick Brandt" <ri*********@hotmail.com> wrote in
news:2u*************@uni-berlin.de:
"Salad" <oi*@vinegar.com> wrote in message
news:fv*****************@newsread3.news.pas.earthl ink.net...
Wayne Morgan wrote:
Having the control and field both with the same name can cause
you problems.


????

If I open a form in design mode and drag a field down, both the
control source and field name are the same. That appears to be
the default.

If I drop a field in a TextBox onto the form and set the control
source to EmployeeID, I make the name the same. Otherwise I
might end up with a bunch of Text0...Text99 and I have no idea
which source it references.
If I have a field called CustomerID, I'll usually name the
textbox txtCustomerID. That way there is no ambiguity as to
which I'm referring to. It also reminds me what type of control
it is.


txtCustomerID is far better when you are writing code vs Text0.


I always (except when using an expression) make my control names
the same as the field names and have never encountered any issues
with it. I've always wondered if there were problems with this in
older versions and the idea that it should be avoided has just
carried over.


If you refer to the value of a control in the controlsource of
another control and the referenced control has the same name as its
underlying controlsource, you'll get a #NAME error, because Access
can't resolve the ambiguity.

If you refer to a control in code and that control's name is
identical to its underlying controlsource, then you're forcing VBA
to resolve the ambiguity (it's doable, since there aren't very many
overlaps between controls and fields in terms of
properties/methods). I don't like to rely on VBA guessing correctly,
so I have three rules:

1. Accept the default control names when you drag and drop.

2. Disambiguate the name of the control if another control refers to
it.

3. Disambiguate the name of the control if it's referred to in code.

The basic principle is accept the defaults until you do something
that could cause problems. If you're not referring to a control in
code or in another control's controlsource, the duplication in the
name space doesn't matter.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #11

P: n/a
"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:Xn**********************************@24.168.1 28.90...
"Rick Brandt" <ri*********@hotmail.com> wrote in
news:2u*************@uni-berlin.de:
"Salad" <oi*@vinegar.com> wrote in message
news:fv*****************@newsread3.news.pas.earthl ink.net...
Wayne Morgan wrote:
Having the control and field both with the same name can cause
you problems.

????

If I open a form in design mode and drag a field down, both the
control source and field name are the same. That appears to be
the default.

If I drop a field in a TextBox onto the form and set the control
source to EmployeeID, I make the name the same. Otherwise I
might end up with a bunch of Text0...Text99 and I have no idea
which source it references.

If I have a field called CustomerID, I'll usually name the
textbox txtCustomerID. That way there is no ambiguity as to
which I'm referring to. It also reminds me what type of control
it is.

txtCustomerID is far better when you are writing code vs Text0.


I always (except when using an expression) make my control names
the same as the field names and have never encountered any issues
with it. I've always wondered if there were problems with this in
older versions and the idea that it should be avoided has just
carried over.


If you refer to the value of a control in the controlsource of
another control and the referenced control has the same name as its
underlying controlsource, you'll get a #NAME error, because Access
can't resolve the ambiguity.


Just tested the above and it worked for me.

TextBox named FirstName bound to field named FirstName. Second TextBox with
ControlSource of...

=[FirstName] & "XXXX"

....returned the correct value.

(This was in Access 97)
--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com
Nov 13 '05 #12

P: n/a
I can't help but wonder about data errors. For example,
one reason for getting this error would be because you
are linked to an older version of the database, and the
field actually IS missing. I've personally never seen
that particular error message associated with a reference
error.

Changing the datasource in code, or using AddFromText, will
cause this problem, so SourceSafe causes this problem, and
perhaps SaveAsPreviousVersion might, but I've never seen it
caused by Import/Export or /Compact or /Decompile. What
version of Access is in use?

(david)

"Keith Tizzard" <in***************@foobox.com> wrote in message
news:3d**************************@posting.google.c om...
I know this subject has been discussed many times and I do not wish to
go over all the ground again but I have a particular problem.

In the code for a Form I always use the dot notation to refer to a
field in the Form's Record Source or to a control on the Form. For
example Me.CustomerID is the value of CustomerID in the Record Source
even if there is no control on the Form whose name is CustomerID. If
I place a control on the Form with its Control Source as CustomerID, I
would name it CustomerID as well.

So far, so good.

When I use Me.CustomerID to refer to a Record Source field without
having a corresponding control on the Form, it works correctly on my
computer (and on a number of others) but when I send the code to one
particular person, it does not work - the usual 'Method or data member
not found' occurs. We then need to place a control named CustomerID
on the Form and make it invisible. This seems to be so unnecessary.

What should I look for on this other machine to get it to work as I
expect? Is there some (hidden) setting in Access which affects this?
I know that I could use ! but do not want to (for well trodden
reasons). I want to understand this specific problem.

Nov 13 '05 #13

P: n/a
"Rick Brandt" <ri*********@hotmail.com> wrote in message news:<2u*************@uni-berlin.de>...
"Salad" <oi*@vinegar.com> wrote in message
news:fv*****************@newsread3.news.pas.earthl ink.net...
Wayne Morgan wrote:
Having the control and field both with the same name can cause you problems.


????

If I open a form in design mode and drag a field down, both the control source
and field name are the same. That appears to be the default.

If I drop a field in a TextBox onto the form and set the control source to
EmployeeID, I make the name the same. Otherwise I might end up with a bunch
of Text0...Text99 and I have no idea which source it references.
If I have a field called CustomerID, I'll usually name the textbox
txtCustomerID. That way there is no ambiguity as to which I'm referring to.
It also reminds me what type of control it is.


txtCustomerID is far better when you are writing code vs Text0.


I always (except when using an expression) make my control names the same as the
field names and have never encountered any issues with it. I've always wondered
if there were problems with this in older versions and the idea that it should
be avoided has just carried over.


I *always* rename the controls - I never accept the Access defaults.
Partly because we have mandated naming conventions in our company, but
mainly because it's just plain common sense. I know immediately that
txtSurname refers to a control, and fldSurname refers to a field.
It's a no-brainer, surely? A few seconds typing for unlimited,
unambiguous domain knowledge?

Edward
--
The reading group's reading group:
http://www.bookgroup.org.uk
Nov 13 '05 #14

P: n/a
Rick, this is one that will definitely cause an error. It's a little more
specific than the one mentioned.

http://www.mvps.org/access/forms/frm0018.htm

--
Wayne Morgan
MS Access MVP
Nov 13 '05 #15

P: n/a
On Mon, 25 Oct 2004 11:59:47 GMT, "Wayne Morgan" <co***************************@hotmail.com> wrote:
Rick, this is one that will definitely cause an error. It's a little more
specific than the one mentioned.

http://www.mvps.org/access/forms/frm0018.htm


That is a different scenario. That error is caused by naming a calculated control with the same name as a field in the
recordsource. Simply bad programming practice.

Like Rick I have never had a single problem using the Me. notation with bound controls where the control name is the
same as the underlying fieldname. Nor have I ever seen a reproducible example of problems caused by using Me. instead of
Me!
Wayne Gillespie
Gosford NSW Australia
Nov 13 '05 #16

P: n/a

"Wayne Morgan" <co***************************@hotmail.com> wrote in message
news:TU***************@newssvr12.news.prodigy.com. ..
Rick, this is one that will definitely cause an error. It's a little more
specific than the one mentioned.

http://www.mvps.org/access/forms/frm0018.htm


My original post did say that I was aware of the problem when using an
expression as a control source.

--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com
Nov 13 '05 #17

P: n/a
Wayne

Do you ever do what was in the orginal question, namely refer in your
code to
a field in the RecordSource which does not have a corresponding control
on
the form e.g.

if not isnull(Me.CustomerID) then ....

Any problems with this?

Ron

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!
Nov 13 '05 #18

P: n/a
Rick Brandt wrote:
TextBox named FirstName bound to field named FirstName. Second TextBox with
ControlSource of...

=[FirstName] & "XXXX"

...returned the correct value.

(This was in Access 97)


In A97, this has always caused the #NAME! error for me.
--
Tim
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "What's UP, Dittoooooo?" - Ditto
Nov 13 '05 #19

P: n/a
Ron Devonish wrote:
Wayne

Do you ever do what was in the orginal question, namely refer in your
code to
a field in the RecordSource which does not have a corresponding control
on
the form e.g.

if not isnull(Me.CustomerID) then ....
I tend to avoid this as much as possible since it may not compile and
then not work.

Why would someone write code for a control that does not exist? I
suppose you can cut and paste code that attempts to access a control
that does not exist but this probably does not compile.

Any problems with this?

Ron

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

Nov 13 '05 #20

P: n/a
Will wrote:
"Rick Brandt" <ri*********@hotmail.com> wrote in message news:<2u*************@uni-berlin.de>...
"Salad" <oi*@vinegar.com> wrote in message
news:fv*****************@newsread3.news.pas.eart hlink.net...
Wayne Morgan wrote:

Having the control and field both with the same name can cause you problems.

????

If I open a form in design mode and drag a field down, both the control source
and field name are the same. That appears to be the default.

If I drop a field in a TextBox onto the form and set the control source to
EmployeeID, I make the name the same. Otherwise I might end up with a bunch
of Text0...Text99 and I have no idea which source it references.
If I have a field called CustomerID, I'll usually name the textbox
txtCustomerID. That way there is no ambiguity as to which I'm referring to.
It also reminds me what type of control it is.

txtCustomerID is far better when you are writing code vs Text0.
I always (except when using an expression) make my control names the same as the
field names and have never encountered any issues with it. I've always wondered
if there were problems with this in older versions and the idea that it should
be avoided has just carried over.

I *always* rename the controls - I never accept the Access defaults.
Partly because we have mandated naming conventions in our company, but
mainly because it's just plain common sense. I know immediately that
txtSurname refers to a control, and fldSurname refers to a field.
It's a no-brainer, surely? A few seconds typing for unlimited,
unambiguous domain knowledge?


IMO, this is a definite "whatever floats your boat" thing...regarding
naming controls using the control source name.

Edward
--
The reading group's reading group:
http://www.bookgroup.org.uk

Nov 13 '05 #21

P: n/a
On a Form I wish to display a Customer's name and have a field and a
control
both named CustomerName. However in the RecordSource
query,CustomerName is obtained from a Customers table via the unique
identifier CustomerID

I have no particular need to have a control for CustomerID but I do want
to
write a double click event for the CustomerName control which will have
code
such as

DoCmd.OpenForm "CustomerDetails",,,"CustomerID = " & Me.CustomerID
Ron

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!
Nov 13 '05 #22

P: n/a
Salad <oi*@vinegar.com> wrote in
news:ce****************@newsread3.news.pas.earthli nk.net:
IMO, this is a definite "whatever floats your boat"
thing...regarding naming controls using the control source name.


Well, it's not for the circumstances where the errors occur because
of the lack of disambiguation between the control and the field of
the same name. It's bloody stupid to insist on a practice that will
lead to problems.

Of course, I'm a banger, simply because I find the dot operator
inelegant, since it conflates multiple collections into a single
collection, and relies on the hidden wrapper properties created by
Access behind the scenes (in order give you the compile-time
checking).

I must say that the least common runtime error I ever encounter is
Me!SomeControl references that are invalid.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #23

This discussion thread is closed

Replies have been disabled for this discussion.