🔒 Locked

PeekMessage()

Started by nLEyETn Feb 18, 2005 at 12:40 AM 5 replies 1.9k views

Original Post

Feb 18, 2005 at 12:40 AM

I was just workin on some Win32 programming and was setting up the window when I used the function PeekMessage with the parameters: PeekMessage(&Msg, hWnd, 0, 0, PM_REMOVE); From what I've seen this should work ok for my one window application. But I started having problems with the program quitting correctly. When I would click on the close button (the default upper right one) the window would not do anything. I then looked at it with Spy++ and saw that once i clicked the button, WM_CLOSE was passed. My WM_CASE switch was set at: case WM_CLOSE: PostQuitMessage(0); break; But this didn't seem to execute. I tried changing the line of PeekMessage to: PeekMessage(&Msg, NULL, 0, 0, PM_REMOVE); And this seemed to fix it. Now it works correctly. I can go ahead and use this method since it will work better once I start adding child windows anyway, but I want to know why changing the HWND parameter to NULL should matter if my window only had the one HWND instance anyway. So know matter what I did in that window, it should have been handled in my WindowProc function. Does anybody know why that it didn't work?

Drew_Benton

Feb 18, 2005 at 1:12 AM

I cannot give you a direct answer to this, but if you take a look at this MSDN reference I think it explains what you are talking about. Use the "Posting a Message" section as reference. I hope that can give you some ideas.

Just from looking at it, they used this:

    case WM_DESTROY:      // Perform cleanup tasks.      PostQuitMessage(0);     break;

So I think you are handling it via the wrong message.

- Drew

nLEyETn

Feb 18, 2005 at 2:10 AM

Thanks for the response, I've tried the Message Handler different ways, but I did notice something after you said that... I tried:

	case WM_CLOSE:		DestroyWindow(hWnd);		break;	case WM_DESTROY:		PostQuitMessage(0);		break;

Which seems to be a good common practice to handle Win32 cleanup. The result was different. This time the window closed which would result from DestroyWindow() being called, so WM_CLOSE did get processed correctly as it should have been. But the process was still running after the window was killed, so it seems that PostQuitMessage() would actually be the problem. The question still remains though, why would PeekMessage() with hWnd passed, not handle PostQuitMessage(0) correctly as it does when NULL is passed instead.

Endurion

Feb 18, 2005 at 2:23 AM

Because PeekMessage with a HWND handle will only check messages specifically for that HWND. The WM_QUIT message gets sent to your thread, not to any explicit HWND. So PeekMessage will only see the WM_QUIT message, if it checks for no explicit HWND.

You got the solution already, just insert NULL for the HWND. I never found a reason to actually put a real HWND handle there all the years of programming.

nLEyETn

Feb 19, 2005 at 12:18 AM

Thanks for the reply, I understand now why it wouldn't catch it if the WM_QUIT never gets sent to the HWND. That makes more sense now.

Dean Harding

Feb 19, 2005 at 12:23 AM

In general, you need to make sure that you always call an unfiltered PeekMessage or GetMessage (at least eventually - you can call it with a filter as long you eventually call the unfiltered version), because it's not just you creating windows. Other services will often create hidden windows for you (examples include COM or the Method Input Editor, etc) and they need to get their messages posted to them to work as well.

Kippesoep

Feb 19, 2005 at 1:03 AM

For some really good information by a person in the know (Raymond Chen works on the Windows Shell Team), check his blog.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.