Strange code in WndProc()

My memory of Petzold style programming is a bit hazy but while trying to locate a bug (in a 3rd party's code) I came across this:-

Code:

---

LRESULT CALLBACK
WndProc(HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam)
{
        switch (message) {

                // Some other stuff

        case WM_MOUSEWHEEL:
        case WM_MOUSEHWHEEL:
                PostMessage(hwnd, message, wParam, lParam);
                return 0;
        default:
                        // calls DefWindowProc() as usual
        }
}

---

The parameters used for PostMessage() are the same parameters received by WndProc() (unchanged). Wouldn't that result in an endless loop whenever WM_MOUSEWHEEL or WM_MOUSEHWHEEL gets received :confused: The effect is just to re-send the message isn't it? (as I said, my memory's a bit hazy on this stuff !!)

you should look also at the message pump loop to draw a conclusion ... moreover, if I recall correctly ( but I wouldn't bet on it ), mouse messages can undergo coalescing, can't they ?

Quote:

---

Originally Posted by superbonzo

you should look also at the message pump loop to draw a conclusion ... moreover, if I recall correctly ( but I wouldn't bet on it ), mouse messages can undergo coalescing, can't they ?

---

Possibly... I remember that WM_PAINT messages can be coalesced but I'm not too sure about mouse messages as they'd usually have different co-ordinates. WM_MOUSEWHEEL and WM_MOUSEHWHEEL could be candidates for coalescing though, I suppose.

The message pump is just the standard Windows one from what I can tell.

the first thing that comes to my mind looking at that code is a lazy and dirty way of ensuring that those messages are processed asynchronously as queued to the pump. Say, suppose there's a self emitted "SendMessage( hwnd, WM_MOUSEWHEEL,..." somewhere else in your code. Normally, this would generate a synchronous blocking call if the invoking thread does not own the pump, or it would bypass the pump invoking the window procedure directly otherwise. Instead, using a code like that the message would be enqueued for later asynchronous processing in both cases.

That said, unless I'm missing something, in order for this to work and avoid the endless loop there should be some further code in either the message pump loop or the window procedure or even somewhere else ( for example, the window proc could have been subclassed ) ... so, if everythings looks 'standard' then I'm confused too ... :)

Just discovered something...

WM_MOUSEHWHEEL seems to be a relatively new message (at least, I can't find it in the definitions for VC8 or eariler). In the 3rd party app it's specifically defined like this:-

Code:

---

#ifndef WM_MOUSEHWHEEL
#define WM_MOUSEHWHEEL 0X20E
#endif

---

I wonder if the intention was to convert one message to the other message - i.e. maybe the code should read:-

Code:

---

LRESULT CALLBACK
WndProc(HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam)
{
        switch (message) {

                // Some other stuff

        case WM_MOUSEHWHEEL:
                message =  WM_MOUSEWHEEL:
                PostMessage(hwnd, message, wParam, lParam);
                return 0;
        default:
                        // calls DefWindowProc() as usual
        }
}

---

I guess that would allow anyone having a 2-wheel mouse to use either wheel for whatever the wheel does in this particular application. That's the only thing that makes sense to me...