On 01.01.2013 23:39, Ian MacArthur wrote:
>
> On 1 Jan 2013, at 21:44, Denton Thomas wrote:
>
>
>>> My thinking is that this *should* work and would mean that only one
>>> "special" derived widget is needed, rather than having to make every
>>> contained widget be a "special" widget.
>>>
>>
>> Yep, I agree. I've just made a template to add the handlers to any old
>> widget, but it seems like a kludge.
>>
>>> From what I can tell, an Fl_Group does not parse events if they are
>>> already within the group. If I tab from one widget to another, within the
>>> group, the event never goes through Fl_Scroll:handle(). So the group never
>>> knows to check whether focus has changed hands/positions.
>>
>> At least I don't -think- it does ... I'll test some more.
>
> Ah... that was what I was worried about, perhaps...
>
> (Paraphrasing somewhat...) Normally, events in fltk get propagated from the
> container widget (e.g. group or scroll) down to its children, until one of
> them takes it.
Correct.
> But I suspect that keyboard events get routed *first* to the widget with
> focus, and only if it doesn't want them, do they get passed to the container
> widget to be distributed.
Yep, correct as well.
> And so I guess it is possible that keyboard nav events would go to the focus
> widget
True so far...
> without necessarily passing through the parent container at all. And thereby
> rendering my cunning scheme useless.
Yep, that's also correct, but fortunately normal FLTK widgets don't
*use* the navigation keys. Hence, navigation key events usually return
zero from the widget's handle() method, and the group gets it.
> Oh well. If you look into this further, be handy to know for sure if this is
> the way things are!
Eventually, when the group gets the key event, there is this code
in Fl_Group::handle():
case FL_KEYBOARD:
return navigation(navkey());
and this method at line #315 in current svn (r 9783):
// try to move the focus in response to a keystroke:
int Fl_Group::navigation(int key) {
...
}
So the approach to subclass Fl_Scroll should work as suggested.
It could maybe need just a little code in handle(), something
like this might suffice:
MyScroll::handle(int event) {
Fl_Widget *fw = Fl::focus(); // save focus widget
int ret = Fl_Scroll::handle(event);
if (ret && fw != Fl::focus) { // event used and focus changed
// check focus widget and scroll ...
// your design decision here how to manage scrolling
// returns wx and wx to scroll to
scroll_to(wx,wy);
}
return ret; // return Fl_Scroll/Fl_Group's return value
}
So far this simple code. Maybe you'd want to also check for
FL_KEYBOARD and/or FL_SHORTCUT events, but that's probably not
necessary.
That said, I have done it in my own code also in all the child
widget classes, but I had shared code in my child classes anyway,
so this was the easiest approach for me at that time.
I'll check if I can use this simple code in my own app as well,
but this will not be done soon. So don't hold your breath for
any more info from me concerning this approach.
To the OP: I'd be interested in your feedback, if it works this
way for you, and in any corrections you need to make.
Albrecht
_______________________________________________
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
