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.SetFocus

which doesn't seem to work. Any ideas?

Thanks,

Neil

[Ken Snell [MVP]]

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" <n...@nrgconsult.com> wrote in message
news:4i8Pd.6117$mG6....@newsread1.news.pas.earthlink.net...

[Neil Ginsberg]

See below.

"Ken Snell [MVP]" <kthsne...@ncoomcastt.renaetl> wrote in message
news:%23c6JpuH...@TK2MSFTNGP15.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 [MVP]]

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_AfterUpdate()
Me.txtNoGo = 1
End Sub

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

Private Sub TextBoxName_Exit(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" <n...@nrgconsult.com> wrote in message

news:kd9Pd.6303$UX3....@newsread3.news.pas.earthlink.net...

[Ken Snell [MVP]]

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" <n...@nrgconsult.com> wrote in message

news:kd9Pd.6303$UX3....@newsread3.news.pas.earthlink.net...

[Neil Ginsberg]

Understood.

"Ken Snell [MVP]" <kthsne...@ncoomcastt.renaetl> wrote in message

news:%23FC9XJI...@TK2MSFTNGP14.phx.gbl...

[Neil Ginsberg]

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]" <kthsne...@ncoomcastt.renaetl> wrote in message

news:eYiWvIIE...@TK2MSFTNGP12.phx.gbl...

[Lyle Fairfield]

Neil Ginsberg wrote:
> Interesting approach. You'd think it would be possible to do it directly in
> code.

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("MDACandESO")
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]

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" <n...@nrgconsult.com> wrote in message

news:15bPd.6217$mG6....@newsread1.news.pas.earthlink.net...

[Neil Ginsberg]

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" <lyle...@yahoo.ca> wrote in message
news:uRbPd.22291$m22....@read1.cgocable.net...

[rkc]

<main form code>
Private m_ReturnFocus As Boolean

Private Sub YourSubForm_Enter()
If m_ReturnFocus Then
m_ReturnFocus = False
Me.MyCombo.SetFocus
End If
End Sub

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

[Neil Ginsberg]

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" <r...@rochester.yabba.dabba.do.rr.bomb> wrote in message
news:obePd.1196$vK5...@twister.nyroc.rr.com...

[rkc]

Neil Ginsberg wrote:
> 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.

Your requirements seem to change with every reply.

[Neil Ginsberg]

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

"rkc" <r...@rochester.yabba.dabba.do.rr.bomb> wrote in message

news:hcgPd.1643$vK5....@twister.nyroc.rr.com...

[rkc]

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

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

[rkc]

O.K. Now I'm thinking all you want to be able to do is to select or
enter a value in the combobox using the Enter key without tabing to the
next control, but tab to the next control if that's not what was done.

How about this...

<Main Form>
Private m_ReturnFocus As Boolean
Private m_EnterKey As Boolean

Private Sub MyCombo_AfterUpdate()
If m_EnterKey Then
m_ReturnFocus = True
End If
End Sub

Private Sub MyCombo_KeyDown(KeyCode As Integer, Shift As Integer)
m_EnterKey = False

If KeyCode = 13 Then
m_EnterKey = True
End If

End Sub

Private Sub TheSubForm_Enter()
If m_ReturnFocus Then
Me.MyCombo.SetFocus
End If
m_ReturnFocus = False
m_EnterKey = False
End Sub
</Main Form>

[Neil Ginsberg]

OK, you're probably right in that sometimes we're not clear in what we
explain, leaving out things that are obvious. In this case, I thought it was
obvious that the use of the mouse should not be affected by the solution,
but I should have stated that.

N

"rkc" <r...@rochester.yabba.dabba.do.rr.bomb> wrote in message

news:rQnPd.3927$H05...@twister.nyroc.rr.com...

[Neil Ginsberg]

> O.K. Now I'm thinking all you want to be able to do is to select or
> enter a value in the combobox using the Enter key without tabing to the
> next control, but tab to the next control if that's not what was done.

Right, exactly! :-) And still be able to select with the mouse without the
focus being "stuck" there due to restricting it for the Enter key.

>
> How about this...

Looks like that would work. Thanks.

Neil