On 04.01.2013 12:36, Denton Thomas wrote:
>>> Albrecht wrote:
>>
>> Oh, yes, that's certainly true. If navigation happens to
>> succeed in a subgroup, then this subgroup does it all. No
>> parent group will notice. You could maybe derive an own
>> Fl_Group class to do this in conjunction with its parent
>> YourScroll class, but this could be a never ending story,
>> unless you know exactly what groups and widgets you need
>> in your special case.
>>
>
> Perhaps this is solve-able after all. New handle() below. I like this version
> a bit better, if only because it meets your original suggestion for a simple
> solution.
Yup, simplicity rocks ;-)
> int handle(int event) {
> int ret = Fl_Scroll::handle(event);
> Fl_Widget* f_new = Fl::focus();
What about adding here:
if (!contains(f_new)) focus_tracker_ = 0; // focus in another group
> if(f_new && (f_new != focus_tracker_) && contains(f_new)) {
> focus_tracker_ = f_new; // focus_tracker_ = NULL in ctor
> scroll_to(scroll_to_focus_x_(), scroll_to_focus_y_());
> redraw();
> }
> return ret;
> }
>
> I've deleted test_focus_() and scroll_to_focus_() functions as unused kruft.
> All the rest remains untouched.
>
> New handle() just checks if focus (1) has moved and (2) is somewhere in the
> scroll group. I've done the membership test with contains(), which seems to
> return true even if the focus widget is nested. So far, at least.
That's how contains() is defined, it *should* (and will) find nested
widgets - and the container widget itself as well.
> I found the problem you mentioned re catching key combinations/order,
> especially w/ Shift+Tab, etc.
This was only a test case and had nothing to do with the keys
pressed per se. I only used it as a means to leave the scroll
group and return easily.
> If the above works, I can avoid the key problem altogether by ignoring the
> event code. Otherwise it may be a bottomless pit of testing the
> possible/accepted keycodes for changing focus. I -think- that the test above
> will catch any method of changing to the focus widget. I also -think- it's
> safe ... but I'll have to test some more.
There's nothing that could be wrong with it, IMHO. Just comparing
previous focus (or maybe an ancient predecessor if you left the
groupt meanwhile) with current focus can't be wrong.
> The main oddity is that I've ditched testing whether the base handle()
> returned 1. If I rely on that, I can't see nested widgets. Ignoring the value
> seems alright, but maybe this does something bad that I haven't caught yet.
This was probably the reason why leaving the group couldn't be
handled, since this would return 0 from Fl_Scroll's handle() -
which means that the parent group should handle it. However,
then the focus change would also happen after returning from
handle, so this would probably not work either. :-(
One drawback of not testing any event type and/or the return
value would be more CPU time to do your checks all the time,
even if there is an FL_MOVE event. However, maybe *this* is what
triggers your focus checks eventually and makes it all work now.
So, if you want to save some (or more) CPU cycles, I'd recommend
checking what is really needed, and then filter events and/or do
some basic, but simple checks first.
Note that there is FL/names.h with the fl_eventnames[] array that
makes it simple to debug events with something like
printf("event = %3d: %s\n",event,fl_eventnames[event]);
In my tests I usually omit repeating FL_MOVE events, since they
can be annoying. YMMV
> Since the placement code seems to be working [knock on wood], I've cut the
> color changes / debug. Thanks for identifying how the color change happened
> to the input field - I hadn't figured that one out.
You're welcome.
> I'll post a new test unit when I've got it.
Albrecht
_______________________________________________
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
