I know I must not be the only one that can't count to three because fltk doesn't have a tab ordering routine yet so I'm not too terribly embarrassed.
Got a sec? This is going to take some time. BTW, is a hard drive supposed to blow smoke and sound like a steam engine? Note: I have renamed my message.cxx to ask.cxx because that's the name of the header. As you read the word "ask" below, think "message". I'm in ask.cxx and we are looking at the creation of three buttons labeled Yes, No, and Cancel. They are anonymous critters so we need to look at the widgets structure in a debugger to be sure who is getting linked to thegroup widget first and who is getting linked last because this sets the search
order and the tab order at creation time.
In a debugger (I'm using kdbg) we can see FOR SURE that the first button
created is the "Yes" button and the last is Cancel.
Notice that this *IS* the tab order for an ask widget. And it's not what we
expect. We'd like to tab from Cancel to No to Yes, starting the loop with
the focus on the Yes button.
We can force the parent widget to re-link its children (these buttons) in
the right order by using the Group::remove() and Group::add() functions.
Here's what we have then, in human terms.
[Yes | No | Cancel]
^
focus -->
With the focus set on the first button during creation which cycles to
No and Cancel when we TAB or even use the arrow keys (which make this
appear to rotate backward).
And here's what we want.
[Cancel | No | Yes]
^
--> focus -> (wraps)
Our group is the window so we'll be using that object to do the reordering.
First we remove them all from the parent. Let's just call the parent the
Group. So first we remove all the widgets from the Group.
This doesn't destroy the object, it just breaks the linkage. (Each object
is responsible for it's own destruction.)
If we were clever, we made a list of these objects beforehand, storing
their address in an array which we can use to tell the Group how to re-
link these objects.
We say:
set_tab_order(
&window, // the Group
3, // items
3, // gets the focus
b2, // Cancel
b1, // No
b0 // Yes
);
Then we remove them all and reinsert them all in this order and we'd expect
the focus to be on the last linked as it would be if it were the last
created
And... Everything looks fine except Cancel for some odd reason gets the focus.
What went wrong? In the ask code, that code also sets the focus. We can infer from this odd behavior that the focus is set by the index of the focused widget rather than its address or xy position. And it's no longer in the first position; it's now in the third. Here's the code in ask that set the focus. if (!istr) window.set_focus(button); In conclusion, no, a hard drive is not supposed to blow smoke OR sound like a steam engine. I knew you were wondering about that, as I have been. But if you have messed with tab ordering in the past and gave up, due to this two-variable complexity now you know what went wrong. Looking at this... [Cancel | No | Yes] We can see that the one we want is now in the third position. set_focus->(widgets[nwidgets-1]) --------------- See a full implementation in the attached file which I'll name ask-message, since there's some confusion about what it really is. ;-) Yup. Either a steam engine or a carpet factory... I'm wondering if getting a SATA drive was such a great idea now. Oh! And now it sounds like it's eating something... like soggy cardboard. So I hope I get this out before it decides to take a nap or something.
ask-message.cxx.tar.gz
Description: GNU Zip compressed data
_______________________________________________ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
