JUCE and multiple mice input

[Aros]

Hello,

right now, I am developing a very specific application which needs to handle multiple mice at the same. It’s a kind of a game (not quite though) but that doesn’t matter. I’ve been doing some research on how to best achieve this with juce. Well, I don’t suppose that I can do this just with JUCE. Right? Although… I noticed that MouseInputSource has some kind of index which refers to a specific finger in multitouch environment. I was wondering whether this would also work while having several mice connected to a one computer…

All I am interested in is a mouse delta for all the connected mice. Nothing more.

Anyway, if this can’t be done with JUCE alone, I guess my best bet is to use RawInput on Windows and then also write some platform specific code for Linux (probably using /udev, but I can’t really tell at this point) - i don’t intend to target any other platform. In the end I would like the app to run on Raspberry Pi.

So to use RawInput I would need to handle windows messages, WM_INPUT to be speciffic. JUCE however handles the Windows messages somewhere inside it’s core logic. What’s the best way to get to them? I found this topic:

Win32NotificationWindow

Certain Windows notifications, such as mixer control changes or device arrival/removal, are only delivered as window messages. Since window message handling is inside the JUCE native code, I have implemented my own hidden window whose sole purpose is to receive these notifications. To use it, have one of your classes inherit from this one: class Win32MessageListener { protected: virtual void Win32MessageReceived(UINT uMsg,WPARAM wParam,LPARAM lParam) = 0; friend class Win32NotificationWin…

But the thing is it’s really old. Would the current best approach still use this way, or would you recommend something else?

Thanks!

[daniel]

You made me curious, so I tested here on Mac:

void MainContentComponent::mouseMove (const MouseEvent &event)
{
    DBG ("Mouse #" << event.source.getIndex() << " type:" << event.source.getType() << " pos: " << event.position.toString() );
}

But no matter, if I move on the trackpad or the mouse, always the same index. So to me it seems, that juce doesn’t get that info from the OS. Even with multiple fingers on the trackpad, always index 0 and type mouse.

But kinda remember, that X11 can handle several mice at the same time…
I don’t have a Linux at hand, but it’s worth a try…

Good luck

[Aros]

Well, thanks for trying that out…

Anyway, I will wait a bit if someone responds to that second part.

[matt]

There’s a class in the JUCE source that creates a hidden window in order to receive Windows messages. It’s cleaner than my implementation.

Check out HiddenMessageWindow in juce_win32_HiddenMessageWindow.h in the juce_events module.

You may also want to look at the code for MouseInputSource; it supports multiple input sources, but right now it looks like it doesn’t support multiple mice, just multitouch.

Hope that helps-

Matt

[fr810]

Have you tried this with multiple mice on Linux? I seem to remember that this worked with JUCE out-of-the-box. Try the multi-touch demo in the JUCE demo in JUCE/examples/Demo.

[Aros]

Thanks matt, I’ll have a look at it.

Fabian: Hm, thanks. I don’t have any Linux installation right now. Apart from that on Raspberry that is. I will try at least that, thanks for the tip.

[Aros]

Fabian, I have installed Ubuntu in VirtualBox to be able to try that, but there’s an issue with that… I am able to compile JUCE demo without any error or warning, but when I run it it does not show. I can see the icon on the tray and there is a process… But the Demo itself just won’t go to the front. Ever seen that?

Thanks

[fr810]

Hmm no I’ve never seen this. Which version of Ubuntu are you using?

[Aros]

17.04

I have tried making all the updates, rebooting several times and still no luck.

It’s a clean installation. I have only installed JUCE repositories as mentioned here:

List of Juce dependencies under linux

I had to reinstall a fresh Ubuntu, and therefore grab all the dependancies for Juce…again. So I thought I’d make a little list and share it with you guys, in case it can save someone else’s time … sudo apt-get -y install g++ sudo apt-get -y install libfreetype6-dev sudo apt-get -y install libx11-dev sudo apt-get -y install libxinerama-dev sudo apt-get -y install libxrandr-dev sudo apt-get -y install libxcursor-dev sudo apt-get -y install mesa-common-dev sudo apt-get -y install libasound2-dev su…

…and cloned the repo.

[Aros]

Matt,
I’ve been trying to make a class that would inherit from HiddenMessageWindow but I am not quite sure how to setup the project. I have a problem with files inclusion…

In juce_events.h, there’s this section at the end:

#if JUCE_WINDOWS
 #if JUCE_EVENTS_INCLUDE_WIN32_MESSAGE_WINDOW
  #include "native/juce_win32_HiddenMessageWindow.h"
 #endif
 #if JUCE_EVENTS_INCLUDE_WINRT_WRAPPER
  #include "native/juce_win32_WinRTWrapper.h"
 #endif
#endif

So by default it is not included. So defined JUCE_EVENTS_INCLUDE_WIN32_MESSAGE_WINDOW to 1 before including the juce header.

At this point, the both compiler and Intellisense recognize HiddenMessageWindow, but it still wouldn’t compile. There are a lot of errors. Obviously those are caused by the fact that windows.h is not included. But I cannot see how JUCE internal actually handles this inclusion. I mean surely the native code has to do that. But I cannot see where it is. If I include windows.h manually before including the juce header, most of the errors are gone. There are only these ones left:

cannot convert from ‘const wchar_t *’ to ‘LPCSTR’

which usually happens when the Visual Studio Character Set does not match the usage within files. Well, I don’t want to mess with this as it is obvious I have missed something. Most likely the way how JUCE handles the windows specific code…

[Aros]

Anyone?

[Aros]

OK, the solution for the Windows problem was to define these two macros before including the JuceHeader:

#define JUCE_EVENTS_INCLUDE_WIN32_MESSAGE_WINDOW 1
#define JUCE_CORE_INCLUDE_NATIVE_HEADERS 1

I was digging through the juce modules wondering how come that the modules itself compile just fine even though they use the native code as well and finally found out this. I am however not sure whats the best practice with these macros you need to define before JuceHeader inclusion. Often you have multiple includes which all unfold to inclusion of the JuceHeader and then the compilation of the project is dependent on the include order. That’s because if you first include some file without those specific macros, they will not be included later because the include guards prevent them from doing so. That is not desirable… I thought adding it to the AppConfig.h would be a good idea but then I get name collisions between juce functions and standard functions because the namespaces collide… Best practise?

My current solution is based on moving everything platform specific into one cpp file where I do the inclusion of JuceHeader file with those two defines. But I had to do a lot of tricks with Singletons, Interfaces and virtual functions in order to achieve what would otherwise be a simple thing

The Ubuntu build problem still not solved.