overworked
asked on
WM_MOUSEMOVE
How do I get all child windows to propogate WM_MOUSEWHEEL up to my main window. The latest common controls dll includes controls which support WM_MOUSEWHEEL and now the controls are being stingy. I would like to keep them from using WM_MOUSEWHEEL so that my main window can.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
What about WM_NOTIFY messages?
ASKER
Is there a wm_notify for mousewheel messages? I lost my sdk. Gotta go re-download.
No, you don't get WM_NOTIFY messages on a WM_MOUSEWHEEL.
However, you might want to look into the WM_MOUSEMOVE message rather than the MOUSEWHEEL message. This will not fix your problem at all. However, you will get the MOUSEMOVE message less frequently than the MOUSEWHEEL message. The MOUSEMOVE message onvle occurs when the mouse pointer moves to a new pixel. That may be sufficient for your purposes and less taxing on the system.
However, you might want to look into the WM_MOUSEMOVE message rather than the MOUSEWHEEL message. This will not fix your problem at all. However, you will get the MOUSEMOVE message less frequently than the MOUSEWHEEL message. The MOUSEMOVE message onvle occurs when the mouse pointer moves to a new pixel. That may be sufficient for your purposes and less taxing on the system.
ASKER
Hmm, I don't follow in regards to the mousemove. Let me restate my problem: My main window has 10 modeless dialogs which are full of controls and so forth. When user moves mouse wheel, my main window scrolls the client up and down. However, when user clicks on any control, I lose my mouse wheel messages and they go to the control. I want to keep mouse wheel messages for my main window.
The mousemove as opposed to mousewheel is unrelated to your problem. The reason I mentioned it is that there are potentially several mouse wheel messages generated for each mousemove message, thus you ussually would process mousemove rather than mousewheel. Mousewheel occurs whenever the mouse (the physical mouse, not the pointer on the display) is moved. Mousemove occurs only when the mouse pointer on the display moves..
That has nothing to do with your problem, just a suggestion for faster processing. You still have to use the methods I suggested for processing either message. Unless Alexo can ofter a better solution.
That has nothing to do with your problem, just a suggestion for faster processing. You still have to use the methods I suggested for processing either message. Unless Alexo can ofter a better solution.
Do you have a working solution then?
Docs say: "The WM_MOUSEWHEEL message is sent to the focus window when the mouse wheel is rotated. The DefWindowProc function propagates the message to the window's parent. There should be no internal forwarding of the message, since DefWindowProc propagates it up the parent chain until it finds a window that processes it." Meaning, you're SOL.
What about one of the 3 solutions I suggested? Those should work, right? (the message loop one might not, but I think it will.)
Right. But it's the hard work that overworked tried to avoid...
ASKER
Well.. a msg hook on WH_MOUSE is no good cause it doesn't give me the MSG struc. WH_MSGFILTER is no good because it doesn't give me messages posted or sent directly to a control (just the wndproc/dlgproc). Since subclassing every control isn't justified to support a mousewheel (in my opinion), I decided to do a SetFocus after each BN_CLICK, CBN_CLOSEUP, and LBN_SELCHANGE to keep the focus on my main window instead of individual controls.
ASKER