Kbase 13632: TAB order in Version 7 -- with and without the UIB
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
10/05/1998 |
|
TAB order in Version 7 -- with and without the UIB
Programmers often have questions on how to change the TAB order of
widgets on a window, with and without the UIB.
The effects of the ENABLE statement on TAB order are discussed in
knowledgebase 13455, "Effects on TAB order using ENABLE or VISIBLE and
SENSITIVE". As its title suggests, kbase 13455 also discusses how
setting :VISIBLE and :SENSITIVE on widgets can change their place in
the TAB order. Users are referred to kbase 13455 for more
information.
This knowledgebase deals with two other aspects of TAB order: using
widget methods to change TAB order, and understanding how the UIB
sets TAB order.
Methods that affect TAB order
-----------------------------
Each field-level widget supports two methods for changing its place
in the TAB order of a window: MOVE-BEFORE-TAB-ITEM() and
MOVE-AFTER-TAB-ITEM().
For example, given a window consisting of six buttons, you could place
button-5 after button-2 in the TAB order by saying:
DEF VAR log AS LOGICAL.
log = button-5:MOVE-AFTER-TAB-ITEM(button-2:HANDLE).
How the UIB affects TAB order
-----------------------------
When you create widgets in the UIB, the UIB adds each new widget to
the ENABLE statement it maintains in the Enable_UI internal
procedure. As discussed in kbase 13455, "Effects on TAB order using
ENABLE or VISIBLE and SENSITIVE", when widgets are enabled using the
ENABLE statement, the resulting TAB order matches the order in which
the widgets are named. For example, in the ENABLE statement below,
the resulting TAB order is (1) fill-in-2, (2) button-3, and
(3) fill-in-1:
ENABLE fill-in-2 button-3 fill-in-1 WITH FRAME frame-b.
How does a programmer get around this? What if you don't want to
have to create your widgets in a certain order just to make sure you
get the TAB order you desire? Experienced UIB users know it's
best not to take over responsibility for maintaining the Enable_UI
internal procedure. There has to be a better way.
There is. You can get around the UIB's default TAB order by (1)
writing your own ENABLE statement in the Main Block, (2) telling
the UIB not to do any default enabling of widgets on its own, and (3)
telling the parent frame *not* to maintain any default TAB order.
To accomplish (2), de-select the "Enable" tickbox on the Property
Sheet of each widget whose TAB order you wish to adjust. To do step
(3), access the frame's Property Sheet and de-select "Keep-Tab-Order".
Short Example:
--------------
Let's say you've created widgets on your window in this order:
button-1, button-2, fill-in-1, fill-in-2, button-3. At some point
you decide that you'd like the default TAB order to bounce through
the two fill-in's before proceeding through the buttons, but the
TAB order created by the UIB in Enable_UI is the same as the order in
which the widgets were created.
To get around the default TAB order, you invoke the Property Sheet
for each widget and turn off the "Enable" toggle. If you now look at
the Enable_UI internal procedure, you'll see there's no ENABLE
statement whatsoever. This will allow you to do your own widget
enabling. Go to the Main Block and find the RUN Enable_UI statement,
then insert an ENABLE statement immediately after it, ordering the
widgets the way you'd like them to appear in the TAB order:
RUN Enable_UI.
ENABLE fill-in-1 fill-in-2 button-1 button-2 button-3 WITH
FRAME frame-b.
Now, go to the frame's Property Sheet and locate the tickbox for
"Keep-Tab-Order". Make sure it is turned OFF. (When Keep-Tab-Order
is on, the TAB order can only be the order in which the widgets are
defined.)
Run the resulting .w and you'll see the TAB order has adjusted to
that given in your ENABLE statement.
Progress Software Technical Support Note # 13632