[XForms] incorrect reporting of mouse (XEvent) status to post-handler

[Ivan Powis]

I posted this problem a week ago. In short, in an application providing
mouse
interaction via pre/post handlers I notice a spurious response - seemingly
xforms detects
and reports an FL_RELEASE immediately following FL_PUSH event, even when the
mouse button is still physically held down. This completely screws up the
ability of the application to track the
mouse actions. It occurs in version of xforms since 0.89, on various OSes.
Interestingly it is
is much more evident on the console of a linux box, than when running via a
remote X server.

I have at least now tracked the apparent problem to the following section of
forms.c,
around line 1357:

#if 1
    /* this is an ugly hack. This is necessary due to popup pointer grab
       where a button release is eaten. Really should do a send event from
       the pop-up routines */

    if (fl_pushobj && !button_down(fl_keymask) /* && event == FL_ENTER */ )
    {
	obj = fl_pushobj;
	fl_pushobj = NULL;
	fl_handle_object(obj, FL_RELEASE, xx, yy, key, xev);
    }
#endif

 .. in particular it is the call to fl_handle_object which I believe
initiates the spurious
FL_RELEASE report to the handlers.

Evidently this section of code comes with a health warning attached.
Anyone understand what it is trying to do? Wasn't there some reference
to this same section in a discussion of odd pup-up behaviour a few weeks
ago?

Ivan Powis

-----Original Message-----
From: xforms-bounces at bob.usuhs.mil
[mailto:xforms-bounces at bob.usuhs.mil]On Behalf Of Ivan Powis
Sent: 04 June 2004 17:48
To: xforms at bob.usuhs.mil
Subject: [XForms] Xforms: incorrect reporting of mouse (XEvent) status
to post-handler


To subscribers of the xforms list

[...]


I may note that the problem appears the same in v.89 and v1 of the forms
library, and isn't confined to a particular version of Linux and/or gcc.
For example on Mandrake linux 8.2 (kernel 4.2, XFree 4.2.0, KDE 2.2.2) on
the console xserver the app becomes unusable. But connect to this same
system a remote pc running Exceed xserver and there is no problem using
either the full KDE session or a single X-window opened on the Windows
desktop.
Likewise on a Redhat (kernel 2.4.20, XFree 4.3.0 KDE 3.1) the app is
unusable at the console, but OK if viewed via a remote pc Xserver - in this
case just an occasional glitch crops up, but basic functinality is not
compromised).
I think we saw some similar minor glitches on older HP/UX systems.

Actually the degradation in performance at the linux consoles seems to
correlate with the use of a heavyweight window manager like KDE or GNOME,
but isn't confined to any particular WM.

It seems then as though the forms library, rather than tracking the mouse
button state via the XEvents it receives, tries to maintain its own internal
record, which more often than not gets out of sync with the physical state
and the reported status via xev. This then seems far far worse with a
heavyweight local WM. I don't quite understand the significance of this, nor
the inner workings of X. Anyone got any ideas, or suggestions where in the
source to browse and what to look for?


This message has been scanned but we cannot guarantee that it and any
attachments are free from viruses or other damaging content: you are
advised to perform your own checks.  Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.