raveling@Unify.com (Paul Raveling) (11/29/90)
In preparing a new product for release we've stumbled across
what appears to be a bug in the Motif scrollbar widget. Choices
for what to do about it that we know about are:
-- Install code to bypass the problem. An undesired side
effect is that this would disable autorepeating on
the increment, decrement, page increment, and page
decrement functions.
-- Supply an equivalent bypass as an app-defaults setting,
producing the same undesired side effect.
-- Document the bug for our users and advise them that
if their application has trouble with this problem
they can bypass it (still with the side effect) by
supplying their own resource setting.
We'd welcome any word of a better alternative.
***** Details:
The basic bug is in the scrollbar's recognition of whether
a mouse button has been held down for more than repeatDelay
(XmNrepeatDelay) milliseconds. Here's one scenario producing
a failure:
The end-user's application is displaying a form that includes
information from one record out of many that have been selected
from a database. A scrollbar on the form allows the user to
control which particular record from this selected set is displayed.
The user clicks on the down arrow to "increment" to the next
record in the selected set. Motif responds to the button-down
event by calling the increment callback; the increment callback
invokes routines that read the next record from the database
and format values from it into screen fields on the displayed
form. In addition, these routines call a 4GL routine supplied
by the application developer that's to be invoked when a new
record has been selected.
In the problem case the routine supplied by the developer
includes a 4GL command such as:
display 'New record' for fyi_message wait
which our 4GL interpreter translates into a request to pop up
a dialog box containing the 'New record' message.
By the time the user hits a button on the dialog box to
dismiss it the scrollbar's repeat interval has expired.
There should now be two events queued in some manner for the
widget:
1. The button-up event that normally follows
a modest number of milliseconds after the
original button-down event.
2. Timer expiration, for the repeat time interval.
Apparently the scrollbar widget handles timer expiration first,
producing another invocation of the increment callback, displaying
another record, and popping up another dialog box. The process
repeats, stepping through the selected set every time the user
dismisses the popup, until it fails by reaching the end of the
selected set.
We can get this operation to work normally by setting the
scrollbar's repeatDelay resource to (for example) 50 seconds
instead of 50 milliseconds. However, this effectively disables
the auto-repeat feature.
Does anyone know of a better bypass?
------------------
Paul Raveling
Raveling@Unify.com