![]() |
|
Published 1998-04-01 Printer-friendly version
One of the really cool things we got with tabs on browses was the ability to have multiple sort orders. More important were the multiple locators and filters that came along with them.
The App and Procedure Wizards will automatically create browses with multiple sort orders. Adding a locator or filter or range limit isn't all that difficult.
So what's the big deal? None, really. Except ... after you create your multi-tabbed browse and place your locators, you discover that someone seems to think that Windows is only mouse driven.
Huh? Well, if you change tabs and press an arrow or page key, nothing happens. The highlight bar does not move through the list. But if you use your mouse to click on the scroll bar, the list suddenly starts scrolling again!
The cause of this behavior is obvious, once you finish pulling out your hair, calm down and examine things dispassionately. Let's start with a quick tour of the basics.
If you used a wizard, your browse probably already has multiple tabs/sort orders. If you didn't, you must place a Sheet control on the window (sizing it would help, too).
Click on the sheet to select it, click Controls, click Tab, click on your sheet and, bam, a new tab! Right click on the tab to expose its Properties worksheet and you can set the tab's text. Repeat the procedure until you have all the tabs you need.
Of course, at this point, the tab doesn't do much. In fact, it doesn't do anything. From the main Procedure Properties worksheet, select Browse Box Behavior (see figure 1).

Note that you can select a locator type and enter a filter or range limit. You can even enter additional sort fields. You cannot enter a key for a sort order. This is because the default sort order is determined by the key you selected when you populated the file into the procedure's file schematic (see figure 2).

Key/sort orders, locators and filters/ranges for the remaining tabs are set from the Conditional tab ... Properties (see figures 3 and 4).


And that, as they say, is how it's done.
The problem occurs only if you are a keyboard user. It does not effect mouse users.
After noting that your keyboard is ineffective after switching tabs, what you may also notice is that the locator field is selected when you change tabs. Of course, you want the list to be selected and, if you click on it, your keyboard comes back to life.
Checking the control order (Edit ... Set Control Order) reveals the cause of the problem. Examining the control order shows the order in which controls are selected. With each tab change, the locator prompt is the first field after the tab and that is what is selected. Because the prompt is a string, the first available control that can receive focus will be the locator entry field (figure 5).

What you want is the list after the tab. But that would mean dynamically moving the list after each tab or having a separate list control on each tab. The latter defeats the point of using Clarion and the former is clearly impossible.
Or is it?
[Note:Because I originally developed this in CW1.5, this discussion will be based on the 2003 templates. However, it works equally well using the ABC templates.]
Obviously, the list cannot be physically moved around in the control order, much less dynamically at run time. But it would be nice if we could dynamically change the logical order of selection.
When I first noticed this problem, back in CW1.5, I ended up (several days later) searching the available properties listed inproperty.clw. Lo and behold, I discoveredProp:Follows and the documentation confirmed that this is exactly what is needed.
IfField_1 is normally selected beforeField_2, the expression?Field_1{Prop:Follows} = ?Field_2 informs the procedure that the control selection order is to beField_2 thenField_1. Just what we need. This can be used to reset the selection order when changing tabs so that the locator field follows the list, not the "normal," populated order. Something like:
?Browse:1{Prop:Follows} = ?Locator_Field
The question is, "Where?" The answer, naturally, is "At the first point at which the value of the sheet's use variable changes its value and matches the selected tab."
Simple, isn't it?
So, what is the earliest point at which the tab value is correct on a tab change?Control Handling, Before Event Handling for the Sheet control, that's where.
And just why am I so certain? You stay up all night puttingStop() statements - giving the embed name and the sheet's value -- in each embed in a browse and you, too, can achieve equal certainty. (Not very subtle, but effective.)
If the Use variable for the sheet isCurrentTab (the default if you use a wizard), the code we want to place in theControl Handling, Before Event Handling, ?CurrentTab embed looks like:
CASE CHOICE(?CurrentTab)
OF 1 !Default tab
?Browse:1{Prop:Follows} = ?LIS:Number
SELECT(?Browse:1)
OF 2 !second tab
?Browse:1{Prop:Follows} = ?LIS:JobInterest1
SELECT(?Browse:1)
OF 3
?Browse:1{Prop:Follows} = ?LIS:Type
SELECT(?Browse:1)
OF 4
?Browse:1{Prop:Follows} = ?LIS:Company
SELECT(?Browse:1)
END
If you use only locators, the repeatedSelect(?Browse:1) is unnecessary. A single instance could be placed after theCase structure.
But, if a field on one (or more) of the tabs is an entry field used to prime a filter or range at run time, theSelect() doesn't make sense after re-setting the control order (the field does not have a value and the filter will automatically fail to find any qualifying records). For filter priming, move theSelect() to that control's Accepted embed (After Generated Code or Priority Last).
There was no method to this solution, no logic, no application of synthesized knowledge. There was absolutely no appreciation of the subtleties of the Clarion language or the templates. A bit of luck, stumbling across the Follows property (actually quite a bit of luck there), and a whole lot of perseverance solved the problem.
Who says that there must always be method to our madness?
Copyright © 1999-2009 by CoveComm Inc. All Rights Reserved. Reproduction in any form without the express written consent of CoveComm Inc., except as described in the subscription agreement, is prohibited.
Clarion Magazine ISSN 1718-9942
One year: $169
(includes all back issues since '99)
Renewals from $119
Two years: $269
Renewals from $219