Roman Kantor wrote:
> The window class (and group for that matter) is responsible for sending
> events to the children, so do not override window handle() unless it
> also handless sending the events to its children. Override handle()
> only for your new box class - something like this:
>
> [snipped example]
>
> Note that the code for FL_ENTER and FL_MOVE can be the same - when the
> FL_MOVE event coordinates are inside the widget. You can either use a
> flag which is set for FL_ENTER and reset for FL_LEAVE events or use
> Fl::event_inside(this) for checking.
True as well; if the OP only needs FL_MOVE events only for
the box, there's no reason to make a handle() method for the
Fl_Window derived widget, unless the OP needs one there for
other reasons. In which case, just be sure the Fl_Window derived
widget's new handle() method calls Fl_Window::handle(e) to pass
events down to the window, and thus on to its children.
Actually, I'd go a step further and say the My_Box::handle()
method should /also/ pass events down to the Fl_Box base class
by calling Fl_Box::handle(event), eg. changing Roman's example:
int My_Box::handle(int event){
int ret = Fl_Box::handle(event); // ADD THIS: pass events down to
Fl_Box, keep return value
// Roman's switch statement here
return(ret); // ADD THIS: pass Fl_Box::handle()'s
return value to caller
}
It just seems to make sense for /any/ widget that derives from
an FLTK widget to not starve the base class of events with its
own handle() method. Even if today Fl_Box doesn't make use of
events, it may in a future FLTK release.
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
