Runaway QSlider : it's a Qt bug

[Matthias Ettrich]

Am Sonntag, 7. März 2004 00:02 schrieb Guillaume Laurent:
> On Wednesday 03 March 2004 22:49, Guillaume Laurent wrote:
> > We have a strange bug in Rosegarden : a QSlider, when clicked on the
> > ruler part to move its cursor one notch, goes mad and suddenly slides all
> > the way to the last notch. It's just like instead of a single click you
> > had a bunch of quick repeated ones.
>
> Just for the record, I finally traced it down to a Qt bug (still in 3.3.1).
> The problem occurrs if, in a slot connected to a QSlider's 'valueChanged()'
> signal, you call QEventLoop::processEvents(QEventLoop::ExcludeUserInput,
> int).
>
> QSlider::mousePressEvent() arms a timer to keep moving the slider if the
> mouse button is kept down. But the valueChanged() signal is emitted from
> within mousePressEvent().
>
> So when the slot is called, if what it does takes a long time and
> processEvents() is called to maintain the GUI, the timer will go off, and
> things will happen as is the button is still down even though it's been
> released. QSlider::mouseReleaseEvent() is never called.
>
> I'm sending a copy of this to qt-bugs with a sample reproducing it.

While I don't argue that it might be possible to find a generic solution to 
this and similar problems on the toolkit level, I'm not quite sure how, yet. 
General rule: do not exclude user input when the mouse is pressed down.

The sitation is roughtly equivalent to installing an event filter on a push 
button on press that eats all mouse release events. It is hard for the 
toolkit to know why you might not want the button to remained pressed down in 
this case.

Matthias