On Jun 24, 2007, at 3:32 AM, Roman Kantor wrote:
> I want to ask if there is some consistency when the
> Fl_Widget::handle()
> method gets particular events. For instance it seems that FL_PUSH is
> sent to a widget only when clicked inside the widget but FL_MOUSEWHEEL
> in all cases.
>
> Looking into implementation for Fl_Group::handle() i see following
> code
> for FL_MOUSEWHEEL event:
>
> case FL_MOUSEWHEEL:
Users expect the mouse wheel to work wherever the mouse is located. I
know, on some platforms, they work in the focus window, on some the
work wherever the mouse is hovering. We decided to make it work
wherever the mouse is.
So, we walk the list of children, and if the child *under* the
pointer handles mouse wheels, we are all happy, have the widget
handle the wheel, and treat the event ad done.
> for (i = children(); i--;) {
> o = a[i];
> if (o->takesevents() && Fl::event_inside(o) && send
> (o,FL_MOUSEWHEEL))
> return 1;
> }
Now here is some trickery. If there was no widget under the mouse
pointer, there may be one close by that is keen on handling the mouse
wheel. So we walk the list of children again to find anyone else who
might be interested. A typical example would be a Scroll: the user
points the mouse to the middle of a scrolling document, but the
document itself does not handle the the mousewheel message, the
scroll bar to the right of the document does. Since document an
scrollbar are in the same group, the event propagation will flow as
expected by the user.
> for (i = children(); i--;) {
> o = a[i];
> if (o->takesevents() && !Fl::event_inside(o) &&
> send(o,FL_MOUSEWHEEL))
> return 1;
Sure, this is a compromise, but it works well in most cases. And one
can still override this feature by creating a new group class.
----
http://robowerk.com/
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
