All other information about the most recent event is stored in static locations and acquired by calling these functions. This static information remains valid until the next event is read from window system (i.e. it is ok to look at it outside of the handle() method). This allows the data to be accessed by callbacks and other functions without having to pass an event argument to them, and allows more fields to be added to events without breaking binary compatability. These are all trivial inline functions and thus very fast and small:
The following functions call the above functions to compute more information about the current event:
The following functions do not return parts of the current event, instead they directly inquire about the current state of devices:
FLTK has very simple rules for sending events to widgets. The major unusual aspect of FLTK is that widgets indicate if they "handled" an event by returning non-zero from their fltk::Widget::handle() method. If they return zero, FLTK can then try the event elsewhere. This eliminates the need for "interests" (event masks or tables), and this is the main reason FLTK is much smaller than other toolkits.Most events are sent to the outermost fltk::Window containing the event, and those widgets are responsible for finding and sending the events to child widgets. Some events are sent directly to fltk::Widgets, this is controlled by the following methods, which the container widgets are required to call:
If all the widgets that FLTK tries to send an event to return zero, then you can add global functions that FLTK will call with these events. This is done with fltk::add_handler(int (*)(int,fltk::Window*)).
You can generate fake events by calling handle(int) on the correct widgets (usally a window). Currently you can change the values returned by the fltk::event_*() functions by storing the desired value into the static variables fltk::e_*, but this may change in future versions.
A mouse button has gone down with the mouse pointing at this widget. You can find out what button by calling fltk::event_button(). You find out the mouse position by calling fltk::event_x() and fltk::event_y(). These positions are relative to the corner of the widget whose handle() method is being called.
A widget indicates that it "wants" the mouse click by returning non-zero from its handle() method. It will then become the fltk::pushed() widget (this is done by the enclosing group widget) and will get fltk::DRAG and the matching fltk::RELEASE events.
To receive fltk::DRAG events you must return non-zero when passed a fltk::PUSH event.
To receive fltk::RELEASE events you must return non-zero when passed a fltk::PUSH event.
If a widget wants the focus, it should change itself to display the fact that it has the focus, and return non-zero from its handle() method. It then becomes the fltk::focus() widget and gets fltk::KEY, fltk::KEYUP and fltk::UNFOCUS events.
The focus will change either because the window manager changed which window gets the focus, or because the user tried to navigate using tab, arrows, or other keys. You can check fltk::event_key() to figure out why it moved, for navigation it will be the key pressed and for switching windows it will be zero.
The key pressed can be found in fltk::event_key(). The text that the key should insert can be found with fltk::event_text() and its length is in fltk::event_length().
If you are actually doing text editing, you should use fltk::compose() to process the individual keystrokes into I18N characters.
You can also make "global" shortcuts by using fltk::add_handler(). A global shortcut will work no matter what windows are displayed or which one has the focus.
If you implement a widget class it is important to call your base class with this same event. Fltk relies on this to communicate the visiblilty of widgets that are windows to the system.
If you implement a widget class it is important to call your base class with this same event. Fltk relies on this to communicate the visiblilty of widgets that are windows to the system.
It is impossible to examine the text of the drag until you release it. There are system-specific variables that can be examined to determine the type of drag being done, but unless you are making a file-management application that wants to delete or rename the source files, you should not need this information.