[C++] WM_MOUSEWHEEL message not working?

To make things simple, I have this:

1
2
3
4
5
6
7
8
9
__________
|        |
|________|
| T X X  |
| T X X  |
| T X X  |
| T X X  |
| T X X  |
|________|


And that part with the T X X scrolls. The X's are text boxes, and the only time the window that holds them gets the WM_MOUSEWHEEL message is when I click on one of the edit boxes. Only when an edit box has focus does it get the message.

So how can I make it to where I'll get the message when my mouse is over the second box (With the [T X X]'s) and not just when I have an edit box with focus?

Also, how do I find out the direction of the mouse wheel? MSDN says:
A positive value indicates that the wheel was rotated forward, away from the user; a negative value indicates that the wheel was rotated backward, toward the user.

However, I always get a positive value when I use HIWORD(wPararm).
Last edited on
*Bump*
The same MSDN page that you got that bit of information from also probably said something like:
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.


What is that second box (that holds the [TXX]'s] ? Is it something that would normally get the
input focus??

(But I think we can 'cheat' our way around it - I prefer to call it using our initiative)

Last edited on
Okay, I missed that part. So how do I pass it to that box when that box is being hovered? No, that box wouldn't normally have the focus.

The second question remains as well.
Tests show that if certain child control windows have the focus and they get a mousewheel message - and they have no use for it then windows will pass it up the chain to the parent window.
These types of controls include Edit boxes, butons.
That is why your main window gets the mousewhell message when as you say the editbox have the focus.

Other controls such as listboxes and comboboxes when they have focus makes use of mousewheel messages - they use it to scroll through their lists - and do not pass the mousewheel message up the chain.

I see an easy out of your problem (I tested this)

If your MainWindow is getting WM_MOUSEMOVE messages when you move the mouse into that box - then trap the WM_MOUSEMOVE message and set the focus to you mainwindow.
1
2
3
case WM_MOUSEMOVE:
    SetFocus( hwnd);//set focus to main window
    break;


You should now get WM_MOUSEWHEEL messages at the mainwindow.
To be consistent - so that we only use WM_MOUSEWHEEL messages when the mouse is
over the background - during WM_MOUSEWHEEL message check which window has the
focus and only take action when no window has focus or the mainwindow has the focus.
(This will avoid taking action on WM_MOUSEWHEEL message forwarded from those controls
which may have focus but don't use it)

1
2
3
4
5
6
7
8
9
case WM_MOUSEWHEEL:
    //check which window has focus
    HWND hwndFocus;
    hwndFocus = GetFocus();
    //only action messages when mainwindow or no-window has focus. 
    if (hwndFocus == NULL || hwndFocus== hwnd)
        FlashWindow(hwnd,TRUE); //test

break;


So the first thing for you to test is to see if you get the WM_MOUSE move message when the mouse is in that box area .
Last edited on
With regard to the positive/negative values when moving the mouse wheel.
Away from me gave positive values - back toward me gave a negative value.

The problem lies in the way the HIWORD macro works.
When it shifts the wParam to the right, it then perform a bitwise AND with 0xFFFF which sets the top 16bits to 0 - so in other words as an integer it will always look positive.

int x = HIWORD(wParam); // x will always look positive

So you have two choices to preserve signedness:

1. Transfer it to a short int.
short x = HIWORD(wParam); //

2. Or if you want it as a normal int - then you can do a(n ugly ) double cast.
int x = (int)(short)HIWORD(wParam);

Last edited on
Ahh, thanks for all the help!
Did it work for you though??
Yes, I simple told the window with the focus that whenever it gets a scroll command to set focus to the child window. And using short worked quite well as well. Just had to multiply by -1 so the numbers made the scrollbar go in the correct direction.
Topic archived. No new replies allowed.