Returning Focus to Main Form

[Neil Ginsberg]

OK, this is a stupid thing, but I can't seem to get this to work. I have a
form with a subform (in continuous form view). A combo box on the main form
has code in the AfterUpdate event which adds a record to the subform (based
on the value of the combo box) and requeries the subform control. I want the
focus to return to the combo box on the main form when it's done, but I
can't get it to do so if the user enters a value and presses Enter (which
tabs to the next control, which is the subform). I've tried:

Me.SetFocus
Me.MyCombo.SetF ocus

which doesn't seem to work. Any ideas?

Thanks,

Neil

[Ken Snell [MVP]]

Re: Returning Focus to Main Form

I think you're setting yourself up for some failure here. How will your code
let the user leave the textbox at all if you intercept a focus move and
don't let the focus go elsewhere? If you put code on the textbox to stop the
focus move, that is what will happen.

You could use the Exit event to intercept the focus move, but that will
happen whenever the user tries to leave the textbox.

Even if you trap to determine if the Enter key was pressed, and stop the
focus move only if that key is pressed (in other words, let the user move
the focus if he/she presses Tab key or clicks into another control), but I
would think that your users will get very tired of having to remember that
the Enter key won't work to move along for just that one control on the
form.

I suggest that you think of a different approach for what you want to
achieve.

--

Ken Snell
<MS ACCESS MVP>


"Neil Ginsberg" <nrg@nrgconsult .com> wrote in message
news:4i8Pd.6117 $mG6.2386@newsr ead1.news.pas.e arthlink.net...[color=blue]
> OK, this is a stupid thing, but I can't seem to get this to work. I have a
> form with a subform (in continuous form view). A combo box on the main
> form has code in the AfterUpdate event which adds a record to the subform
> (based on the value of the combo box) and requeries the subform control. I
> want the focus to return to the combo box on the main form when it's done,
> but I can't get it to do so if the user enters a value and presses Enter
> (which tabs to the next control, which is the subform). I've tried:
>
> Me.SetFocus
> Me.MyCombo.SetF ocus
>
> which doesn't seem to work. Any ideas?
>
> Thanks,
>
> Neil
>[/color]

[Neil Ginsberg]

Re: Returning Focus to Main Form

See below.

"Ken Snell [MVP]" <kthsneisllis9@ ncoomcastt.rena etl> wrote in message
news:%23c6JpuHE FHA.3928@TK2MSF TNGP15.phx.gbl. ..[color=blue]
>I think you're setting yourself up for some failure here. How will your
>code let the user leave the textbox at all if you intercept a focus move
>and don't let the focus go elsewhere?[/color]

If you mean that the user will never be able to leave the combo box with
what I'm doing, that's not true. It's only in the AfterUpdate event that I
want to move the focus back to the combo box. Thus, if the user enters a
value and hits Enter, the result is that the focus is back in the combo box.
If the user is just tabbing through the controls, pressing Enter or Tab,
they can leave it fine. No code is activated.
[color=blue]
> If you put code on the textbox to stop the focus move, that is what will
> happen.[/color]

Again, just in AfterUpdate.
[color=blue]
>
> You could use the Exit event to intercept the focus move, but that will
> happen whenever the user tries to leave the textbox.[/color]

Not what I want.
[color=blue]
>
> Even if you trap to determine if the Enter key was pressed, and stop the
> focus move only if that key is pressed (in other words, let the user move
> the focus if he/she presses Tab key or clicks into another control), but I
> would think that your users will get very tired of having to remember that
> the Enter key won't work to move along for just that one control on the
> form.[/color]

Again, don't want that. Just AfterUpdate.
[color=blue]
>
> I suggest that you think of a different approach for what you want to
> achieve.[/color]

Hopefully my above notes have clarified what I'm trying to do here.

Neil
[color=blue]
>
> --
>
> Ken Snell
> <MS ACCESS MVP>
>
>
> "Neil Ginsberg" <nrg@nrgconsult .com> wrote in message
> news:4i8Pd.6117 $mG6.2386@newsr ead1.news.pas.e arthlink.net...[color=green]
>> OK, this is a stupid thing, but I can't seem to get this to work. I have
>> a form with a subform (in continuous form view). A combo box on the main
>> form has code in the AfterUpdate event which adds a record to the subform
>> (based on the value of the combo box) and requeries the subform control.
>> I want the focus to return to the combo box on the main form when it's
>> done, but I can't get it to do so if the user enters a value and presses
>> Enter (which tabs to the next control, which is the subform). I've tried:
>>
>> Me.SetFocus
>> Me.MyCombo.SetF ocus
>>
>> which doesn't seem to work. Any ideas?
>>
>> Thanks,
>>
>> Neil
>>[/color]
>
>[/color]

[Ken Snell [MVP]]

Re: Returning Focus to Main Form

OK. Put a hidden textbox on the form -- name it txtNoGo. Set its
DefaultValue to 0.

In your textbox's AfterUpdate event, use this code:

Private Sub TextBoxName_Aft erUpdate()
Me.txtNoGo = 1
End Sub


In the textbox's Exit event, use this code:

Private Sub TextBoxName_Exi t(Cancel As Integer)
If Me.txtNoGo = 1 Then
Me.txtNoGo = 0
Cancel = True
End If

This will use a hidden textbox as a flag to know that you've updated the
textbox's value and that the focus should not move.

--

Ken Snell
<MS ACCESS MVP>


"Neil Ginsberg" <nrg@nrgconsult .com> wrote in message
news:kd9Pd.6303 $UX3.4974@newsr ead3.news.pas.e arthlink.net...[color=blue]
> See below.
>
> "Ken Snell [MVP]" <kthsneisllis9@ ncoomcastt.rena etl> wrote in message
> news:%23c6JpuHE FHA.3928@TK2MSF TNGP15.phx.gbl. ..[color=green]
>>I think you're setting yourself up for some failure here. How will your
>>code let the user leave the textbox at all if you intercept a focus move
>>and don't let the focus go elsewhere?[/color]
>
> If you mean that the user will never be able to leave the combo box with
> what I'm doing, that's not true. It's only in the AfterUpdate event that I
> want to move the focus back to the combo box. Thus, if the user enters a
> value and hits Enter, the result is that the focus is back in the combo
> box. If the user is just tabbing through the controls, pressing Enter or
> Tab, they can leave it fine. No code is activated.
>[color=green]
>> If you put code on the textbox to stop the focus move, that is what will
>> happen.[/color]
>
> Again, just in AfterUpdate.
>[color=green]
>>
>> You could use the Exit event to intercept the focus move, but that will
>> happen whenever the user tries to leave the textbox.[/color]
>
> Not what I want.
>[color=green]
>>
>> Even if you trap to determine if the Enter key was pressed, and stop the
>> focus move only if that key is pressed (in other words, let the user move
>> the focus if he/she presses Tab key or clicks into another control), but
>> I would think that your users will get very tired of having to remember
>> that the Enter key won't work to move along for just that one control on
>> the form.[/color]
>
> Again, don't want that. Just AfterUpdate.
>[color=green]
>>
>> I suggest that you think of a different approach for what you want to
>> achieve.[/color]
>
> Hopefully my above notes have clarified what I'm trying to do here.
>
> Neil
>[color=green]
>>
>> --
>>
>> Ken Snell
>> <MS ACCESS MVP>
>>
>>
>> "Neil Ginsberg" <nrg@nrgconsult .com> wrote in message
>> news:4i8Pd.6117 $mG6.2386@newsr ead1.news.pas.e arthlink.net...[color=darkred]
>>> OK, this is a stupid thing, but I can't seem to get this to work. I have
>>> a form with a subform (in continuous form view). A combo box on the main
>>> form has code in the AfterUpdate event which adds a record to the
>>> subform (based on the value of the combo box) and requeries the subform
>>> control. I want the focus to return to the combo box on the main form
>>> when it's done, but I can't get it to do so if the user enters a value
>>> and presses Enter (which tabs to the next control, which is the
>>> subform). I've tried:
>>>
>>> Me.SetFocus
>>> Me.MyCombo.SetF ocus
>>>
>>> which doesn't seem to work. Any ideas?
>>>
>>> Thanks,
>>>
>>> Neil
>>>[/color]
>>
>>[/color]
>
>[/color]

[Ken Snell [MVP]]

Re: Returning Focus to Main Form

FYI... I note that I mistakenly referred to your control as a textbox in my
replies. Code will work for combo box as well.


--

Ken Snell
<MS ACCESS MVP>

"Neil Ginsberg" <nrg@nrgconsult .com> wrote in message
news:kd9Pd.6303 $UX3.4974@newsr ead3.news.pas.e arthlink.net...[color=blue]
> See below.
>
> "Ken Snell [MVP]" <kthsneisllis9@ ncoomcastt.rena etl> wrote in message
> news:%23c6JpuHE FHA.3928@TK2MSF TNGP15.phx.gbl. ..[color=green]
>>I think you're setting yourself up for some failure here. How will your
>>code let the user leave the textbox at all if you intercept a focus move
>>and don't let the focus go elsewhere?[/color]
>
> If you mean that the user will never be able to leave the combo box with
> what I'm doing, that's not true. It's only in the AfterUpdate event that I
> want to move the focus back to the combo box. Thus, if the user enters a
> value and hits Enter, the result is that the focus is back in the combo
> box. If the user is just tabbing through the controls, pressing Enter or
> Tab, they can leave it fine. No code is activated.
>[color=green]
>> If you put code on the textbox to stop the focus move, that is what will
>> happen.[/color]
>
> Again, just in AfterUpdate.
>[color=green]
>>
>> You could use the Exit event to intercept the focus move, but that will
>> happen whenever the user tries to leave the textbox.[/color]
>
> Not what I want.
>[color=green]
>>
>> Even if you trap to determine if the Enter key was pressed, and stop the
>> focus move only if that key is pressed (in other words, let the user move
>> the focus if he/she presses Tab key or clicks into another control), but
>> I would think that your users will get very tired of having to remember
>> that the Enter key won't work to move along for just that one control on
>> the form.[/color]
>
> Again, don't want that. Just AfterUpdate.
>[color=green]
>>
>> I suggest that you think of a different approach for what you want to
>> achieve.[/color]
>
> Hopefully my above notes have clarified what I'm trying to do here.
>
> Neil
>[color=green]
>>
>> --
>>
>> Ken Snell
>> <MS ACCESS MVP>
>>
>>
>> "Neil Ginsberg" <nrg@nrgconsult .com> wrote in message
>> news:4i8Pd.6117 $mG6.2386@newsr ead1.news.pas.e arthlink.net...[color=darkred]
>>> OK, this is a stupid thing, but I can't seem to get this to work. I have
>>> a form with a subform (in continuous form view). A combo box on the main
>>> form has code in the AfterUpdate event which adds a record to the
>>> subform (based on the value of the combo box) and requeries the subform
>>> control. I want the focus to return to the combo box on the main form
>>> when it's done, but I can't get it to do so if the user enters a value
>>> and presses Enter (which tabs to the next control, which is the
>>> subform). I've tried:
>>>
>>> Me.SetFocus
>>> Me.MyCombo.SetF ocus
>>>
>>> which doesn't seem to work. Any ideas?
>>>
>>> Thanks,
>>>
>>> Neil
>>>[/color]
>>
>>[/color]
>
>[/color]

[Neil Ginsberg]

Re: Returning Focus to Main Form

Understood.

"Ken Snell [MVP]" <kthsneisllis9@ ncoomcastt.rena etl> wrote in message
news:%23FC9XJIE FHA.3732@TK2MSF TNGP14.phx.gbl. ..[color=blue]
> FYI... I note that I mistakenly referred to your control as a textbox in
> my replies. Code will work for combo box as well.
>
>
> --
>
> Ken Snell
> <MS ACCESS MVP>
>
> "Neil Ginsberg" <nrg@nrgconsult .com> wrote in message
> news:kd9Pd.6303 $UX3.4974@newsr ead3.news.pas.e arthlink.net...[color=green]
>> See below.
>>
>> "Ken Snell [MVP]" <kthsneisllis9@ ncoomcastt.rena etl> wrote in message
>> news:%23c6JpuHE FHA.3928@TK2MSF TNGP15.phx.gbl. ..[color=darkred]
>>>I think you're setting yourself up for some failure here. How will your
>>>code let the user leave the textbox at all if you intercept a focus move
>>>and don't let the focus go elsewhere?[/color]
>>
>> If you mean that the user will never be able to leave the combo box with
>> what I'm doing, that's not true. It's only in the AfterUpdate event that
>> I want to move the focus back to the combo box. Thus, if the user enters
>> a value and hits Enter, the result is that the focus is back in the combo
>> box. If the user is just tabbing through the controls, pressing Enter or
>> Tab, they can leave it fine. No code is activated.
>>[color=darkred]
>>> If you put code on the textbox to stop the focus move, that is what
>>> will happen.[/color]
>>
>> Again, just in AfterUpdate.
>>[color=darkred]
>>>
>>> You could use the Exit event to intercept the focus move, but that will
>>> happen whenever the user tries to leave the textbox.[/color]
>>
>> Not what I want.
>>[color=darkred]
>>>
>>> Even if you trap to determine if the Enter key was pressed, and stop the
>>> focus move only if that key is pressed (in other words, let the user
>>> move the focus if he/she presses Tab key or clicks into another
>>> control), but I would think that your users will get very tired of
>>> having to remember that the Enter key won't work to move along for just
>>> that one control on the form.[/color]
>>
>> Again, don't want that. Just AfterUpdate.
>>[color=darkred]
>>>
>>> I suggest that you think of a different approach for what you want to
>>> achieve.[/color]
>>
>> Hopefully my above notes have clarified what I'm trying to do here.
>>
>> Neil
>>[color=darkred]
>>>
>>> --
>>>
>>> Ken Snell
>>> <MS ACCESS MVP>
>>>
>>>
>>> "Neil Ginsberg" <nrg@nrgconsult .com> wrote in message
>>> news:4i8Pd.6117 $mG6.2386@newsr ead1.news.pas.e arthlink.net...
>>>> OK, this is a stupid thing, but I can't seem to get this to work. I
>>>> have a form with a subform (in continuous form view). A combo box on
>>>> the main form has code in the AfterUpdate event which adds a record to
>>>> the subform (based on the value of the combo box) and requeries the
>>>> subform control. I want the focus to return to the combo box on the
>>>> main form when it's done, but I can't get it to do so if the user
>>>> enters a value and presses Enter (which tabs to the next control, which
>>>> is the subform). I've tried:
>>>>
>>>> Me.SetFocus
>>>> Me.MyCombo.SetF ocus
>>>>
>>>> which doesn't seem to work. Any ideas?
>>>>
>>>> Thanks,
>>>>
>>>> Neil
>>>>
>>>
>>>[/color]
>>
>>[/color]
>
>[/color]

[Neil Ginsberg]

Re: Returning Focus to Main Form

Interesting approach. You'd think it would be possible to do it directly in
code. I seem to recall in the past that I was able to do that, by just using
SetFocus. I don't know if I'm remembering wrongly, or if something's
changed.

In any case, your solution works fine in the case where the user presses
Enter after entering a value. But it has problems in other scenarios:

* If the user uses the mouse to select a value from the combo box and then
presses Enter to leave the combo box , the focus stays in the combo box.

* Similarly, if the user uses the mouse to select a value and then clicks a
command button or tries to go to a new record, they are still stuck there
for at least one time.

Perhaps something in the KeyPress event, instead of Exit, would work? (Still
seems there should be a more direct approach....)

Thanks,

Neil



"Ken Snell [MVP]" <kthsneisllis9@ ncoomcastt.rena etl> wrote in message
news:eYiWvIIEFH A.2676@TK2MSFTN GP12.phx.gbl...[color=blue]
> OK. Put a hidden textbox on the form -- name it txtNoGo. Set its
> DefaultValue to 0.
>
> In your textbox's AfterUpdate event, use this code:
>
> Private Sub TextBoxName_Aft erUpdate()
> Me.txtNoGo = 1
> End Sub
>
>
> In the textbox's Exit event, use this code:
>
> Private Sub TextBoxName_Exi t(Cancel As Integer)
> If Me.txtNoGo = 1 Then
> Me.txtNoGo = 0
> Cancel = True
> End If
>
> This will use a hidden textbox as a flag to know that you've updated the
> textbox's value and that the focus should not move.
>
> --
>
> Ken Snell
> <MS ACCESS MVP>
>
>
> "Neil Ginsberg" <nrg@nrgconsult .com> wrote in message
> news:kd9Pd.6303 $UX3.4974@newsr ead3.news.pas.e arthlink.net...[color=green]
>> See below.
>>
>> "Ken Snell [MVP]" <kthsneisllis9@ ncoomcastt.rena etl> wrote in message
>> news:%23c6JpuHE FHA.3928@TK2MSF TNGP15.phx.gbl. ..[color=darkred]
>>>I think you're setting yourself up for some failure here. How will your
>>>code let the user leave the textbox at all if you intercept a focus move
>>>and don't let the focus go elsewhere?[/color]
>>
>> If you mean that the user will never be able to leave the combo box with
>> what I'm doing, that's not true. It's only in the AfterUpdate event that
>> I want to move the focus back to the combo box. Thus, if the user enters
>> a value and hits Enter, the result is that the focus is back in the combo
>> box. If the user is just tabbing through the controls, pressing Enter or
>> Tab, they can leave it fine. No code is activated.
>>[color=darkred]
>>> If you put code on the textbox to stop the focus move, that is what
>>> will happen.[/color]
>>
>> Again, just in AfterUpdate.
>>[color=darkred]
>>>
>>> You could use the Exit event to intercept the focus move, but that will
>>> happen whenever the user tries to leave the textbox.[/color]
>>
>> Not what I want.
>>[color=darkred]
>>>
>>> Even if you trap to determine if the Enter key was pressed, and stop the
>>> focus move only if that key is pressed (in other words, let the user
>>> move the focus if he/she presses Tab key or clicks into another
>>> control), but I would think that your users will get very tired of
>>> having to remember that the Enter key won't work to move along for just
>>> that one control on the form.[/color]
>>
>> Again, don't want that. Just AfterUpdate.
>>[color=darkred]
>>>
>>> I suggest that you think of a different approach for what you want to
>>> achieve.[/color]
>>
>> Hopefully my above notes have clarified what I'm trying to do here.
>>
>> Neil
>>[color=darkred]
>>>
>>> --
>>>
>>> Ken Snell
>>> <MS ACCESS MVP>
>>>
>>>
>>> "Neil Ginsberg" <nrg@nrgconsult .com> wrote in message
>>> news:4i8Pd.6117 $mG6.2386@newsr ead1.news.pas.e arthlink.net...
>>>> OK, this is a stupid thing, but I can't seem to get this to work. I
>>>> have a form with a subform (in continuous form view). A combo box on
>>>> the main form has code in the AfterUpdate event which adds a record to
>>>> the subform (based on the value of the combo box) and requeries the
>>>> subform control. I want the focus to return to the combo box on the
>>>> main form when it's done, but I can't get it to do so if the user
>>>> enters a value and presses Enter (which tabs to the next control, which
>>>> is the subform). I've tried:
>>>>
>>>> Me.SetFocus
>>>> Me.MyCombo.SetF ocus
>>>>
>>>> which doesn't seem to work. Any ideas?
>>>>
>>>> Thanks,
>>>>
>>>> Neil
>>>>
>>>
>>>[/color]
>>
>>[/color]
>
>[/color]

[Lyle Fairfield]

Re: Returning Focus to Main Form

Neil Ginsberg wrote:[color=blue]
> Interesting approach. You'd think it would be possible to do it directly in
> code.[/color]

The Windows API SetFocus is sometimes a bit more responsive than the
Access SetFocus.

We may be able to use it as follows (mostly air ... code)

Private Declare Function SetFocusAPI _
Lib "user32" _
Alias "SetFocus" _
(ByVal hwnd As Long) _
As Long

Private Sub Label10_Click()
SetFocusAPI Form_MDACandESO .hwnd
End Sub

where MDACandESO is the name of the form to which focus is transferred.
We must use the Alias, of course, to avoid confusion with the Access
function.

In a not so thorough test of two forms this moves the focus to the form
called MDACandESO. This form must have a module for the nomenclature
Form_MDACandESO to work. I'm guessing one could use Forms("MDACandE SO")
if it doesn't have a module, but I haven't tried that.

Of course, one might want to write some error handling code if one could
not be sure that Form_MDACandESO is open, or test its state with SysCmd.

Lyle

[Ken Snell]

Re: Returning Focus to Main Form

You can only cancel the movement of the focus by cancelling the Exit or
BeforeUpdate event. You can use the GotFocus event of a subsequent control
to move the focus to another control -- perhaps that is what you're thinking
of.

The scenarios that you mention are along the lines of what I'd posted
initially. Until you can identify what is a change that should not let the
focus move and what is not a change that should not let the focus move, it's
difficult to devise a 'perfect fit' for your scenario. As I'd mentioned
previously, you could try trapping for the Enter key being pressed and use
that to decide if the flag should be set or not, along with the AfterUpdate
changes.

You'll need to figure out the exact scenarios that should move focus and/or
the ones that shouldn't, and then develop the setup to handle the form's
actions the way you wish.


--

Ken Snell
<MS ACCESS MVP>



"Neil Ginsberg" <nrg@nrgconsult .com> wrote in message
news:15bPd.6217 $mG6.5149@newsr ead1.news.pas.e arthlink.net...[color=blue]
> Interesting approach. You'd think it would be possible to do it directly
> in code. I seem to recall in the past that I was able to do that, by just
> using SetFocus. I don't know if I'm remembering wrongly, or if something's
> changed.
>
> In any case, your solution works fine in the case where the user presses
> Enter after entering a value. But it has problems in other scenarios:
>
> * If the user uses the mouse to select a value from the combo box and then
> presses Enter to leave the combo box , the focus stays in the combo box.
>
> * Similarly, if the user uses the mouse to select a value and then clicks
> a command button or tries to go to a new record, they are still stuck
> there for at least one time.
>
> Perhaps something in the KeyPress event, instead of Exit, would work?
> (Still seems there should be a more direct approach....)
>
> Thanks,
>
> Neil
>
>
>
> "Ken Snell [MVP]" <kthsneisllis9@ ncoomcastt.rena etl> wrote in message
> news:eYiWvIIEFH A.2676@TK2MSFTN GP12.phx.gbl...[color=green]
>> OK. Put a hidden textbox on the form -- name it txtNoGo. Set its
>> DefaultValue to 0.
>>
>> In your textbox's AfterUpdate event, use this code:
>>
>> Private Sub TextBoxName_Aft erUpdate()
>> Me.txtNoGo = 1
>> End Sub
>>
>>
>> In the textbox's Exit event, use this code:
>>
>> Private Sub TextBoxName_Exi t(Cancel As Integer)
>> If Me.txtNoGo = 1 Then
>> Me.txtNoGo = 0
>> Cancel = True
>> End If
>>
>> This will use a hidden textbox as a flag to know that you've updated the
>> textbox's value and that the focus should not move.
>>
>> --
>>
>> Ken Snell
>> <MS ACCESS MVP>
>>
>>
>> "Neil Ginsberg" <nrg@nrgconsult .com> wrote in message
>> news:kd9Pd.6303 $UX3.4974@newsr ead3.news.pas.e arthlink.net...[color=darkred]
>>> See below.
>>>
>>> "Ken Snell [MVP]" <kthsneisllis9@ ncoomcastt.rena etl> wrote in message
>>> news:%23c6JpuHE FHA.3928@TK2MSF TNGP15.phx.gbl. ..
>>>>I think you're setting yourself up for some failure here. How will your
>>>>code let the user leave the textbox at all if you intercept a focus move
>>>>and don't let the focus go elsewhere?
>>>
>>> If you mean that the user will never be able to leave the combo box with
>>> what I'm doing, that's not true. It's only in the AfterUpdate event that
>>> I want to move the focus back to the combo box. Thus, if the user enters
>>> a value and hits Enter, the result is that the focus is back in the
>>> combo box. If the user is just tabbing through the controls, pressing
>>> Enter or Tab, they can leave it fine. No code is activated.
>>>
>>>> If you put code on the textbox to stop the focus move, that is what
>>>> will happen.
>>>
>>> Again, just in AfterUpdate.
>>>
>>>>
>>>> You could use the Exit event to intercept the focus move, but that will
>>>> happen whenever the user tries to leave the textbox.
>>>
>>> Not what I want.
>>>
>>>>
>>>> Even if you trap to determine if the Enter key was pressed, and stop
>>>> the focus move only if that key is pressed (in other words, let the
>>>> user move the focus if he/she presses Tab key or clicks into another
>>>> control), but I would think that your users will get very tired of
>>>> having to remember that the Enter key won't work to move along for just
>>>> that one control on the form.
>>>
>>> Again, don't want that. Just AfterUpdate.
>>>
>>>>
>>>> I suggest that you think of a different approach for what you want to
>>>> achieve.
>>>
>>> Hopefully my above notes have clarified what I'm trying to do here.
>>>
>>> Neil
>>>
>>>>
>>>> --
>>>>
>>>> Ken Snell
>>>> <MS ACCESS MVP>
>>>>
>>>>
>>>> "Neil Ginsberg" <nrg@nrgconsult .com> wrote in message
>>>> news:4i8Pd.6117 $mG6.2386@newsr ead1.news.pas.e arthlink.net...
>>>>> OK, this is a stupid thing, but I can't seem to get this to work. I
>>>>> have a form with a subform (in continuous form view). A combo box on
>>>>> the main form has code in the AfterUpdate event which adds a record to
>>>>> the subform (based on the value of the combo box) and requeries the
>>>>> subform control. I want the focus to return to the combo box on the
>>>>> main form when it's done, but I can't get it to do so if the user
>>>>> enters a value and presses Enter (which tabs to the next control,
>>>>> which is the subform). I've tried:
>>>>>
>>>>> Me.SetFocus
>>>>> Me.MyCombo.SetF ocus
>>>>>
>>>>> which doesn't seem to work. Any ideas?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Neil
>>>>>
>>>>
>>>>
>>>
>>>[/color]
>>
>>[/color]
>
>[/color]

[Neil Ginsberg]

Re: Returning Focus to Main Form

Thanks for the tip. I added the code you gave to the subform, and created a
Label10 label, but there was no effect. Perhaps because the subform is part
of the main form, by setting focus to the main form we're not changing
anything?

In any case, since you said you got it to work, I'm wondering what your
setup was. Was one form a subform of the other?

Thanks,

Neil


"Lyle Fairfield" <lylefair@yahoo .ca> wrote in message
news:uRbPd.2229 1$m22.9845@read 1.cgocable.net. ..[color=blue]
> Neil Ginsberg wrote:[color=green]
>> Interesting approach. You'd think it would be possible to do it directly
>> in code.[/color]
>
> The Windows API SetFocus is sometimes a bit more responsive than the
> Access SetFocus.
>
> We may be able to use it as follows (mostly air ... code)
>
> Private Declare Function SetFocusAPI _
> Lib "user32" _
> Alias "SetFocus" _
> (ByVal hwnd As Long) _
> As Long
>
> Private Sub Label10_Click()
> SetFocusAPI Form_MDACandESO .hwnd
> End Sub
>
> where MDACandESO is the name of the form to which focus is transferred. We
> must use the Alias, of course, to avoid confusion with the Access
> function.
>
> In a not so thorough test of two forms this moves the focus to the form
> called MDACandESO. This form must have a module for the nomenclature
> Form_MDACandESO to work. I'm guessing one could use Forms("MDACandE SO") if
> it doesn't have a module, but I haven't tried that.
>
> Of course, one might want to write some error handling code if one could
> not be sure that Form_MDACandESO is open, or test its state with SysCmd.
>
> Lyle[/color]

[rkc]

Re: Returning Focus to Main Form

Neil Ginsberg wrote:[color=blue]
> See below.
>
> "Ken Snell [MVP]" <kthsneisllis9@ ncoomcastt.rena etl> wrote in message
> news:%23c6JpuHE FHA.3928@TK2MSF TNGP15.phx.gbl. ..
>[color=green]
>>I think you're setting yourself up for some failure here. How will your
>>code let the user leave the textbox at all if you intercept a focus move
>>and don't let the focus go elsewhere?[/color]
>
>
> If you mean that the user will never be able to leave the combo box with
> what I'm doing, that's not true. It's only in the AfterUpdate event that I
> want to move the focus back to the combo box. Thus, if the user enters a
> value and hits Enter, the result is that the focus is back in the combo box.
> If the user is just tabbing through the controls, pressing Enter or Tab,
> they can leave it fine. No code is activated.
>
>[color=green]
>> If you put code on the textbox to stop the focus move, that is what will
>>happen.[/color]
>
>
> Again, just in AfterUpdate.
>
>[color=green]
>>You could use the Exit event to intercept the focus move, but that will
>>happen whenever the user tries to leave the textbox.[/color]
>
>
> Not what I want.
>
>[color=green]
>>Even if you trap to determine if the Enter key was pressed, and stop the
>>focus move only if that key is pressed (in other words, let the user move
>>the focus if he/she presses Tab key or clicks into another control), but I
>>would think that your users will get very tired of having to remember that
>>the Enter key won't work to move along for just that one control on the
>>form.[/color]
>
>
> Again, don't want that. Just AfterUpdate.
>
>[color=green]
>>I suggest that you think of a different approach for what you want to
>>achieve.[/color]
>
>
> Hopefully my above notes have clarified what I'm trying to do here.
>
> Neil
>
>[color=green]
>>--
>>
>> Ken Snell
>><MS ACCESS MVP>
>>
>>
>>"Neil Ginsberg" <nrg@nrgconsult .com> wrote in message
>>news:4i8Pd.61 17$mG6.2386@new sread1.news.pas .earthlink.net. ..
>>[color=darkred]
>>>OK, this is a stupid thing, but I can't seem to get this to work. I have
>>>a form with a subform (in continuous form view). A combo box on the main
>>>form has code in the AfterUpdate event which adds a record to the subform
>>>(based on the value of the combo box) and requeries the subform control.
>>>I want the focus to return to the combo box on the main form when it's
>>>done, but I can't get it to do so if the user enters a value and presses
>>>Enter (which tabs to the next control, which is the subform). I've tried:
>>>
>>>Me.SetFocu s
>>>Me.MyCombo.S etFocus
>>>
>>>which doesn't seem to work. Any ideas?[/color][/color][/color]

<main form code>
Private m_ReturnFocus As Boolean

Private Sub YourSubForm_Ent er()
If m_ReturnFocus Then
m_ReturnFocus = False
Me.MyCombo.SetF ocus
End If
End Sub

Private Sub MyCombo_AfterUp date()
m_ReturnFocus = True
End Sub
</main form code>

[Neil Ginsberg]

Re: Returning Focus to Main Form

Thanks for the note. Problem here is that it does it for all AfterUpdates,
including those done with the mouse. Thus, if the user selects an item with
the mouse and then clicks in the subform, it wouldn't go. Need to be able to
keep it there just with Enter. If they select with the mouse, they should
then be able to click elsewhere.

Neil


"rkc" <rkc@rochester. yabba.dabba.do. rr.bomb> wrote in message
news:obePd.1196 $vK5.592@twiste r.nyroc.rr.com. ..[color=blue]
> Neil Ginsberg wrote:[color=green]
>> See below.
>>
>> "Ken Snell [MVP]" <kthsneisllis9@ ncoomcastt.rena etl> wrote in message
>> news:%23c6JpuHE FHA.3928@TK2MSF TNGP15.phx.gbl. ..
>>[color=darkred]
>>>I think you're setting yourself up for some failure here. How will your
>>>code let the user leave the textbox at all if you intercept a focus move
>>>and don't let the focus go elsewhere?[/color]
>>
>>
>> If you mean that the user will never be able to leave the combo box with
>> what I'm doing, that's not true. It's only in the AfterUpdate event that
>> I want to move the focus back to the combo box. Thus, if the user enters
>> a value and hits Enter, the result is that the focus is back in the combo
>> box. If the user is just tabbing through the controls, pressing Enter or
>> Tab, they can leave it fine. No code is activated.
>>
>>[color=darkred]
>>> If you put code on the textbox to stop the focus move, that is what will
>>> happen.[/color]
>>
>>
>> Again, just in AfterUpdate.
>>
>>[color=darkred]
>>>You could use the Exit event to intercept the focus move, but that will
>>>happen whenever the user tries to leave the textbox.[/color]
>>
>>
>> Not what I want.
>>
>>[color=darkred]
>>>Even if you trap to determine if the Enter key was pressed, and stop the
>>>focus move only if that key is pressed (in other words, let the user move
>>>the focus if he/she presses Tab key or clicks into another control), but
>>>I would think that your users will get very tired of having to remember
>>>that the Enter key won't work to move along for just that one control on
>>>the form.[/color]
>>
>>
>> Again, don't want that. Just AfterUpdate.
>>
>>[color=darkred]
>>>I suggest that you think of a different approach for what you want to
>>>achieve.[/color]
>>
>>
>> Hopefully my above notes have clarified what I'm trying to do here.
>>
>> Neil
>>
>>[color=darkred]
>>>--
>>>
>>> Ken Snell
>>><MS ACCESS MVP>
>>>
>>>
>>>"Neil Ginsberg" <nrg@nrgconsult .com> wrote in message
>>>news:4i8Pd.6 117$mG6.2386@ne wsread1.news.pa s.earthlink.net ...
>>>
>>>>OK, this is a stupid thing, but I can't seem to get this to work. I have
>>>>a form with a subform (in continuous form view). A combo box on the main
>>>>form has code in the AfterUpdate event which adds a record to the
>>>>subform (based on the value of the combo box) and requeries the subform
>>>>control. I want the focus to return to the combo box on the main form
>>>>when it's done, but I can't get it to do so if the user enters a value
>>>>and presses Enter (which tabs to the next control, which is the
>>>>subform). I've tried:
>>>>
>>>>Me.SetFoc us
>>>>Me.MyCombo. SetFocus
>>>>
>>>>which doesn't seem to work. Any ideas?[/color][/color]
>
> <main form code>
> Private m_ReturnFocus As Boolean
>
> Private Sub YourSubForm_Ent er()
> If m_ReturnFocus Then
> m_ReturnFocus = False
> Me.MyCombo.SetF ocus
> End If
> End Sub
>
> Private Sub MyCombo_AfterUp date()
> m_ReturnFocus = True
> End Sub
> </main form code>
>[/color]

[rkc]

Re: Returning Focus to Main Form

Neil Ginsberg wrote:[color=blue]
> Thanks for the note. Problem here is that it does it for all AfterUpdates,
> including those done with the mouse. Thus, if the user selects an item with
> the mouse and then clicks in the subform, it wouldn't go. Need to be able to
> keep it there just with Enter. If they select with the mouse, they should
> then be able to click elsewhere.[/color]

Your requirements seem to change with every reply.

[Neil Ginsberg]

Re: Returning Focus to Main Form

You mean noting that the solution to the problem causes problems in other
areas is a "change in requirement"? OK, then.

"rkc" <rkc@rochester. yabba.dabba.do. rr.bomb> wrote in message
news:hcgPd.1643 $vK5.1131@twist er.nyroc.rr.com ...[color=blue]
> Neil Ginsberg wrote:[color=green]
>> Thanks for the note. Problem here is that it does it for all
>> AfterUpdates, including those done with the mouse. Thus, if the user
>> selects an item with the mouse and then clicks in the subform, it
>> wouldn't go. Need to be able to keep it there just with Enter. If they
>> select with the mouse, they should then be able to click elsewhere.[/color]
>
> Your requirements seem to change with every reply.[/color]

[rkc]

Re: Returning Focus to Main Form

Neil Ginsberg wrote:[color=blue]
> You mean noting that the solution to the problem causes problems in other
> areas is a "change in requirement"? OK, then.[/color]

I mean to me it's not clear what you are trying to achieve.
I you feel it should be, O.K. then.