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:
But the thing is it’s really old. Would the current best approach still use this way, or would you recommend something else?
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…
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?
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…
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