[Solved] disable mouse wheel event on ComboBox

[openBrain]

With SpinBox, you mean below?
fsc_2020-06-03_152425.jpg

Exactly. Your screenshot makes me think that probably the QListView is also concerned...

[wmayer]

git commit c90db641881
In order to activate the filter you must create the boolean key ComboBoxWheelEventFilter in the group General and set it to true.

Newly introduced parameter is now documented in Fine-tuning

@wmayer : could you please extend the event filter to also return false on QAbstractSpinBox class ? Spin boxes suffer the same issue as combo boxes. Thx.

I don't know what you are after but filtering wheel events for spin boxes might not be what you actually want. If you click on a spin box and scroll it won't change the values any more -- don't know why this behaviour should be desired.

What I can imagine what you want is that if the mouse cursor is over a spin box that hasn't the focus it steals the focus when scrolling. To avoid this filtering wheel events doesn't work.

See: https://stackoverflow.com/questions/582 ... focus-when

[openBrain]

I don't know what you are after but filtering wheel events for spin boxes might not be what you actually want. If you click on a spin box and scroll it won't change the values any more -- don't know why this behaviour should be desired.

What I can imagine what you want is that if the mouse cursor is over a spin box that hasn't the focus it steals the focus when scrolling. To avoid this filtering wheel events doesn't work.

Yep that's it. The idea is to prevent spin boxes to automatically steal focus on wheel events, so that it's possible to seamlessly scroll scrollable areas.
But you're right that it's not so simple as just catching the event at App level.
Thx for comprehensive reply (as usual).

[wmayer]

Most of the suggestions in the SO thread offer a way by sub-classing. IMO this is not a good alternative as it cannot be guaranteed that nowhere a QSpinBox or QDoubleSpinBox is used -- hence no consistent behaviour possible.

One of the solutions offer a way without sub-classing but it still requires to explicitly set the focus policy in client code which is cumbersome too.

Here is my solution that works without sub-classing and without touching client code. It sets the focus policy of a spin box as soon as it becomes visible and only accepts wheel events if the spin box has the focus.

git commit fcddee292

[openBrain]

Most of the suggestions in the SO thread offer a way by sub-classing. IMO this is not a good alternative as it cannot be guaranteed that nowhere a QSpinBox or QDoubleSpinBox is used -- hence no consistent behaviour possible.

One of the solutions offer a way without sub-classing but it still requires to explicitly set the focus policy in client code which is cumbersome too.

Here is my solution that works without sub-classing and without touching client code. It sets the focus policy of a spin box as soon as it becomes visible and only accepts wheel events if the spin box has the focus.

git commit fcddee292

I totally agree with your remarks. Neither impose sub-classing nor having to hardcode focus policy is an acceptable solution.

Regarding your commit :

• I like it, looks clever
• I hate you. This is kind of coding challenge I'd have liked to look at. But you're to easy at dealing with it.
• Just a remark. In the specific case of Wheel type event, Qt strongly recommends to explicitly accept() or ignore() the event (especially ignore() is important to ensure the event is pushed to parent).

[wmayer]

Just a remark. In the specific case of Wheel type event, Qt strongly recommends to explicitly accept() or ignore() the event (especially ignore() is important to ensure the event is pushed to parent).

In eventFilter() you usually don't have to explicitly use accept() or ignore() because with the return value of true/false you define if an event should be filtered or not.
According to the Qt doc only for QEvent::ShortcutOverride an explicit call of accept() is required. And this makes sense because ShortcutOverride is a special event that is sent when a key is pressed and a receiver can claim to handle it. The QApplication will realize it and send a key event directly to the receiver. This is a nice way to achieve some sophisticated shortcut handling.

The accept() and ignore() methods most of the time are used in the event handlers like closeEvent(), showEvent(), hideEvent(), ...

[openBrain]

According to the Qt doc only for QEvent::ShortcutOverride an explicit call of accept() is required. And this makes sense because ShortcutOverride is a special event that is sent when a key is pressed and a receiver can claim to handle it. The QApplication will realize it and send a key event directly to the receiver. This is a nice way to achieve some sophisticated shortcut handling.

The accept() and ignore() methods most of the time are used in the event handlers like closeEvent(), showEvent(), hideEvent(), ...

According the Qt doc, I think I'm right on this one.

QtwheelEv.png (11.18 KiB) Viewed 1978 times

Anyway, I saw some cases where it was omitted and it seems to work correctly though.

[wmayer]

According the Qt doc, I think I'm right on this one.

You may do this in the event handler wheelEvent() but not necessarily in the eventFilter()

[openBrain]

You may do this in the event handler wheelEvent() but not necessarily in the eventFilter()

You may, but this isn't what doc advises (it's a "should", not a "shall"). Anyway, this was just a remark, you can take or not.

[fc_tofu]

Many people who suffered from mouse wheel will benefit from @wmayer fix.
And IMO, “ComboBoxWheelEventFilter"=Ture could be made default vaule in future build.
Also hope some discussions.