Problem with SetFocus

[Guest]

I am using Access 2002. I have considerable experience with Excel and VBA but
very little with Access.

My problem is with SetFocus. I have a main form and a subform. I shift the
focus to the subform and after some processing I am trying to set the focus
back to a control on the main form. However, I get an error 2110. (Microsoft
Access can’t move the focus to this control.)

After considerable testing, the SetFocus appeared to be working even though
I was still getting the error message.

I tried OnError Resume Next to suppress the Error message and now it works
fine. However, I would like to know if anyone can give me any advice. Perhaps
I should be including some other code first.

This is the code. (I have tried with and without the first 3 lines and they
make no difference.)

Forms!NameAndAddress.Visible = True
Forms!NameAndAddress.SetFocus
Forms!NameAndAddress.Repaint
On Error Resume Next
Forms!NameAndAddress![Post Code].SetFocus
On Error GoTo 0

Have also tried the following without success using both with and without
the error message suppressing. Doesn’t work with either method.

Forms!NameAndAddress.Visible = True
Forms!NameAndAddress.SetFocus
Forms!NameAndAddress.Repaint
DoCmd.GoToControl [Post Code]

Will very much appreciate any help.

Regards,

OssieMac

 

[Guest]

Just a thought, have you tried setting focus to the form first as:

Forms!NameAndAddress.SetFocus
Forms!NameAndAddress.Repaint
Forms!NameAndAddress.SetFocus
Forms!NameAndAddress![Post Code].SetFocus

I dont get an error when I use the last two lines but I don't use the
repaint method.

I have noticed I have used DoCmd to overcome one issue the same as yours

DoCmd.SetWarnings False
DoCmd.GoToControl "ProjectPlan"
DoCmd.SetWarnings True

I can't remember why I used this though and most of the time,

Forms!FormName.SetFocus
Forms!FormName![Post Code].SetFocus

Appears to work for me?? Let know if you find the error?

Mike B
--
An Engineers Prayer:
At the very end of the day,
when all else fails,
you have tried all,
you have shouted at and blamed the innocent,
and asked everyone you know,

READ THE INSTRUCTION MANUAL.

 

[Guest]

If that works, I have an idea why

Regards Mike B
--
An Engineers Prayer:
At the very end of the day,
when all else fails,
you have tried all,
you have shouted at and blamed the innocent,
and asked everyone you know,

READ THE INSTRUCTION MANUAL.

Just a thought, have you tried setting focus to the form first as:

Forms!NameAndAddress.SetFocus
Forms!NameAndAddress.Repaint
Forms!NameAndAddress.SetFocus
Forms!NameAndAddress![Post Code].SetFocus

I dont get an error when I use the last two lines but I don't use the
repaint method.

I have noticed I have used DoCmd to overcome one issue the same as yours

DoCmd.SetWarnings False
DoCmd.GoToControl "ProjectPlan"
DoCmd.SetWarnings True

I can't remember why I used this though and most of the time,

Forms!FormName.SetFocus
Forms!FormName![Post Code].SetFocus

Appears to work for me?? Let know if you find the error?

Mike B
--
An Engineers Prayer:
At the very end of the day,
when all else fails,
you have tried all,
you have shouted at and blamed the innocent,
and asked everyone you know,

READ THE INSTRUCTION MANUAL.

I am using Access 2002. I have considerable experience with Excel and VBA but
very little with Access.

My problem is with SetFocus. I have a main form and a subform. I shift the
focus to the subform and after some processing I am trying to set the focus
back to a control on the main form. However, I get an error 2110. (Microsoft
Access can’t move the focus to this control.)

After considerable testing, the SetFocus appeared to be working even though
I was still getting the error message.

I tried OnError Resume Next to suppress the Error message and now it works
fine. However, I would like to know if anyone can give me any advice. Perhaps
I should be including some other code first.

This is the code. (I have tried with and without the first 3 lines and they
make no difference.)

Forms!NameAndAddress.Visible = True
Forms!NameAndAddress.SetFocus
Forms!NameAndAddress.Repaint
On Error Resume Next
Forms!NameAndAddress![Post Code].SetFocus
On Error GoTo 0

Have also tried the following without success using both with and without
the error message suppressing. Doesn’t work with either method.

Forms!NameAndAddress.Visible = True
Forms!NameAndAddress.SetFocus
Forms!NameAndAddress.Repaint
DoCmd.GoToControl [Post Code]

Will very much appreciate any help.

Regards,

OssieMac

 

[Guest]

Hello OssieMac,

While I do not have an answer for you (I too am having difficulty with
SetFocus) I do have a related question for you. I am not as knowledgable
with VB as I would like to be and was hoping you could recommend a good
training source?

Lynn

 

[Dirk Goldgar]

I am using Access 2002. I have considerable experience with Excel and
VBA but very little with Access.

My problem is with SetFocus. I have a main form and a subform. I
shift the focus to the subform and after some processing I am trying
to set the focus back to a control on the main form. However, I get
an error 2110. (Microsoft Access can't move the focus to this
control.)

After considerable testing, the SetFocus appeared to be working even
though I was still getting the error message.

I tried OnError Resume Next to suppress the Error message and now it
works fine. However, I would like to know if anyone can give me any
advice. Perhaps I should be including some other code first.

This is the code. (I have tried with and without the first 3 lines
and they make no difference.)

Forms!NameAndAddress.Visible = True
Forms!NameAndAddress.SetFocus
Forms!NameAndAddress.Repaint
On Error Resume Next
Forms!NameAndAddress![Post Code].SetFocus
On Error GoTo 0

Have also tried the following without success using both with and
without the error message suppressing. Doesn't work with either
method.

Forms!NameAndAddress.Visible = True
Forms!NameAndAddress.SetFocus
Forms!NameAndAddress.Repaint
DoCmd.GoToControl [Post Code]

In what event are you executing this code? You say you shift the focus
to the subform, do some processing, and then are trying to set it back
to the main form. Do you mean you are doing all that in one procedure,
or is that just a rough summary of the sequence of operations?
Normally, I'd expect a simple

Me.Parent![Post Code].SetFocus

(executed from the subform) to work. Could you explain a bit more about
exactly what your code is doing? What is the actual sequence of events?

 

[Guest]

Dirk, Mike and Lyn,

First of all thanks for all the replies and Dirk, I don't know what you mean
by your comment on the bottom to "(please reply to the newsgroup)". The only
way I know how to reply is on this forum.
Anyhow I now feel somewhat ridiculous and stupid for not realising earlier
what the problem was but I seemed to just get stuck in a rut. Dirk's comments
made me think a bit more laterally and the problem was a recursive event
call. The procedure is called by the Enter event of of course when I try to
reset the focus to the same control the Enter event runs again. Solution is
simple enough. Finished with the Post Code so set the focus to the next
control on the form and problem solved.

For Lyn,
Can't recommend anything in particular. Where I live we have free libraries
and I frequently get books from there. Can't recommend any one book as my
knowledge has come from many books and hours of experimenting and testing and
then there is always this forum.

Regards,

OssieMac

I am using Access 2002. I have considerable experience with Excel and
VBA but very little with Access.

My problem is with SetFocus. I have a main form and a subform. I
shift the focus to the subform and after some processing I am trying
to set the focus back to a control on the main form. However, I get
an error 2110. (Microsoft Access can't move the focus to this
control.)

After considerable testing, the SetFocus appeared to be working even
though I was still getting the error message.

I tried OnError Resume Next to suppress the Error message and now it
works fine. However, I would like to know if anyone can give me any
advice. Perhaps I should be including some other code first.

This is the code. (I have tried with and without the first 3 lines
and they make no difference.)

Forms!NameAndAddress.Visible = True
Forms!NameAndAddress.SetFocus
Forms!NameAndAddress.Repaint
On Error Resume Next
Forms!NameAndAddress![Post Code].SetFocus
On Error GoTo 0

Have also tried the following without success using both with and
without the error message suppressing. Doesn't work with either
method.

Forms!NameAndAddress.Visible = True
Forms!NameAndAddress.SetFocus
Forms!NameAndAddress.Repaint
DoCmd.GoToControl [Post Code]

In what event are you executing this code? You say you shift the focus
to the subform, do some processing, and then are trying to set it back
to the main form. Do you mean you are doing all that in one procedure,
or is that just a rough summary of the sequence of operations?
Normally, I'd expect a simple

Me.Parent![Post Code].SetFocus

(executed from the subform) to work. Could you explain a bit more about
exactly what your code is doing? What is the actual sequence of events?

--
Dirk Goldgar, MS Access MVP
www.datagnostics.com

(please reply to the newsgroup)

 

[Dirk Goldgar]

Dirk, Mike and Lyn,

First of all thanks for all the replies and Dirk, I don't know what
you mean by your comment on the bottom to "(please reply to the
newsgroup)". The only way I know how to reply is on this forum.

These particular web forums are just a shell (with some additional
functionality) grafted on top of what are traditionally known as
"newsgroups" -- bulletin boards supported by NNTP (Network News Transfer
Protocol). You can read a bit more about it here on Wikipedia:

http://en.wikipedia.org/wiki/Network_News_Transfer_Protocol

Newsgroups existed (the Microsoft-hosted ones along with more general
public newsgroups) long before Microsoft made them available via a web
interface.

Most of us who post a lot don't use the web forums, but use newsreader
programs (Outlook Express is one, but there are many others) instead.
They are a lot faster than the web interface. Each of these approaches
has functionality that the other lacks, but for my personal use I much
prefer using a newsreader to using the web interface, which seems much
more cumbersome to me.

When I say in my sig, "Please reply to the newsgroup", all I mean is
that replies should be kept in the discussion forum, regardless of how
you access that forum, whether by web or newsreader -- and not e-mailed
to me directly. Maybe I should revise my sig, since now there are a
whole lot of people who aren't aware that these forums are a newsgroup.

[...] the problem
was a recursive event call. The procedure is called by the Enter
event of of course when I try to reset the focus to the same control
the Enter event runs again. Solution is simple enough. Finished with
the Post Code so set the focus to the next control on the form and
problem solved.

That makes sense. It's a bit unusual, though, to need to be setting the
focus hither and yon. Most things you might want to do don't involved
changing the current focus. Would you care to explain why you're doing
it?

 

[Guest]

Dirk,
Explanation as requested. Down Under in Aussieland we have a situation with
post codes where there can be multiple post codes for the same City/State.
(eg. Large cities have one code for an actual street address and a different
one if addressed to a post office box and further additional postcodes for
some large businesses).

Therefore where there are multiple post codes it needs human intervention to
decide which postcode to use based on street address or post office box and
in some cases the business name.

I have the post codes table linked to a subform and filtered to the ones
matching the city/state. The system automatically allocates a post code (The
first one matching the city/state in the filtered list).

I am using Dcount to assess the number of available postcodes for the
city/state. If it returns 1 as it does in most cases then no more to do and
move to the next field on the parent form withoput even displaying the
subform. If it returns > 1 then set the post code form visible and request
the user to select the correct one which of course takes the focus away from
the main form. I want the user to be able to simply click on the correct
postcode and continue entering data on the parent form.

I use the Entry event on the parent form post code field to initiate the
test for number of post codes and Entry event again on the subform post code
field to initiate resetting focus back to the parent form.

And yes I have considered the possibility of a separate address field for
post office boxes and even identifying the business name but there are other
problems associated with doing that which I might or might not address in the
future. The number of entries in that category is minimal considering that it
only applies to the central business district of the cities and all the
suburbs in the cities have their own postcodes.

Regards,

OssieMac

Dirk, Mike and Lyn,

First of all thanks for all the replies and Dirk, I don't know what
you mean by your comment on the bottom to "(please reply to the
newsgroup)". The only way I know how to reply is on this forum.

These particular web forums are just a shell (with some additional
functionality) grafted on top of what are traditionally known as
"newsgroups" -- bulletin boards supported by NNTP (Network News Transfer
Protocol). You can read a bit more about it here on Wikipedia:

http://en.wikipedia.org/wiki/Network_News_Transfer_Protocol

Newsgroups existed (the Microsoft-hosted ones along with more general
public newsgroups) long before Microsoft made them available via a web
interface.

Most of us who post a lot don't use the web forums, but use newsreader
programs (Outlook Express is one, but there are many others) instead.
They are a lot faster than the web interface. Each of these approaches
has functionality that the other lacks, but for my personal use I much
prefer using a newsreader to using the web interface, which seems much
more cumbersome to me.

When I say in my sig, "Please reply to the newsgroup", all I mean is
that replies should be kept in the discussion forum, regardless of how
you access that forum, whether by web or newsreader -- and not e-mailed
to me directly. Maybe I should revise my sig, since now there are a
whole lot of people who aren't aware that these forums are a newsgroup.

[...] the problem
was a recursive event call. The procedure is called by the Enter
event of of course when I try to reset the focus to the same control
the Enter event runs again. Solution is simple enough. Finished with
the Post Code so set the focus to the next control on the form and
problem solved.

That makes sense. It's a bit unusual, though, to need to be setting the
focus hither and yon. Most things you might want to do don't involved
changing the current focus. Would you care to explain why you're doing
it?

--
Dirk Goldgar, MS Access MVP
www.datagnostics.com

(please reply to the newsgroup -- or forum, or whatever)

 

[Dirk Goldgar]

Dirk,
Explanation as requested. Down Under in Aussieland we have a
situation with post codes where there can be multiple post codes for
the same City/State. (eg. Large cities have one code for an actual
street address and a different one if addressed to a post office box
and further additional postcodes for some large businesses).

Therefore where there are multiple post codes it needs human
intervention to decide which postcode to use based on street address
or post office box and in some cases the business name.

I have the post codes table linked to a subform and filtered to the
ones matching the city/state. The system automatically allocates a
post code (The first one matching the city/state in the filtered
list).

I am using Dcount to assess the number of available postcodes for the
city/state. If it returns 1 as it does in most cases then no more to
do and move to the next field on the parent form withoput even
displaying the subform. If it returns > 1 then set the post code form
visible and request the user to select the correct one which of
course takes the focus away from the main form. I want the user to be
able to simply click on the correct postcode and continue entering
data on the parent form.

I use the Entry event on the parent form post code field to initiate
the test for number of post codes and Entry event again on the
subform post code field to initiate resetting focus back to the
parent form.

And yes I have considered the possibility of a separate address field
for post office boxes and even identifying the business name but
there are other problems associated with doing that which I might or
might not address in the future. The number of entries in that
category is minimal considering that it only applies to the central
business district of the cities and all the suburbs in the cities
have their own postcodes.

I see what you're doing, and why you're doing it. It seems reasonable,
but ...

If all the subform is doing is displaying a list of appropriate post
codes and allowing the user to select one, I think I'd be inclined to
use a list box instead of a subform, with the control's rowsource set to
reference the city/state field on the form as a criterion. I'd probably
use the AfterUpdate event of the city/state field to requery the list
box, and at that point the listbox's ListCount property would tell me
how many matching post codes there were, thus eliminating the need for a
separate DCount.

One could easily default the post code text box to the first item in the
list box, and only show the the list box if there's more than one.
Furthermore, one could bind the list box to the same post code field
that the text box is bound to, so that no additional code is necessary
to update the field with the selection. You could use the AfterUpdate
event of the list box to move the focus on to the next field, and then
hide the list box.

 

[Guest]

Dirk,

Thankyou ever so much for your assistance. It's all good advice and very
helpful. Your latest as given me another perspective on alternative options
that I can use, particularly with the Afterupdate property. I will also be
checking out the Network News Transfer Protocol that you told me about.

So thanks again and kind regards,

OssieMac