Does something like `acceptsMouseWheel_(false)` exist?

[tedmoore]

Greetings,

Whenever I mouse scroll (i.e., two finger swipe on my MacBook Pro) while the mouse is over a PopUpMenu the menu changes, which I don’t want it to do. This also happens with EZSliders. A mouse wheel or mouse scroll will change the slider. I don’t want any of my GUIs to respond to this. I want to specify for each of these GUIs something like .acceptsMouseWheel_(false) or something that would cause the equivalent. Any suggestions?

Thanks,

Ted

[jamshark70]

@tedmoore

I want to specify for each of these GUIs something like .acceptsMouseWheel_(false) or something that would cause the equivalent.

There isn’t directly this feature. But there is key and mouse event propagation:

If you wish to control whether the event will be propagated or not, return true or false from the action. True means you have responded to the event, and the propagation will be stopped; false means you are not interested in the event, and the event will propagate. However, returning either true or false will completely bypass the view’s C++ implementation, so it will not get a chance at responding to the event with its standard behavior.

So, in theory, myView.mouseWheelAction = { true } should block the wheel from doing anything in the view (including scrolling the parent); setting it to { false } should block the view’s wheel action and pass it up to the parent (where, if the parent is a ScrollView, should keep scrolling). But I haven’t verified that it works as advertised.

FWIW a GUI framework that begins responding to scroll events in one view (e.g. a scrolling container) and then latches onto another view mid-scroll is IMO careless – that is, this may be Qt’s fault. I saw this behavior in other software too and it’s truly awful.

hjh

[wehrk]

I’m experiencing an opposite problem where the scrolling function has suddenly stopped working for me. I can no longer scroll through any PopUpMenu. What might be causing this issue?

[Dindoleon]

This is unlikely, but this could be related to a change in the PopUpMenu file, or one of it’s parent classes. Did you modify the classes files ? Do you have installed Quarks that might be modifying PopUpMenu’s behavior ? Does it concern other scrollable widgets ?

My best guess is that it is a problem with the OS. Maybe the signal it fires isn’t recognized by SuperCollider. What OS are you using ? Is it a problem with the mouse wheel ? The track pad ? Both ?

[wehrk]

Thank you for suggestions. I revised all the installed quarks. That behaviour was introduced by the ... quark

UPD: sorry for mentioning the wrong quark. Actually it was introduced by the 3.13.0 macOS x64 build of SC