tabbing out of a subform without knowing about the parent

[Michael Fay]

There have been threads in this newsgroup explaining how to
tab out of a subform to the parent form -- without having to
use ctrl-tab (of which users might be unaware -- and at any
rate, they shouldn't have to know that part of a form is
a "subform").

I use a common subform among two main forms, so those solutions
won't work -- because the "next control" depends on who the
parent is. And even if I write fancy code to detect which
parent I have, the subform code will break if I change the
parent's next control.

Here's my brilliant idea, which doesn't work: on the
last control of the subform, check KeyDown and change
TAB to CTRL+TAB, in hopes that Access will recognize it.

Private Sub <LASTCONTROL>_KeyDown(KeyCode As Integer, Shift As Integer)
If KeyCode = vbKeyTab And Shift <> 1 Then
Shift = 2 ' change ordinary tab (or ctrl-tab) to ctrl-tab
to get out of subform
End If
End Sub

Alas, this does nothing; TAB cycles within the subform.
Maybe KeyDown simply can't pass CTRL+TAB to Access. But, if
if anybody sees a flaw in my code, please post it and we'll
have a wonderful way to TAB our way out of subforms!

Note: you'd have to do a similar check for SHIFT+TAB out of
the *first* control of the subform.

[Tom van Stiphout]

On 8 Apr 2005 14:03:40 -0700, "Michael Fay" <fa*@acm.org> wrote:

Interesting idea.
Try using SendKeys instead.

-Tom.

There have been threads in this newsgroup explaining how to
tab out of a subform to the parent form -- without having to
use ctrl-tab (of which users might be unaware -- and at any
rate, they shouldn't have to know that part of a form is
a "subform").

I use a common subform among two main forms, so those solutions
won't work -- because the "next control" depends on who the
parent is. And even if I write fancy code to detect which
parent I have, the subform code will break if I change the
parent's next control.

Here's my brilliant idea, which doesn't work: on the
last control of the subform, check KeyDown and change
TAB to CTRL+TAB, in hopes that Access will recognize it.

Private Sub <LASTCONTROL>_KeyDown(KeyCode As Integer, Shift As Integer)
If KeyCode = vbKeyTab And Shift <> 1 Then
Shift = 2 ' change ordinary tab (or ctrl-tab) to ctrl-tab
to get out of subform
End If
End Sub

Alas, this does nothing; TAB cycles within the subform.
Maybe KeyDown simply can't pass CTRL+TAB to Access. But, if
if anybody sees a flaw in my code, please post it and we'll
have a wonderful way to TAB our way out of subforms!

Note: you'd have to do a similar check for SHIFT+TAB out of
the *first* control of the subform.

[Michael Fay]

Tom -- SendKeys works! (Mostly.) Now we're close. I fixed the Shift
mask checking and put in SendKeys calls for both the first and last
controls:

Private Sub <LASTCONTROL>_KeyDown(KeyCode As Integer, Shift As Integer)
If KeyCode = vbKeyTab And ((Shift And acShiftMask) = 0) Then
SendKeys "^{TAB}" ' ctrl-tab moves out to the parent form!
End If
End Sub
Private Sub <FIRSTCONTROL>_KeyDown(KeyCode As Integer, Shift As
Integer)
If (KeyCode = vbKeyTab) And ((Shift And acShiftMask) > 0) Then
SendKeys "^+{TAB}" ' ctrl-shift-tab moves out backwards to
the parent form!
End If
End Sub

A problem remains: if you TAB your way out to the parent, then
immediately SHIFT-TAB back in, focus passes to the *first* control of
the subform, not the last one. I tried to fool Access with a .SetFocus
call before the SendKeys, but to no avail. Can anyone fix this? The
analogous problem occurs with SHIFT-TAB from the first control,
followed by TAB back in (to the last control).

Folks, if we can get this working perfectly it would make subforms
quite desirable in a number of circumstances:
- common portions of several main forms
- a subform can be attached to a different table from the main form --
in effect you are attaching to two tables, which is impossible
otherwise (without a bunch of awkward code, e.g. copying to a "hidden"
form).

[John Mishefske]

Michael Fay wrote:

Tom -- SendKeys works! (Mostly.) Now we're close. I fixed the Shift
mask checking and put in SendKeys calls for both the first and last
controls:

Private Sub <LASTCONTROL>_KeyDown(KeyCode As Integer, Shift As Integer)
If KeyCode = vbKeyTab And ((Shift And acShiftMask) = 0) Then
SendKeys "^{TAB}" ' ctrl-tab moves out to the parent form!
End If
End Sub
Private Sub <FIRSTCONTROL>_KeyDown(KeyCode As Integer, Shift As
Integer)
If (KeyCode = vbKeyTab) And ((Shift And acShiftMask) > 0) Then
SendKeys "^+{TAB}" ' ctrl-shift-tab moves out backwards to
the parent form!
End If
End Sub

A problem remains: if you TAB your way out to the parent, then
immediately SHIFT-TAB back in, focus passes to the *first* control of
the subform, not the last one. I tried to fool Access with a .SetFocus
call before the SendKeys, but to no avail. Can anyone fix this? The
analogous problem occurs with SHIFT-TAB from the first control,
followed by TAB back in (to the last control).

Folks, if we can get this working perfectly it would make subforms
quite desirable in a number of circumstances:
- common portions of several main forms
- a subform can be attached to a different table from the main form --
in effect you are attaching to two tables, which is impossible
otherwise (without a bunch of awkward code, e.g. copying to a "hidden"
form).

There might be an easy safer way to do this. Create a small text box
control on the subform, name it "txtSentry" or some such and make it
last in the tab order. Make it without a border and forecolor/backcolor
to match the Section's values.

Then add code to set focus to the parent for and then some control on
the parent form (I used txtName in this example):

Private Sub txtSentry_GotFocus()

Me.Parent.Form.SetFocus
Me.Parent.Form!txtName.SetFocus

End Sub

--
'---------------
'John Mishefske
'---------------

[Michael Fay]

But this has the drawback of putting code in the subform that knows the
name of the next control in the parent form; I was trying to avoid that
kind of dependency.

Also, it looks like you couldn't shift-tab backwards across txtSentry.

This is tricky, isn't it?
- Mike Fay