Tab Form navigation

[Guest]

It seems that the only way a user can navigate between pages on a tab form is
by clicking on the tabs. Is this correct, or is there a way to
programatically trap a PageDown/PageUp key for instance and display the
next/previous page (using KeyCode values)?

 

[Al Camp]

ctdak,
Naming a tab something like &First Tab would allow the user to hit Alt-F
to access that tab. A name like &Second Tab would use Alt-S.
The ampersand will cause the F and the S to be underlined, alerting the
user that Alt-whatever's underlined will access that tab... just like
Captions on buttons.

 

[Bob.Orta]

Code to move to the second tab of a tab control named TabCtl0 (not a
very meaningful name). Note that tab controls are zero based, so (1)
is the second tab....

Me.TabCtl0.Pages(1).SetFocus

Bob

 

[Guest]

Great, this is along the lines of what I was looking for. But the program
has to know which tab the user is moving from in order to move the user to
the right one (the next one with a PageDown key press for instance). Is
there a way to ascertain the user's current tab, perhaps by the tab caption
or some other tab property?

ctdak

 

[Al Camp]

ctdak,
Not true. Either method above will move to the correct tab, no matter
where you are on the main form.

 

[Guest]

I appreciate your responses, but you're missing my point. Let me be more
specific. I want to enable the PageDown key to move the user to the next
sequential tab (from whichever tab he is currently on), and to enable the
PageUp key to move the user to the previous sequential tab (from whichever
tab he is currently on). What Bob showed me earlier will only move to one
particular tab all the time. So, as I said I need a way to know the user's
current tab in order to know which tab to move him to.

ctdak

 

[Brendan Reynolds]

Private Sub TabCtl0_KeyDown(KeyCode As Integer, Shift As Integer)
Select Case KeyCode
Case vbKeyPageDown
If Me.TabCtl0.Value < Me.TabCtl0.Pages.Count - 1 Then
Me.TabCtl0.Value = Me.TabCtl0.Value + 1
Else
Me.TabCtl0.Value = 0
End If
Case vbKeyPageUp
If Me.TabCtl0.Value > 0 Then
Me.TabCtl0.Value = Me.TabCtl0.Value - 1
Else
Me.TabCtl0.Value = Me.TabCtl0.Pages.Count - 1
End If
Case Else
'do nothing
End Select
End Sub

 

[Guest]

Brendan,

Thanks for doing all the work for me. The pieces of the coding puzzle I was
missing here were the ".Value" and the ".Pages.Count". This is what I was
looking for. It works great.

Would you happen to know if the same kind of thing can be done with an
option group? In other words, is there a way for the program to know how
many option buttons exist (similar to "Pages.Count") and which option button
the user is currently on (similar to ".Value").

ctdak

 

[Brendan Reynolds]

The arrow keys navigate through the controls in an option group, no code
required.

An option group does have a Value property, which returns the Value of the
selected control within the option group. It also has a Controls property,
which returns a collection of the controls contained in the option group -
this includes labels as well as check boxes or radio buttons. The main
difficulty in adapting the code I posted to work with an option group,
though, is that an option group does not have a KeyDown event. Perhaps it
might be possible to use the form's KeyDown event (set the form's KeyPreview
property to 'Yes' before trying to use this event) and check the
ActiveControl property to determine whether one of the controls in the
option group is the active control. I wouldn't do it myself, though - not
when the arrow keys already provide the desired behaviour for free.

 

[Al Camp]

ct,
I see that Brendan has provided you a good solution...

In my first reply, I thought that I had suggested not using the PageUp/Dn
keys for functions other than the default function of navigating/moving from
record to record.
I see that I forgot to do that, and since my solution was really targeted
towards using the standard Alt-Something method of accessing tabs at will...
without that caveat, my solution appeared to be out of synch with your
question...

I would still suggest that you not "override" default Access foem key
functions. As a productivity issue, there is something to be said for
keeping all Access applications "standardized", so that users are always
presented the same form maintenance interface from one app to another.
I'm just trying to weigh the "de-standardization" of your form navigation
against the questionable convenience of "sequential" tab accessing...

OK, there's my 2 cents... for what it's worth.
-
hth
Al Camp
Candia Computer Consulting - Candia NH
http://home.comcast.net/~cccsolutions

 

[Guest]

Brendan,

You're not quite right here. The problem is that the arrow keys do not
navigate "properly" through an option group if you have two or more columns
of buttons, so code IS requirted to fix this. As I found out from discussing
this with someone else here recently, "the cursor (down arrow) always goes to
the next option whose Top property is >= the current option." In other
words, if you have two columns of buttons, the down arrow bops around between
the two columns instead of going down the first column and then down the
second (likewise with the up arrow).

I already adapted the code you posted to fix this (I used the form's KeyDown
event) and it works great. However, the total number of buttons has to be
hard-coded into that routine. I was simply wondering here if the program
could find out the number of buttons instead of me hard-coding that value.
That way if the number of buttons changes, then the code doesn't have to
change.

ctdak

 

[Brendan Reynolds]

Thanks for the clarification. I don't think I've ever used an option group
with more than one column. If I had that many options, I'd go for a combo
box or list box rather than an option group, as it takes less screen space.

As I mentioned previously, the Controls collection of an option group
includes all controls in the option group, including labels. Usually, each
button or check box in the option group will have a label, and the option
group itself will have a label. Therefore *usually* the number of buttons or
checkboxes in the option group will be (NameOfOptionGroup.Controls.Count -
1) \ 2

 

[Guest]

Al,

Thanks for explaining what you were thinking. Your rationale might make
sense except that I have only one Access application to worry about for my
users, so "standardization" is a non-issue for me. Even if it were an issue,
I often find inconsistencies with so-called standards in MS applications, and
neither are they the best. There is nothing "questionable" in my mind about
the convenience of "sequential tab accessing", as you suggested. It is very
intuitive for the user, much more so that "Alt-anything". (And all the more
so when to the user a multi-tab form looks like a different "record" is
associated with each tab.)

By the way, if Access standards were truly standard, then in my opinion
PageDown and PageUp would move a user between records (report pages) when
viewing a report on the screen, instead of moving the view down/up on one
page. Maybe the attempt was to make that function like in Word, but then the
bottom of the screen looks just like an Access form. So much for standards!

ctdak

 

[Guest]

Thanks a lot again! This did the trick for me. (It looks like the Controls
collection does not include controls like regular option buttons or aesthetic
boxes and labels, etc, that also happen to be within the option group on the
form.)
ctdak

 

[Brendan Reynolds]

Option buttons are included if you create the option button directly within
the frame. They are not included if you create them on the form, then drag
them into the frame. If you do that accidentally, you can add the control to
the option group by selecting the control, cutting it to the clipboard, then
selecting the frame and pasting the control back from the clipboard.

Labels are included if they are attached to the frame control or one of its
child controls, but not if they are unattached or attached to a control that
is not a child control of the frame control.

 

[Guest]

"Standard" Windows navigation in a tabbed dialog box is CTRL-TAB to move one
tab forward and SHIFT-CTRL-TAB to move backwards. This is consistent with
keyboard navigation in Access Tab controls.