1

I have a DLL that I am injecting to DX games. In the DLL, I am disabling XInput, raw input and also subclass WndProc to filter a bunch of input messages like WM_MOUSEMOVE, WM_LBUTTONDOWN, WM_INPUT etc. Disabling XInput with XInputEnable(FALSE) and register raw devices with RIDEV_REMOVE flag.

While it works great for some games, it doesn't work for all. Certain games still have mouse move/hover input and I can see hover state for some UI when I move over.

My question is what did I miss? Could the game be capturing input some other ways?

Thank you.

Kenny Lim
  • 1,193
  • 1
  • 11
  • 31

1 Answers1

1

I can think of these possible ways the application may still be receiving mouse input:

  • It re-enables Raw Input notifications
  • A window other than you one subclassed is receiving the messages
  • It's polling GetCursorPos
  • Using the Windows HID API or other user-mode interface to access the mouse device
  • Hooking mouse events or windows message using SetWindowsHookEx

The are probably others, but these are all I can think of at the moment.

Ross Ridge
  • 38,414
  • 7
  • 81
  • 112
  • Sounds like it is possible for the Game to create another thread and poll for input. Are there any way to get around that? Other than SuspendThread :-) – Kenny Lim Nov 20 '14 at 00:36
  • It wouldn't have to create another thread to use `GetCursorPos`. It could be called once a frame in the same thread used for rendering. – Ross Ridge Nov 20 '14 at 00:44
  • So this happens in the game loop. Do you know of any ways to disable that? Sounds impossible to me. – Kenny Lim Nov 20 '14 at 02:22
  • 1
    You can hook `GetCursorPos` and have it return some other value. How to do that is another question: http://stackoverflow.com/questions/873658/how-can-i-hook-windows-functions-in-c-c – Ross Ridge Nov 20 '14 at 03:20
  • Ok this is not impossible.. but not really practical as it needs to replace system DLL. – Kenny Lim Nov 20 '14 at 03:47