Next: Object Events, Up: Interaction [Contents][Index]
It is possible to by-pass the form event processing entirely by setting a "raw callback" that sits between the event reading and dispatching stage, thus a sneak preview can be implemented and optionally the event can even be consumed before the libraries internal form processing machinery gets to it.
Use the following routines to register such a preemptive processing routine
typedef int (*FL_RAW_CALLBACK)(FL_FORM *, void *xevent); FL_RAW_CALL_BACK fl_register_raw_callback(FL_FORM *form, unsigned long mask, FL_RAW_CALLBACK callback);
where mask
is the event mask you are interested in (same as
the XEvent mask). The function returns the old handler for the event.
Currently only handlers for the following events are supported
KeyPressMask
and KeyReleaseMask
ButtonPressMask
and ButtonReleaseMask
EnterWindowMask
and LeaveWindowMask
ButtonMotionMask
and PointerMotionMask
FL ALL EVENT
(see below)
Further, there is only one handler for each event pair, (e.g.,
ButtonPress
and ButtonRelease
), thus you can’t have two
separate handlers for each pair although it is possible to register a
handler only for one of them (but almost always a mistake) if you know
what you’re doing. If you register a single handler for more than one
pair of events, e.g., setting mask to
KeyPressMask|ButtonPressMask
, the returned old handler is
random.
A special constant, FL_ALL_EVENT
, is defined so that the
handler registered will received all events that are selected. To
select events, use fl_addto_selected_xevent()
.
Once an event handler is registered and the event is detected, then
instead of doing the default processing by the dispatcher, the
registered handler function is invoked. The handler function must
return either
FL_PREEMPT
if the event is consumed) and 0
otherwise so
that the internal processing of the event can continue. See the demo
program minput2.c for an example.
Since these kind of handlers work on a rather low level there’s a
chance that they interfere with some mechanisms of the library.
Consider the case of setting a raw callback handler for mouse press
and release events, in which the handler returns 0
for mouse
press events but FL_PREEMPT
on relese events. In that case the
mouse press event results in the normal processing and e.g., a button
below the mouse will receive it (and be drawn correspondingly). To be
drawn again in its normal way it also needs to receive the release
event (even if the mouse isn’t on top of it anymore when the mouse
button is released). But when the handler function doesn’t also let
the release event propagate to the normal handling of events then the
button will never receive the expected release event and will stay
drawn in the way as if the release event never happened. Thus one
should avoid having different return values from the handler for pairs
of related events.
Next: Object Events, Up: Interaction [Contents][Index]