On Monday 09 December 2002 3:06 pm, Lars Gullik Bjønnes wrote:
> My plan was/is to remove a lot of these when we get separate KEY_PRESS
> and KEY_RELEASE events, this has not been true with 0.88 and 0.89 (not
> sure how 1.0 behaves in this respect).
Ummm. Well, xforms /receives/ separate events from X, but does not pass on
the KeyRelease event to the FL_OBJECT handler. Are you saying that you'd like
FL_KEYRELEASE events to be received by the XWorkArea handler?
This all seems to demonstate a lack of joined-up thinking in xforms handling
of key events. This is what /does/ actually happen:
(do_interaction_step)
case KeyPress:
fl_mousex = st_xev.xkey.x;
fl_mousey = st_xev.xkey.y;
fl_keymask = st_xev.xkey.state;
do_keyboard(&st_xev, FL_KEYPRESS);
return;
case KeyRelease:
fl_mousex = st_xev.xkey.x;
fl_mousey = st_xev.xkey.y;
fl_keymask = st_xev.xkey.state;
do_keyboard(&st_xev, FL_KEYRELEASE);
return;
Interestingly, do_keyboard does not differentiate between FL_KEYPRESS and
FL_KEYRELEASE events, processing both events in identical fashion. Ie, it
calls fl_XLookupString((XKeyEvent *)xev, ..., &keysym, ...), although xev
doesn't appear to be very interesting in the case of KeyRelease. Certainly,
my tests suggest that (keysym == 0) on FL_KEYRELEASE events.
(Am I right here? passing a KeyRelease event to
fl_XLookupString((XKeyEvent *)xev, ..., &keysym, ...)
is pointless?)
do_keyboard then passes on control of both events to fl_handle_form.
In turn, fl_handle_form handles FL_KEYPRESS (== FL_KEYBOARD):
case FL_KEYBOARD: /* A key was pressed */
fl_keyboard(form, key, xx, yy, xev);
break;
fl_keyboard calls the widget handler fl_handle_object.
However, fl_handle_form does NOT process FL_KEYRELEASE. Ie, it just falls
through the routine. It is NOT passed to the FL_OBJECT handler.
Shall I pass this analysis on to the xforms list? I'm in danger of making a
nuisance of myself ;-)
Angus
