Mouse wheel stopped working

[peterpiper0815]

Hi. I recently switched from


Windows7
OpenMPT (x86 (32 bit))
Version 1.30.05.01-r17639 TEST

to

Windows7
OpenMPT (amd64 (64 bit))
Version 1.30.10.00

and realized that the mouse wheel act differntly now. For example in the sample edit window I used to play the sample (so the 'mouse focus' was in the lower part of the window) while I changed parameters in the upper window part with the mouse wheel (like Golbal Volume, Freq, Transpose and even pulldown like LOOP OFF/ON/BIDI.
The mouse focus was automatically on the parameter but I still was able to play the sample with the PC keyboard.

With the new version this behavior is not present anymore. I have to click the parameter to change it.
This also applies to plugins.

I searched in the settings cause I wondered if I overlooked something but didn't find an answer.

Bug or Setting (OpenMPT/Windows) or reasonable decision to disable the feature?

thanks

[Saga Musix]

There was no such change in OpenMPT. You should be able to verify this easily by reinstalling OpenMPT 1.30.05.00. I can still use the behaviour you descibed in OpenMPT 1.30.10.00 (no matter if 32-bit or 64-bit version). Are you using the exact same machine with exact same drivers when comparing the behaviour? All I know is that some touchpad drivers implement scrollwheel emulation differently from how a physical mouse would work, which could explain such behaviour.

[peterpiper0815]

Ok thanks. Good to know that there wasn't any change on that.

1. I use the portable version(s). Completly different folders.
2. Exact same machine
2. cheap mouse from 'Trust'. the simplest mouse.

But I tested some things.

1. Different user accounts (The machine/Win7 has 2). The other user account is the Admin account and on this account none of the versions worked with the mousewheel.

2. Then I changed the display settings on this user account (I usually turn off bling bling stuff and like to work with classic design instead of an AERO design). With this setting the wheel worked again on 1.30.05

3. Then I checked with my notebook (Win7 64bit and of course with the same mouse). Same results.

4. The notebook also have a Linux Mint installation with wine and BOTH versions worked with the mousewheel.   

Seems (to me) that I have to check some Windows settings. As I mentioned before after a fresh installation I turn off some things (display settings, instaling classic explorer etc).



EDIT: But wait. If it's application/version dependet it can't be a windows global setting. can it?  (voice in my head: Why are you on windows anyway?  )

[peterpiper0815]

Update:
Still no correct behavior on Win 7 Pro. Here is what I tried:

Hardware: Another PC, two different mice (both mice show same behaviour), used the onboard soundcard.

OS: Windows 7 Pro Clean Install (no tweaks etc. Plain OS)
OpenMPT-1.30.11.00-portable-amd64-legacy.zip
Focus stay on the lower part of the display no matter where the mousepointer is. When I hover over the transpose field the fielt turn from grey to blue but it won't change the value when I move the wheel. Instead the (zoomed in) waveform move (correct default behavior when the pointer is on the lower display)


OpenMPT 1.30.11.00 Installer
Same as above


OS: Windows 10 Clean Install
OpenMPT-1.30.11.00-portable-amd64-legacy.zip
It works. Wherever the pointer hover over, the value change when mousewheel is used.

OpenMPT-1.30.11.00-portable-amd64.zip
It works. Wherever the pointer hover over, the value change when mousewheel is used.

[Saga Musix]

For what it's worth, I fired up an old Windows 7 VM and even with the very old OpenMPT version that was installed there (1.28) I get the same behaviour. Both with Windows 2000 look and Aero basic (no transparency effects). I could imagine that the behaviour depends on DWM being used for rendering Windows, but I think DWM is only only used when Aero with glass effects is activated, which I cannot do in this VM. Control panel dialogs behave exactly the same way. Which makes sense, because all of this logic is driven by the operating system. OpenMPT's code is not involved with deciding when the scrollwheel is allowed to interact with unfocussed elements.

[peterpiper0815]

Thank you for testing it and the info about DWM.
I probably use the mentioned PC with Windows 10 for OpenMPT (performs much better than my old PC and I managed to record the screen without dropout. Probably doin some 'Tutorial'-like videos for OpenMPT)

However I also found a tool called 'xmouse button control' which enabled the correct scrollwheel behavior on Win7.

I just wonder how on earth I (accidently) managed to enable the wheel on the older 1.30.05 version. 

Again thank you. I love OpenMPT

[LPChip]

For what it's worth, I fired up an old Windows 7 VM and even with the very old OpenMPT version that was installed there (1.28) I get the same behaviour. Both with Windows 2000 look and Aero basic (no transparency effects). I could imagine that the behaviour depends on DWM being used for rendering Windows, but I think DWM is only only used when Aero with glass effects is activated, which I cannot do in this VM. Control panel dialogs behave exactly the same way. Which makes sense, because all of this logic is driven by the operating system. OpenMPT's code is not involved with deciding when the scrollwheel is allowed to interact with unfocussed elements.

Its probably an Hardware Accellerator thing, if it works in the VM for both options, because a VM usually have hardware accelleration turned off, and also, switching to classic view should turn off hardware accelleration.

See also: https://www.majorgeeks.com/content/page/how_to_disable_or_adjust_hardware_acceleration_in_windows.html#:~:text=Hardware%20acceleration%20was%20more%20prominent,,%208,%20and%20Vista%20days.&text=Press%20the%20Windows%20Key%20+%20S,GPU%20scheduling%20on%20or%20off.

[Saga Musix]

Hardware acceleration does not change how mouse input events are treated, but as already said it may change whether DWM is used for window compositing or not, and that is the most likely candidate for me to influence this behaviour.