Question

I'll try to keep this as short as possible.

I have an app that has worked for years with a single mouse input. I am looking to incorporate the ability for my users to use other forms of input, such as interactive projectors, touch devices, or pretty much anything that provides WM_INPUT messages when you register for them.

The general idea I had was I would have a list of Vendor IDs and/or Product IDs that I would handle with Raw Input (which provides VID/PID, device handle and other information) for each message (WM_INPUT) received. Any devices that are not handled in the Raw Input code would be handled in the Mouse Input code (WM_MOUSEMOVE, WM_LBUTTONDOWN, WM_RBUTTONDOWN, etc).

Ideally, I would be able to leave all of my Mouse Input code as is, or close to it. This way, if a user plugs in two mice, or a mouse and an unsupported pointing device (meaning my Raw Input code doesn't handle it based on VID/PID) the devices would both use the same system cursor. Any device that is known by my Raw Input code would be given separate cursors that exist only within my app.

The problem is simple: Mouse Input does not provide any information about the source of the message (such as WM_MOUSEMOVE, etc). Knowing that the message originated from touch helps (I have this implemented) but is definitely not enough. I need some kind of unique identifier. If I could know the source of the Mouse Input, I could only handle Mouse Input from devices that aren't on my list of known devices, and I could only handle Raw Input that are on my list of known devices.

Unfortunately, I cannot seem to find a way to achieve this.

Any ideas?

Thanks for your time sorry for the lengthy post.

TL;DR - Can you identify the source of Mouse Input (not Raw Input) in Windows? Determining whether or not the source is touch is not enough information, I need some kind of unique identifier.

Mouse Input - http://msdn.microsoft.com/en-us/library/windows/desktop/ff468877(v=vs.85).aspx

Raw Input - http://msdn.microsoft.com/en-us/library/windows/desktop/ms645536(v=vs.85).aspx

Was it helpful?

Solution 2

edit2: The answer to this question is "Not possible", you can't do it. Don't bother trying, but if you do and I'm wrong please explain. The fact of the matter is you can't rely on Windows to provide messages in any particular order consistently, which is what I was attempting to do. This bit me big time. Either use raw input (WM_INPUT) or use mouse messages (wm_mouse) don't try to combine the two somehow.

I never really got the answer I wanted, but I got something that works so I thought it was worth sharing.

I am working on a huge assumption, as I can't find any documentation from Windows to support this assumption (and probably wouldn't really even trust it if I found documentation from windows). To my understanding, when a mouse event is generated at the lowest level it comes through the system as a raw input message first (WM_INPUT). After the WM_INPUT message is posted, the OS gets the message and applies the ballistics and whatever else it does before a WM_*MOUSE* message is posted. The huge assumption is that this process is serial in that it is always 1 WM_INPUT message followed by 1 WM_*MOUSE* message in the queue.

With this assumption I am working with the following: When an input message is received, store all relevant information about the source device as the "current input information" When a mouse message is received, process it using the "current input information" as the source of the mouse message

This allows me to use n inputs in my application independently.

I'd also like to add that per Brandon's suggestion I am using the hDevice member of the RAWINPUTHEADER structure to uniquely identify each input. Since a unique device can have multiple inputs, I have yet to come up with a good way of uniquely identifying each device. VID/PID doesn't work because you can have 2 of the exact same device with multiple inputs each plugged in. I'm still working on this, see Windows HID Device Name Format

Please let me know if anyone would like me to elaborate!

edit: not marking this as the answer since I believe the correct answer is "Not possible"

OTHER TIPS

I don't know of any API for getting some sort of device id after the fact.

You could use the fact that WM_INPUT messages come before all other input messages, and when you handle WM_INPUT you could use GetRawInputDeviceInfo and a hash of the name returned by RIDI_DEVICENAME to use as a unique id. Or, you might be able to use the hDevice member of the RAWINPUTHEADER structure.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top