Exactly. Your screenshot makes me think that probably the QListView is also concerned...
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.openBrain wrote: ↑Tue Jun 02, 2020 8:18 pmNewly 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.
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.wmayer wrote: ↑Wed Jun 03, 2020 8:46 amI 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.
I totally agree with your remarks. Neither impose sub-classing nor having to hardcode focus policy is an acceptable solution.wmayer wrote: ↑Wed Jun 03, 2020 12:14 pmMost 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
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.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).
According the Qt doc, I think I'm right on this one. Anyway, I saw some cases where it was omitted and it seems to work correctly though.wmayer wrote: ↑Wed Jun 03, 2020 2:01 pmAccording 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(), ...