Mouse wheel bug Windows

General JUCE discussion
1

Hi Jules,

When two (or more) different Juce-based plugins (I used the demo plugin and a blank plugin created with the Introjucer, both Release builds) are open (e.g. both GUIs are visible) only the last opened will receive correct mouse wheel messages. The others will always get a maximum increment (e.g. positive, no matter in what direction the wheel was moved).
This doesn’t happen in the 64-bit plugins, though I only tested 64-bit on our plugins.

I traced this back to juce_win32_Windowing.cpp:1956

return peer->peerWindowProc (h, message, wParam, lParam);

The wParam is already wrong, so it seems Windows is sending a wrong value.

OS is Windows7/64, VS2008EE, Juce tip.

Chris

2

Sounds like it must be related to the VST mouse hook, but I can’t see why it’d go wrong like that. Wheel events that aren’t used by the plugin should be passed on to the next client…

3

Hi Jules,

I must admit I’m at a loss solving this. I just checked the quite recent (from monday or tuesday) modules tip, but the bug still seems to be there. I used the JuceDemoPlugin plus a plugin created with the Introjucer where I simply added a slider. When I load both plugins, only the one last loaded receives meaningfull mouse wheel messages.

Could you take a look at this.

Thanks,
Chris

4

I can’t see anything wrong… Does it make a difference if you remove the ‘return’ statement so it always calls the next hook function, i.e:

[code] LRESULT CALLBACK mouseWheelHookCallback (int nCode, WPARAM wParam, LPARAM lParam)
{
if (nCode >= 0 && wParam == WM_MOUSEWHEEL)
{
const MOUSEHOOKSTRUCTEX& hs = (MOUSEHOOKSTRUCTEX) lParam;

        Component* const comp = Desktop::getInstance().findComponentAt (Point<int> (hs.pt.x,
                                                                                    hs.pt.y));
        if (comp != nullptr && comp->getWindowHandle() != 0)
            PostMessage ((HWND) comp->getWindowHandle(), WM_MOUSEWHEEL,
                         hs.mouseData & 0xffff0000, (hs.pt.x & 0xffff) | (hs.pt.y << 16));
    }

[/code]

5

Unfortunately no change.

I looked at the value of hs.mouseData for good and bad events. Working events result in 0x780000 for up and 0xFF880000 for down while in case of the ‘bad’ events it is always 0x75209e2e.

I added a check for the lower bytes of hs.mouseData being zero:

if (comp != nullptr && comp->getWindowHandle() != 0 && (hs.mouseData& 0xffff) == 0)
  return PostMessage ((HWND) comp->getWindowHandle(), WM_MOUSEWHEEL, hs.mouseData & 0xffff0000, (hs.pt.x & 0xffff) | (hs.pt.y << 16));

With this modification after opening another plugin the previous ones only get mouse wheel messages if one instance of them has keyboard focus (I had to click on them). So if I open three different plugins the third always gets mouse wheel messages, while the other ones need to get keyboard focus in order to receive mouse wheel messages. In case of several instances only one has to get keyboard focus.

Could the reason for this be related with Windows’s dislike of non-focused windows getting mouse wheel messages?

Chris

6

Yes, definitely. Bear in mind that all this event hooking is just a workaround to try to improve Windows’ crappy mouse-wheel behaviour. If it’s not working, you still get the normal events, just like any other Windows app.

7

So even without registering the mouse wheel hook, components would receive mouse wheel messages?

Can you see any downsides in the above mentioned change, and if not could you put it into Juce.

Chris

8

According to MSDN, the low-word of the mouseData value is “reserved and undefined”. I can’t publish code that makes any assumptions about it.

9

I think the behaviour with the mentioned patch also is the same than simply removing the hook.

Would you consider removing the hook or making it switchable?
I must admit I don’t see any advantages when it only works as long as one Juce plugin is opened.

Chris

10

Well, I guess that the advantage is that if you’re only using one plugin, at least it’s better than nothing.

11

Hi Jules,
Have you worked on this bug since last year?
Thanks
Raph

12

No, haven’t got anything to add.

13

Bumping this. Just started experiencing this with our plug-ins. Is this on the roadmap for getting fixed?

14

Its a windows bug: User should install this fix:

 

https://support.microsoft.com/en-us/kb/2752274

15

Thanks for the fast reply! That makes sense that I wasn't able to reproduce it on our computers then, since I keep all of them up-to-date with everything on Windows Update. I'll forward this to the customer.