mirrors
/
fltk
mirror of https://github.com/fltk/fltk
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Fixed typos and added a \todo paragraph about some more events. This probably 

needs some more corrections ...


git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@7468 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
This commit is contained in:
Albrecht Schlosser 2010-04-07 22:35:48 +00:00
parent f6753ea76a
commit 0fe65e94c9
1 changed files with 27 additions and 21 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

48
documentation/src/events.dox
View File

@ -338,7 +338,7 @@ These are all trivial inline functions and thus very fast and small:
\section events_propagation Event Propagation \section events_propagation Event Propagation
Widgets receive events via the virtual handle() function. The argument indicates Widgets receive events via the virtual handle() function. The argument indicates
the type of event that can be handled. The widget must indicat if it handled the the type of event that can be handled. The widget must indicate if it handled the
event by returning 1. FLTK will then remove the event and wait for further events event by returning 1. FLTK will then remove the event and wait for further events
from the host. If the widget's handle function returns 0, FLTK may redistribute from the host. If the widget's handle function returns 0, FLTK may redistribute
the event based on a few rules. the event based on a few rules.
@ -365,33 +365,39 @@ control those leaf widgets:
\li Fl::release() \li Fl::release()
\li Fl_Widget::take_focus() \li Fl_Widget::take_focus()
FLTK propagetes events along the widget hierarchy depending on the kind of event FLTK propagates events along the widget hierarchy depending on the kind of event
and the status of the UI. Some events are injected directly into the widgets, others and the status of the UI. Some events are injected directly into the widgets,
may be resend as anew event to a different group of receivers. others may be resent as new events to a different group of receivers.
Mouse click events are first sent to the Window that caused them. The Window Mouse click events are first sent to the window that caused them. The window
then forwards the event down the hierarchy until it reaches the Widget that then forwards the event down the hierarchy until it reaches the widget that
is below the click position. It that Widget uses the given event, the widget is below the click position. If that widget uses the given event, the widget
is marked "pushed" and will receive all following mouse motion events until the is marked "pushed" and will receive all following mouse motion (FL_DRAG) events
mouse button release. until the mouse button is released.
Mouse wheel events are sent to the Window that caused the event. The Window \todo Is this correct? IMHO, mouse motion (FL_MOVE) events are sent to the
propagets the event down the tree, first to the widget that is below the belowmouse() widget, i.e. the widget that returned 1 on an FL_ENTER event.
mouse pointer, and if that does not succeed, to all other widgets in the Group. The pushed() widget will usually get an FL_FOCUS event and becomes the focus()
This ensures that Scroll widgets work as expected with the widget furthest widget if it returns 1 on FL_FOCUS, and will then get keyboard events (see
below).
Mouse wheel events are sent to the window that caused the event. The window
propagates the event down the tree, first to the widget that is below the
mouse pointer, and if that does not succeed, to all other widgets in the group.
This ensures that scroll widgets work as expected with the widget furthest
down in the hierarchy getting the first opportunity to use the wheel event, down in the hierarchy getting the first opportunity to use the wheel event,
but also giving scroll bars, that are ot directly below the mouse a chance. but also giving scroll bars, that are not directly below the mouse a chance.
Keyboard events are sent directly to the Widget that has keyboard focus. Keyboard events are sent directly to the widget that has keyboard focus.
If the focused Widget rejects the event, it is resent as a Shortcut event, If the focused widget rejects the event, it is resent as a shortcut event,
first to the top-most window, then to the widget below the mouse pointer, first to the top-most window, then to the widget below the mouse pointer,
propagiting up the hierarchy to all its parents. Those send the event also propagating up the hierarchy to all its parents. Those send the event also
to all widgets that are not below the mouse pointer. Now if that did not work to all widgets that are not below the mouse pointer. Now if that did not work
out, the shortcut is sent to all registered shortcut handler. out, the shortcut is sent to all registered shortcut handlers.
If we are still unsuccessful, the event handler flips the case of the shortcut If we are still unsuccessful, the event handler flips the case of the shortcut
letter and starts over. Finally, if the key is "escape", FLTK sends a close letter and starts over. Finally, if the key is "escape", FLTK sends a close
event to the top-most window. event to the top-most window.
All other events are pretty much sent right away to the window that created All other events are pretty much sent right away to the window that created
the event. the event.
@ -399,8 +405,8 @@ the event.
Widgets can "grab" events. The grabbing window gets all events exclusively, but Widgets can "grab" events. The grabbing window gets all events exclusively, but
usually by the same rules as described above. usually by the same rules as described above.
Windows can also request eclusivity in event handling by making the Windows can also request exclusivity in event handling by making the
window non-modal. window modal.
\section events_compose_characters FLTK Compose-Character Sequences \section events_compose_characters FLTK Compose-Character Sequences