11

I have successfully installed a WH_GETMESSAGE hook with SetWindowsHookEx and I can see the WM_POINTERDOWN, WM_POINTERUP etc. messages that the application receives. (It is a 32 bit desktop application running on Windows 8.1.)

Now, I not only want to see those messages, but I want to remove some of them.

The documententation for GetMsgProc says:

The GetMsgProc hook procedure can examine or modify the message. After the hook procedure returns control to the system, the GetMessage or PeekMessage function returns the message, along with any modifications, to the application that originally called it.

With WM_KEYUP messages this seem to work fine. I can set the message to WM_NULL in the hook, and the key event will disappear.

With WM_POINTER... messages however, this does not seem to work. The application still receives the messages (validated in the debugger).

Maybe there is some other way to filter/remove such messages?

Edit: It has to work with unmodified third-party applications (hence the usage of a hook).

Update: I managed to prevent click events from touch by aggressively calling PeekMessage within the hook (probably not a good idea in the long term). However, I still can't prevent scrolling by touch.

wmeyer
  • 3,426
  • 1
  • 18
  • 26
  • What is the purpose of discarding the messages? – ta.speot.is Jan 14 '14 at 09:34
  • @ta.speot.is: The idea is to recognize certain gestures within the hook. The pointer messages should then not be processed by the application because they were already handled in the hook and should not result in scrolling or mouse movements in the application. – wmeyer Jan 14 '14 at 09:51
  • It has to work with unmodified third-party applications (hence the usage of a hook). – wmeyer Jan 14 '14 at 10:08
  • It seems to me that `WH_GETMESSAGE` is intended for monitoring and modification but not removal. It seems that `WH_KEYBOARD_LL` and `WH_MOUSE_LL` do allow removal with both showing this in the documentation: *it may return a nonzero value to prevent the system from passing the message to the rest of the hook chain or the target window* – mark Jan 14 '14 at 13:10
  • Removing DOES work with Keyboard Messages. Nevertheless, this sounds interesting. I will check whether a `WH_MOUSE_LL` hook receives `WM_POINTER...` messages. But even if doesn't, I might be able to filter the *resulting* mouse messages. – wmeyer Jan 14 '14 at 14:12
  • Unfortunately, that does not seem to work. `WM_POINTER...` messages don't reach the `WM_MOUSE_LL` hook. Also, filtering mouse events is not enough to prevent scrolling by touch. – wmeyer Jan 14 '14 at 21:59
  • if nothing helps, you could approach it with an api hook, either handwritten or using something like http://research.microsoft.com/en-us/projects/detours/ – wonko realtime Jan 16 '14 at 19:26
  • @wonkorealtime: Thanks! I will consider this option (although it does sound kind of invasive ;). – wmeyer Jan 17 '14 at 16:37
  • C# has something called IMessageFilter which I think works exactly as you want. I wonder if there's a C++ equivalent. – Kyle Delaney Jun 23 '17 at 23:42

1 Answers1

2

Solution 1:

WH_GETMESSAGE is not designed to remove or modify messages, only to monitor them. Unfortunately, mark's alternate solution - using WH_KEYBOARD_LL and WH_MOUSE_LL - didn't appear to solve the problem either (because multitouch doesn't fall into the category of a mouse message). Sorry, mark!

I'd like to point out WH_CALLWNDPROC, which receives messages before their intended window. This seems to be the accepted way to modify messages.

Solution 2:

It's possible that the target window doesn't care about WM_POINTER... messages at all! It could be detecting touch input through the Raw Input API, like this demo here. Try keeping an eye out for WM_INPUT messages as well.

Note 1: Raw Input messages can be removed, but cannot be modified or created.

Note 2: I'm not entirely sure, but unhandled WM_INPUT messages might create a memory leak because the thing is practically one massive pointer. Just in case, handle the messages in your hook procedure.

Proxy
  • 1,824
  • 1
  • 16
  • 27
  • Thanks for your suggestions! However, I still had no success. Modifying or removing messages in `WH_CALLWNDPROC`does not work at all, not even for keyboard messages. Removing `WM_INPUT` messages does not prevent scrolling or clicking from touch. I start to believe that Windows handles "touch scrolling" on a very fundamental level... – wmeyer Jan 17 '14 at 15:34
  • @wmeyer may I ask on what application you are testing this? – Proxy Jan 21 '14 at 15:13