Detecting Touch input vs Mouse input

Detecting Touch input vs Mouse input


I'm starting with Ultrabook development.

I would like to know if there is a simple way to know if the user input is being done with the traditional mouse or if he/she is touching the screen at a particular moment.

As the events are not exactly the same when touching the screen than when using the mouse, I think it is needed to tell the difference to be able to handle the legacy mouse properly, isn't it so?

Any info regarding this will be appreciated.

I'm using C/C++.

Thank you,






10 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Well I've seen the SENSOR_TYPE_TOUCH under the Biometric Sensor Types.
I guess I can ask for its property SENSOR_DATA_TYPE_TOUCH_STATE to be true, anyone agrees? Does that correspond to the touch screen?
Many thanks.

Hi Manuel,

It might help to know what you are trying to do, for example are you trying to 'switch off' mouse events generated by touchpad and/or external mouse or are you trying to handle touch events in a different manner to the 'out of the box' experience?


Hi David,
Given a mouse click, I would like to know from where does it come from.
The reason is that I want to handle slighty different the same event, depending on the device that originated it.
Any reason why this doesn't make sense? I thought this was a somewhat common problem.

Hi Manuel,

I understand what you want to do but you may find the OS makes it difficult to determine source of event turning the touch event into a mouse event but I could be completely wrong. You will need to look at the window messages to see what information is available.


The API's allow you to detect specific aspects of mouse and touch events, however Microsoft is allowing, one to trigger the other. ie a tap on screen is counted as a mouse action. You could possibly build a filter on your app to look for one event while the event is null. Never tried it but that might work to determine where the event is coming from. Also a mouse has hover state, that could be use to knoww if the mouse moved over a coordinate before clicked. So you might need to get creative


David and Bob are right, on the desktop side if you don't handle the events yourself they will be filtered and appear as mouse events.
but then you can use GetMessageExtraInfo() on mouse up / mouse down messages. Mask the returned value with 0xFFFFFF80, then if the result is equal to 0xFF515780: the message comes from a touch event, equal to 0xFF515700: the message comes from a pen.

Also, if you register to the WM_POINTER (Windows 8 desktop specific) events you can use the GetPointerType function on the pointer id you will receive.
It will return exactly what you are looking for.

For Windows Store apps, here is a sample that shows you how to do it:

Thank you all.
@Xavier, best answer. I was in need of implementation clues.

I used the GetMessageExtraInfo() as you described and described here:
(very similar to your explanation, except that it says 0xFFFFFF00 and 0xFF515700, instead of your proposed 0xFFFFFF80 and 0xFFFFFF80, that I suppose that are for pen/touch identification).

And it works very well. It can tell if any event comes from a touch surface or a physical mouse. This is what I was looking for.

Now please, what do you mean with "if you don't handle the events yourself"?
Is GetMessageExtraInfo() a good practice or should I handle the events in other way?

Many thanks.

I meant that touch events (WM_TOUCH or WM_POINTER messages) are transformed into mouse events if you don't handle them.

GetMessageExtraInfo() is neither a good or bad practice but if your app needs to handle touch properly that's always better to rely on things that are designed for it, like WM_POINTER.

Alright, many thanks for the additional clarification. It is much clearer now.
By now we got GetMessageExtraInfo working, but we'll try to move into GetPointerType.
Many thanks for all your support. It has been crucial to take our first steps.

Leave a Comment

Please sign in to add a comment. Not a member? Join today