WM_MOUSEWHEEL messages never arrive. Why?

[AlionSolutions]

This is just strange. For the first time I wanted to use messages from the mousewheel in Win32 API. So I put this in my Windowprocedure :

LRESULT CALLBACK AFDrawArea::WindowProcedure (HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam)
{
  switch (message)                  
  {
    case WM_MOUSEWHEEL:
    {
        MessageBox(0,"WHEEL","WHEEL",0);
    }          
    break;    
    default:                      
      return DefWindowProc (hwnd, message, wParam, lParam);
  }
}

The actions I want to take place on a mousewheel event are of cause more sophisticated but I just put this in to get some visual feedback after it all didn't do anything.

The strange thing is, that however and how much I move the mousewheel, NO WM_MOUSEWHELL event seems to come in. I put the same piece of code in the WndProc of the parent window and it worked.
So I suppose, that the problem is, that the window I want to recieve WM_MOUSEWHEEL messages from is a child window.

Is there any special class style etc. a wihndo must have to recieve WM_MOUSEWHEEL?

Thanks for any help
Sonny

[Igor Vartanov]

LRESULT CALLBACK AFDrawArea::WindowProcedure (HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam)
{
  switch (message)                  
  {
    case WM_MOUSEWHEEL:
    {
        MessageBox(0,"WHEEL","WHEEL",0);
    }          
    break;    
  }
  return DefWindowProc (hwnd, message, wParam, lParam);
}

WM_MOUSEWHEEL Message

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.

[Igor Vartanov]

BTW, what is AFDrawArea?

[AlionSolutions]

Thanks Igor! I allready read this on MSDN. But I really dont understand why my childwindow should not have the focus and should therefore receive the WM_MOSEWHEEL messages. The childwindow receives WM_MOUSEMOVE and and all the other messages when the mouse is in it's client area. Really dont know what is so special about WM_MOUSEWHEEL messages. Well, so I have to catch the messages in the parent window and forward them down to the child. That's... errm..stupid

[AlionSolutions]

AFDrawArea ist something you don't have to worry about.
It's a object oriented encapsulation of the window. I don't like to break the object oriented style of C++ just for the OS from Redmond
WindowProcedure is a static member of this class and does work great for all the other messages except for WM_MOUSEWHEEL.

[Igor Vartanov]

Thanks Igor! I allready read this on MSDN. But I really dont understand why my childwindow should not have the focus and should therefore receive the WM_MOSEWHEEL messages.

Well, the MSDN article says, to receive the message the window has to possess the input focus. In case your child does not, the message just won't come to it. (In fact that was the real reason of my asking about what AFDrawArea is )

The childwindow receives WM_MOUSEMOVE and and all the other messages when the mouse is in it's client area. Really dont know what is so special about WM_MOUSEWHEEL messages. Well, so I have to catch the messages in the parent window and forward them down to the child. That's... errm..stupid

Sorry, no intention to offend, but I don't really see what good could come from such criticizing. The things are as they are. This is not a bug, it's just a matter of design. This is a Win API design you just cannot change, you grouch or not. Calling stupid publicly the other people which give you a chance to do your job looks a bit... childish?

[olivthill2]

For your information, here is how I handle the WM_MOUSEWHEEL message

   case WM_MOUSEWHEEL:
      if (((short) HIWORD(wParam))/120 > 0 )
         PostMessage (hwnd, WM_VSCROLL, SB_LINEUP, (LPARAM) 0);
      if (((short) HIWORD(wParam))/120 < 0 )
         PostMessage (hwnd, WM_VSCROLL, SB_LINEDOWN, (LPARAM) 0);
      return (0);

[AlionSolutions]

Sorry Igor, didn't mean to offend too. But I coded on various operating systems since 1986 and the Win32 API is in my opinion the worst stuff I ever came across. From the other operating systems APIs I know that stuff can be implemented in a much more clever way than the folks in Redmond did it. The fact alone, that it is a major pain in the butt to wrap that API into a object oriented fashion like with C++ gives me the creeps. Yes, I call that API stupid and nothing will keep me from doing that

Thanks olivthill2! My solution looks pretty much the same

[Igor Vartanov]

Your point taken. About API being not object oriented enough. As for me the issue looks far less painful than if the API evolvement would break backward compatibility in favor to perfect OOP compliance. This is my personal opinion nobody could keep me from staying with.

As for me, being a bit illogical, but consistently illogical, looks much better than re-tailoring the stuff in accordance with modern fashion influences (including OOP ). Besides as I said, the issue we talk about is just a matter of design. You consider WM_MOUSEWHEEL as something similar to WM_MOUSEMOVE. But if you tried to think of it as a sort of input similar to WM_LBUTTONDOWN or WM_KEYDOW, the things would become to look more sensible.

[ovidiucucu]

Just keep in mind that Windows API is written in "plain-raw-blind-deaf" C, which is a great procedural programming language but not an object-oriented one.

BTW. Can you name an OS with a "clever" API which treats WM_MOUSEWHEEL in a most OO manner...

... since 1986

?

[Uglybb]

It was worse than that originally there was no such thing as a mouse with a mousewheel.

The API was built around a two button mouse it had to be extended to work with a 3 button mouse and then along came a mouse with a scroll wheel.

Everything is easy in hindsight ... I mean who would ever need a hard disk with more than 512Mb of data ... right?

The programmers did what they could to get new functionality into an already existign API structure and no the result was not pretty but it works.

[chmiel]

Hi, I wonder if you can help clear this up about the focus. I am experiencing the same problem in a window, an MFC CWnd. I have overridden OnMouseWheel, added the ON_WM_MOUSEWHEEL() command router. I find that the wheel message goes the the very top level window, which is a problem since it's not mine (its a calling app). I just don't understand why the window does not have focus - if I click, for example, the OnxBtnDown is triggered for the window in question. I have tried explicit SetFocus() and that does not work either.

Any light or help greatly appreciated!