On 18.05.2012, at 10:36, Manolo Gouy wrote:

>> 
>> On 17.05.2012, at 15:50, [email protected] wrote:
>> 
>>> Author: manolo
>>> Date: 2012-05-17 06:50:11 -0700 (Thu, 17 May 2012)
>>> New Revision: 9514
>>> Log:
>>> Created function fltk3::Widget* fltk3::event_widget() with this =
>> Doxygen description:
>>> Widget to which mouse event coordinates relate.
>>> =20
>>> Functions fltk3::event_x() and fltk3::event_y() return values that are=20=
>> 
>>> offsets from the top-left of the widget returned by this function.
>>> Outside of event-handling contexts, this function returns NULL.
>> 
>> Hmm, I don;t understand why all this is needed. fltk3::Widget::send()
>> should update event_x and event_y for the widget that receives the
>> event. So AnyWidget::handle() should always read event_x() and _y()
>> relative to its own origin (top, left).
>> 
> 
> My idea is that this function is helpful to determine exactly what are
> the event_x() and event_y() coordinates. Inside a handle() function,
> coordinates are known to be relative to the widget origin. The concern
> is whether some programs may deal with event_x/y() in contexts where
> the target widget is not available. This happens at the library
> development level where fltk3::event_inside(fltk3::Widget*),
> Fl::eventx/y() and Fl::event_inside(int x, y, w, h) need
> to call fltk3::event_widget().
> If you feel this is superfluous, we can remove fltk3::event_widget()
> from the public API.

OK. I just moved it to where al the other event related variables are.

_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev

Reply via email to