Previous: Form Events, Up: Interaction [Contents][Index]
Just as you can by-pass the internal event processing for a particular form, you can also do so for an object. Unlike in raw callbacks, you can not select individual events.
The mechanism provided is via the registration of a pre-handler for an object. The pre-handler will be called before the built-in object handler. By electing to handle some of the events, a pre-handler can, in effect, replace part of the built-in handler.
In the chapter about pre-emptive handlers the API was already discussed in detail, so here we just repeat the discussion for completeness as any use of pre-emptive handler is considered "dirty tricks".
To register a pre-handler, use the following routine
typedef int (*FL_HANDLEPTR)(FL_OBJECT *obj, int event, FL_Coord mx, FL_Coord my, int key, void *raw_event); void fl_set_object_prehandler(FL_OBJECT *, FL_HANDLEPTR prehandler);
where event
is the generic event in the Forms Library, that is,
FL DRAW
, FL ENTER
etc. The arguments mx
and
my
are the mouse position and key
is the key pressed.
The last parameter, raw_event
is a pointer to the XEvent that
caused the invocation of the pre-handler. cast to a void pointer.
Notice that the pre-handler has the same function prototype as the
built-in handler. Actually they are called with the exact same
parameters by the event dispatcher. The prehandler should return
0
if the processing by the built-in handler should continue. A
return value of FL PREEMPT
will prevent the dispatcher from
calling the built-in handler.
See demo program preemptive.c for an example.
A similar mechanism exists for registering a post-handler, i.e., a handler invoked after the built-in handler is finished, by using
void fl_set_object_posthandler(FL_OBJECT *, FL_HANDLEPTR prehandler);
Whenever possible a post-handler should be used instead of a pre-handler.
Previous: Form Events, Up: Interaction [Contents][Index]