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

The best (correct?) way

P: n/a
Hi!
What is the best (correct?) way to do:

Me.txtCustID.SetFocus

in the OnLoad or in the OnOpen or... of the form?
Nov 13 '05 #1
Share this Question
Share on Google+
15 Replies


P: n/a
Geir Baardsen wrote:
Hi!
What is the best (correct?) way to do:

Me.txtCustID.SetFocus

in the OnLoad or in the OnOpen or... of the form?


Set it's TabIndex property to 0 in design view, forget the code. IT will
have the focus when the form is opened.

If however txtCustID is in the form header or footer then use some code
in OnOpen.

BTW your syntax is little off, the dot is for properties and methods,
use a bang for your objects, e.g.

Me!txtCustID
Me("txtCustID") which is short for
Me.Controls("txtCustID")

There used to be a little rule, if MS created it, it was Me. else if you
created it it was Me!

Using Me.ControlName can cause problems, if an object has the same name
as a property or method it can create confusion, either produce
unexpected results or just confuse a developer later on who looks at the
code. Additionally, it can produce random compile errors, one minute it
compiles OK the next it doesn't.
Nov 13 '05 #2

P: n/a
Trevor Best <nospam@localhost> wrote:
Using Me.ControlName can cause problems, if an object has the same name
as a property or method it can create confusion, either produce
unexpected results or just confuse a developer later on who looks at the
code. Additionally, it can produce random compile errors, one minute it
compiles OK the next it doesn't.


That's interesting. I always use Me.ControlName but all my control names
have prefixes such as 'txt' (text box) and 'cbo' (combo box) - is this
relatively safe? I don't seem to get any compile errors. A97 BTW.
Nov 13 '05 #3

P: n/a
That's safe, Keith.

I use the dot, and don't bother with the prefix for bound controls (i.e. the
control has the same name as the field).

The only problem I've seen is when the field is *not* represented by a
control on the form, and you refer to the field as:
Me.MyField
That case can (but does not always) trigger the strange issue that Trevor
refers to.

It seems that the field-without-control is of the undocumented type
AccessField, and there must be some bugs in the way it is implemented. A
possibly related case can cause Access 2002 to crash (and possibly 2003).
That can happen where the LinkChildFields property of a subform control
refers to an AccessField type (i.e. a field in the subform's RecordSource,
that is not represented by a text box in the subform). Adding a text box for
this foreign key field stops the crashes.

BTW, the reason I prefer the dot is that if I mistype the control name, it
is caught at compile time.

--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"Keith Wilby" <ke*********@AwayWithYerCrap.com> wrote in message
news:Xn************************@10.15.188.42...
Trevor Best <nospam@localhost> wrote:
Using Me.ControlName can cause problems, if an object has the same name
as a property or method it can create confusion, either produce
unexpected results or just confuse a developer later on who looks at the
code. Additionally, it can produce random compile errors, one minute it
compiles OK the next it doesn't.


That's interesting. I always use Me.ControlName but all my control names
have prefixes such as 'txt' (text box) and 'cbo' (combo box) - is this
relatively safe? I don't seem to get any compile errors. A97 BTW.

Nov 13 '05 #4

P: n/a
Keith Wilby wrote:
Trevor Best <nospam@localhost> wrote:

Using Me.ControlName can cause problems, if an object has the same name
as a property or method it can create confusion, either produce
unexpected results or just confuse a developer later on who looks at the
code. Additionally, it can produce random compile errors, one minute it
compiles OK the next it doesn't.

That's interesting. I always use Me.ControlName but all my control names
have prefixes such as 'txt' (text box) and 'cbo' (combo box) - is this
relatively safe? I don't seem to get any compile errors. A97 BTW.


Upgrade it to 2K2 and watch :-)

--

\\\\\\
\\ \\ Windows is searching
\ \ For your sig.
\ \ Please Wait.
\__\

Nov 13 '05 #5

P: n/a
Trevor Best <nospam@localhost> wrote:
That's interesting. I always use Me.ControlName but all my control
names have prefixes such as 'txt' (text box) and 'cbo' (combo box) -
is this relatively safe? I don't seem to get any compile errors. A97
BTW.


Upgrade it to 2K2 and watch :-)


I've just done a test upgrade to A2003 and all seems well but I will bear
what you have said in mind :o)
Nov 13 '05 #6

P: n/a
"Allen Browne" <Al*********@SeeSig.Invalid> wrote:
BTW, the reason I prefer the dot is that if I mistype the control name,
it is caught at compile time.


Being rather lazy I too prefer the dot as the code screen's auto-complete
saves a lot of typing. Thanks for your response.
Nov 13 '05 #7

P: n/a
In article <41**********************@auth.uk.news.easynet.net >,
nospam@localhost says...
Geir Baardsen wrote:
Hi!
What is the best (correct?) way to do:

Me.txtCustID.SetFocus

in the OnLoad or in the OnOpen or... of the form?


Set it's TabIndex property to 0 in design view, forget the code. IT will
have the focus when the form is opened.

If however txtCustID is in the form header or footer then use some code
in OnOpen.

BTW your syntax is little off, the dot is for properties and methods,
use a bang for your objects, e.g.

Me!txtCustID
Me("txtCustID") which is short for
Me.Controls("txtCustID")

There used to be a little rule, if MS created it, it was Me. else if you
created it it was Me!

Using Me.ControlName can cause problems, if an object has the same name
as a property or method it can create confusion, either produce
unexpected results or just confuse a developer later on who looks at the
code. Additionally, it can produce random compile errors, one minute it
compiles OK the next it doesn't.

If you use a good naming convention you will never have that issue.
Nov 13 '05 #8

P: n/a
Keith Wilby wrote:
Trevor Best <nospam@localhost> wrote:

That's interesting. I always use Me.ControlName but all my control
names have prefixes such as 'txt' (text box) and 'cbo' (combo box) -
is this relatively safe? I don't seem to get any compile errors. A97
BTW.


Upgrade it to 2K2 and watch :-)

I've just done a test upgrade to A2003 and all seems well but I will bear
what you have said in mind :o)


I have just done a A97 to 2K2 conversion for a rather old app we just
dug up out of the archives (it was a bespoke development for someone
long since gone but someone has expressed an interest in it) and apart
from where MS had introduced some functions/properties/methods that I
already had those names as functions it compiled OK. It's only when I
started working on a particular form that the compile errors started to
crop up. It may have been the AccessField thing that Allen mentioned but
I didn't check the field names vs textboxes as the primary concern was
to get the thing into a state where it can be shown to a prospective
client and *look* good, don't care if it works or not, as long as no
silly error messages pop up, if we get the job we'll worry about making
it work then :-) By then it will have been thoroughly tested and debugged.

--

\\\\\\
\\ \\ Windows is searching
\ \ For your sig.
\ \ Please Wait.
\__\

Nov 13 '05 #9

P: n/a
Ima Lostsoul wrote:
If you use a good naming convention you will never have that issue.


I totally agree, languages of old would never let you use a name that
conflicted with a reserved word but these new fangled things like Access
allow this sort of thing, even spaces in names which is {user
friendly|sloppy}. IMHO the language/platform would be doing the
developer more favors if it were a little bit more strict.

--

\\\\\\
\\ \\ Windows is searching
\ \ For your sig.
\ \ Please Wait.
\__\

Nov 13 '05 #10

P: n/a
Keith Wilby <ke*********@AwayWithYerCrap.com> wrote in
news:Xn************************@10.15.188.42:
"Allen Browne" <Al*********@SeeSig.Invalid> wrote:
BTW, the reason I prefer the dot is that if I mistype the control
name, it is caught at compile time.


Being rather lazy I too prefer the dot as the code screen's
auto-complete saves a lot of typing. Thanks for your response.


Ctrl-Spacebar gets you a different version of Intellisense that
includes what you need. So, there's no extra typing with the bang.

--
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 wrote:
Ctrl-Spacebar gets you a different version of Intellisense that
includes what you need. So, there's no extra typing with the bang.


But it gives you a load of irrelevant entries to choose from.

--

\\\\\\
\\ \\ Windows is searching
\ \ For your sig.
\ \ Please Wait.
\__\

Nov 13 '05 #12

P: n/a
Trevor Best <nospam@localhost> wrote in message news:<41*********************@auth.uk.news.easynet .net>...
Ima Lostsoul wrote:
If you use a good naming convention you will never have that issue.


I totally agree, languages of old would never let you use a name that
conflicted with a reserved word but these new fangled things like Access
allow this sort of thing, even spaces in names which is {user
friendly|sloppy}. IMHO the language/platform would be doing the
developer more favors if it were a little bit more strict.

Thanks for information. You are right...I had some crashes now and then, and >>maybe it is because of wrong use of .DOTS and !BANGSI'll check my entire projects...;-}

Nov 13 '05 #13

P: n/a
Trevor Best <nospam@localhost> wrote in
news:41***********************@auth.uk.news.easyne t.net:
David W. Fenton wrote:
Ctrl-Spacebar gets you a different version of Intellisense that
includes what you need. So, there's no extra typing with the
bang.


But it gives you a load of irrelevant entries to choose from.


If you're going to point and click your way, yes.

But if you know how to TYPE, one or two characters gets you where
you need to be.

Personally, I don't experience any difference between the standard
Intellisense lists and the one that comes up with Ctrl-Space,
because I'm typing. Indeed, I prefer the Ctrl-Space list, since it
doesn't pop up when I don't want it.

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

P: n/a
David W. Fenton wrote:
Trevor Best <nospam@localhost> wrote in
news:41***********************@auth.uk.news.easyne t.net:

David W. Fenton wrote:

Ctrl-Spacebar gets you a different version of Intellisense that
includes what you need. So, there's no extra typing with the
bang.


But it gives you a load of irrelevant entries to choose from.

If you're going to point and click your way, yes.

But if you know how to TYPE, one or two characters gets you where
you need to be.

Personally, I don't experience any difference between the standard
Intellisense lists and the one that comes up with Ctrl-Space,
because I'm typing. Indeed, I prefer the Ctrl-Space list, since it
doesn't pop up when I don't want it.


I would find it more useful if you could customise the order or if it
remembered your most used entries and stuck at the top of the list or
something, getting to ".Value" you have to type nearly the whole word
anyway to get past .ValidationRule, etc.

A good way would be type . to pring up your favorites, ctrl-space to
bring up all relevant and ctrl-space again to bring them all up

--

\\\\\\
\\ \\ Windows is searching
\ \ For your sig.
\ \ Please Wait.
\__\

Nov 13 '05 #15

P: n/a
"David W. Fenton" <dX********@bway.net.invalid> wrote:
Ctrl-Spacebar gets you a different version of Intellisense that
includes what you need. So, there's no extra typing with the bang.


Didn't know that. There's always summat new to learn - thanks :o)
Nov 13 '05 #16

This discussion thread is closed

Replies have been disabled for this discussion.