MouseWheel events without focus
-
Has anybody found a way to implement a global message trap, so that no matte what window/control has focus, and no matte where the mouse is pointing, you can listen to the mouse wheel roll messages? I have seen mouse driver settings that say send messsages to the window being pointed at, rather than the window with focus. I want to develop several controls that respond to mouse wheel events without having focus, and I dont want to set focus to them just so that I can "hear" the mouse wheel messages either. Any input, pardon the pun, would be great. Nursey
-
Has anybody found a way to implement a global message trap, so that no matte what window/control has focus, and no matte where the mouse is pointing, you can listen to the mouse wheel roll messages? I have seen mouse driver settings that say send messsages to the window being pointed at, rather than the window with focus. I want to develop several controls that respond to mouse wheel events without having focus, and I dont want to set focus to them just so that I can "hear" the mouse wheel messages either. Any input, pardon the pun, would be great. Nursey
It's exactly the same as a keyboard hook, except it looks at mouse messages. Create an implementation of IMessageFilter and call Application.AddMessageFilter[^] to start it. All you have to do is add the code to watch for the mouse wheel message, documented here[^]. Look through the Windows C++ header files (*.h) for MW_MOUSEWHEEL to find what the constant value is for the message. RageInTheMachine9532 "...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
-
Has anybody found a way to implement a global message trap, so that no matte what window/control has focus, and no matte where the mouse is pointing, you can listen to the mouse wheel roll messages? I have seen mouse driver settings that say send messsages to the window being pointed at, rather than the window with focus. I want to develop several controls that respond to mouse wheel events without having focus, and I dont want to set focus to them just so that I can "hear" the mouse wheel messages either. Any input, pardon the pun, would be great. Nursey
Please note that what Dave said is only for the message pump for your application. You could also set
Control.Capture
totrue
to capture mouse events that you could handle either inWndProc
or even the events that are exposed on theControl
on which you set itsCapture
property totrue
. You could also implement a system hook, but this is very dangerous and not something to be taken lightly - you're hooking every group of messages for the entire platform and your code has to be clean, efficient, and must be unloaded and gracefully fail should any problems occur. There are several articles here on CodeProject about that. Search forSetWindowsHook
to find articles on this site.Software Design Engineer Developer Division Sustained Engineering, Microsoft My Articles
-
Please note that what Dave said is only for the message pump for your application. You could also set
Control.Capture
totrue
to capture mouse events that you could handle either inWndProc
or even the events that are exposed on theControl
on which you set itsCapture
property totrue
. You could also implement a system hook, but this is very dangerous and not something to be taken lightly - you're hooking every group of messages for the entire platform and your code has to be clean, efficient, and must be unloaded and gracefully fail should any problems occur. There are several articles here on CodeProject about that. Search forSetWindowsHook
to find articles on this site.Software Design Engineer Developer Division Sustained Engineering, Microsoft My Articles
Thank you both for your advice, that was just what I needed to hear. I've done quite a bit with subclassing in the past, but as its been a while, and as I would like to know if there is a more ".NET" like way in which this should be done, then it was well worth asking. If I hook into the application message pump, then presumably, as controls run "in process" I will be able to hook into every Windows Forms App that utilises my controls? Many thanks once again. Nursey
-
Thank you both for your advice, that was just what I needed to hear. I've done quite a bit with subclassing in the past, but as its been a while, and as I would like to know if there is a more ".NET" like way in which this should be done, then it was well worth asking. If I hook into the application message pump, then presumably, as controls run "in process" I will be able to hook into every Windows Forms App that utilises my controls? Many thanks once again. Nursey
cnurse wrote: If I hook into the application message pump, then presumably, as controls run "in process" I will be able to hook into every Windows Forms App that utilises my controls? Most likely, yes. It greatly depends on the container application, though. I don't forsee you having any The ".NET" way of things has nothing to do with Windows Forms or anything else, actually. .NET is Microsoft's brand of the CLI, or Common Language Infrastructure. Windows Forms is part of the BCL and actually encapsulates the Common Controls (like Edit, Rich Edit, Static, etc.) and many, many other Windows APIs and other Win32 APIs. Handling messages in this way is nothing different from what Microsoft is doing. That's why the
Control
class defines theWndProc
method (among other Windows Platform-related members) - not just so you can use it but so that they can use it to encapsulates the Common Controls.Software Design Engineer Developer Division Sustained Engineering, Microsoft My Articles