CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Results 1 to 5 of 5
  1. #1
    John E is offline Elite Member Power Poster
    Join Date
    Apr 2001
    Location
    Manchester, England
    Posts
    4,835

    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 The effect is just to re-send the message isn't it? (as I said, my memory's a bit hazy on this stuff !!)
    "A problem well stated is a problem half solved.” - Charles F. Kettering

  2. #2
    Join Date
    Oct 2008
    Posts
    1,456

    Re: Strange code in WndProc()

    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 ?

  3. #3
    John E is offline Elite Member Power Poster
    Join Date
    Apr 2001
    Location
    Manchester, England
    Posts
    4,835

    Re: Strange code in WndProc()

    Quote Originally Posted by superbonzo View Post
    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.
    "A problem well stated is a problem half solved.” - Charles F. Kettering

  4. #4
    Join Date
    Oct 2008
    Posts
    1,456

    Re: Strange code in WndProc()

    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 ...

  5. #5
    John E is offline Elite Member Power Poster
    Join Date
    Apr 2001
    Location
    Manchester, England
    Posts
    4,835

    Re: Strange code in WndProc()

    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...
    "A problem well stated is a problem half solved.” - Charles F. Kettering

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  





Click Here to Expand Forum to Full Width

Featured