On 04/02/12 14:22, Jeff Paranich wrote:
> The kicker is that Fl_Table has to have focus (and for the current way
> my program is setup this can only be achieved by first clicking within
> the table with the mouse).
As with any widget, you should be able to give the table focus
with take_focus(). Just be sure its handle() method returns 1
for FL_FOCUS so that FLTK knows it can take focus. I think it
does this already, but you should check.
> If I am in an Fl_Input (created external from the table - as my
> table does not implement Fl_Inputs like your examples), and press
> up/down arrow key, I have discovered that Fl_Window (that has the
> Fl_Input box) and consequently Fl_Table never receives the events
This is probably because input takes these for itself.
Assuming that's the case, you can prevent that by deriving
a class from Fl_Input, and create your own handle() method
that that checks for the up/down arrow keys and ignores them
(by doing a return(0) when those events are received). This
will short circuit those keys away from Fl_Input, and the
return(0) tells FLTK to try passing those events to the
other widgets in the window.
> So I looked at Fl_Input.cxx's handle function, it appears it
> should pass my up/down key presses for other widgets to handle....
> I think? Not really familiar with the inner workings of FLTK.
The event handling is pretty simple for all widgets:
All widgets use handle() to process events, eg:
window manager events (like FOCUS/UNFOCUS/OPEN/CLOSE..)
mouse events like ENTER/LEAVE/PUSH/RELEASE..)
keyboard events (like KEYDOWN and KEYUP, etc.)
..and the important thing is handle()'s return tells FLTK if
the widget 'handled' the event or not.
A return value of 1 indicates the widget 'handled' the event,
and that tells FLTK it doesn't need to deliver the event
to the other widgets.
So if Fl_Input returns 1 for arrow key events, then FLTK won't
pass those events on to other widgets.
But if you derive a widget from Fl_Input and make your own
handle() method, and return 0 for those keypresses, then
you can not only prevent Fl_Input from seeing the events
(by not passing them down to Fl_Input::handle()),
but you can also tell FLTK to pass the events to other
widgets (by returning 0 instead of 1).
> *** Relevant Excerpts from Fl_Input.cxx ***
> case FL_Up:
> #ifdef __APPLE__
> if (mods==0) return kf_lines_up(1); // Up
> (OSX-HIG)
> if (mods==FL_CTRL) return kf_page_up(); // Ctrl-Up
> (TE !HIG)
> if (mods==FL_ALT) return kf_move_up_and_sol(); // Alt-Up
> (OSX-HIG)
> if (mods==FL_META) return kf_top(); // Meta-Up
> (OSX-HIG)
> return 0; //
> ignore other combos, pass to parent
Yes, this is because Fl_Input can be used in lots of other contexts,
like Fl_Multiline_Input, where up/down can move the cursor around
within the widget.
It used to be that for single line widgets (like Fl_Input), the
arrow keys let you move from one widget to another, the way
Tab and Shift-Tab do.
This is a feature we recently made 'optional', as these days everyone
seems to use Tab and Shift-Tab exclusively for moving from one widget
to another, and the arrow keys are not as often used for this purpose,
though it can be nice if you want to navigate east/west + north/south
with the arrow keys in the case of a table of single line input widgets.
I think one of the demos tests this.. can't remember which one :/
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
