Tab groups (was: Re: Default Sizers, First Draft)

[Don Dwiggins]

Tim Roberts wrote:
> The problem is that it isn't in "3rd normal form", so to speak.  It's
> like updating a doubly-linked list.  If you do this:
>     button2.TabNext = button3
>     button2.TabPrevious = button1
> Do you automatically have to set button1.TabNext and button3.TabPrevious
> to button2?  What happens to the control that used to be in
> button1.TabNext?  If it no longer has references, does it lose out? 
> Having a single "TabNext" property is probably a less error-prone solution.

My thinking on TabPrevious is to allow for "backward" navigation with 
Shift-Tab, which as a user I appreciate in some of the forms I work 
with.  I agree that it raises a consistency issue, and I hadn't thought 
that far.  It'd probably be best to have a tab group normally specified 
as a list of controls, but "editing" it would require careful attention 
on the part of the programmer.

  > I'm afraid multiple independent "tab groups" would be terribly
> confusing.  How would I switch from one group into another?  Pressing
> the tab button like my son presses the A button on his Gameboy should
> allow me to visit every control.

That's a UI design issue.  It'd probably be rare to have more than one 
group, but on that rare occasion, it'd be nice that it's there.  (Of 
course, a special case of a tab group is an "isolated" control, where 
next/previous are both null; this may be less rare.)

Actually, I only mentioned it because it falls out naturally from the 
mechanism.  I wouldn't go to great lengths to provide it when designing 
a different mechanism.

-- 
Don Dwiggins
Advanced Publishing Technology