Sign in to follow this  

Program still running after PostMessageQuit(0) [SORTED]

This topic is 4304 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Ok so I've got this as my message handler:
LRESULT CALLBACK CWin::WndProc(HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam)
{
	switch (msg)
	{
	case WM_DESTROY:
		PostQuitMessage(0);
		return 0;
	}
	return DefWindowProc(hWnd, msg, wParam, lParam);
}

and this as my message pump:
void CWin::appLoop()
{
	MSG msg;
	while (GetMessage(&msg, m_hWnd, 0 , 0))
	{
		TranslateMessage(&msg);
		DispatchMessage(&msg);
	}
}

When I close the window I still have to manually stop the program from the debugger menu. If I step through after the window's closed I get an error stating: "There is no source code available for the current location.", and stepping through clearly shows it passing through PostMessageQuit(0) and falling out of the function block. Any ideas? Thanks. [Edited by - BigFreak on March 2, 2006 10:42:09 AM]

Share this post


Link to post
Share on other sites
Use PeekMessage instead of getmessage?
It might work,

PeekMessage(&msg, NULL, 0, 0, PM_REMOVE)




Obviously you need to adapt this for your own uses. I am assuming that
m_hWnd = hWnd.

Share this post


Link to post
Share on other sites
Quote:
Original post by Smit
I've always done PostQuitMessage() in WM_QUIT.

WM_DESTROY is the proper place to call a PostQuitMessage(), because PostQuitMessage() will generate a WM_QUIT message (thus, calling that function from within WM_QUIT is rather pointless...)
Quote:
Original post by Plasmarobo
Use PeekMessage instead of getmessage?

It doesn't matter which you use, PeekMessage or GetMessage, neither will affect the actual processing of a message, they just determine how the message is acquired.

BigFreak, two questions: 1) Do you know if your program is actually reaching that PostQuitMessage() in your WM_DESTROY section, for a fact? 2) Is you application using hooks?

Share this post


Link to post
Share on other sites
I used to have a similar problem using Visual Studio 2005... I switched to Visual Studio 2003 and it stopped doing that...

Maybe you could try that to make sure it's code problem and not a compiler problem?

Share this post


Link to post
Share on other sites
Try this:

Add a case for WM_CLOSE and call DestroyWindow inside it. DestroyWindow cleans up system resources and sends WM_DESTROY to the window so that PostQuitMessage(0) can be called. See Destroying a Window for details.

WM_QUIT should never make it to the WndProc. WM_QUIT directs GetMessage to return 0, typically resulting in an exit to the message loop. Also note the warning regarding GetMessage, namely that it returns non-zero, 0 and -1 (-1 when there is an error).

Many game loops use PeekMessage, but doing so can result in a loop that uses all of the CPU, so do some more investigation before proceeding with that kind of loop. See Examining a Message Queue for details.

Share this post


Link to post
Share on other sites
1) Upon closer inspection it gets to the switch statement, then it all goes wrong at the return... line. So closing the window made difference it had already fallen out of the block by this point.

2) Hooks? Heh, no idea...really new to this.

And yer, I'm using 2003, hehe.

Share this post


Link to post
Share on other sites
Quote:
Original post by Omega147
Quote:
Original post by Smit
I've always done PostQuitMessage() in WM_QUIT.

WM_DESTROY is the proper place to call a PostQuitMessage(), because PostQuitMessage() will generate a WM_QUIT message (thus, calling that function from within WM_QUIT is rather pointless...)


I must remember to read MSDN and not just truct code I find :/

Share this post


Link to post
Share on other sites
I'm not sure, but I think you need to pass NULL for the window handle on GetMessage. Otherwise I think it filters out the WM_QUIT, because I don't think it's associated with the apps window.

while (GetMessage(&msg, NULL, 0 , 0))

Share this post


Link to post
Share on other sites
My message handler now looks like this:
LRESULT CALLBACK CWin::WndProc(HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam)
{
switch (msg)
{
case WM_CLOSE:
DestroyWindow(hWnd);
break;
case WM_DESTROY:
PostQuitMessage(0);
}
return DefWindowProc(hWnd, msg, wParam, lParam);
}

But the same thing's happening. Erghs.

Share this post


Link to post
Share on other sites
Quote:
Original post by kiniport
I'm not sure, but I think you need to pass NULL for the window handle on GetMessage. Otherwise I think it filters out the WM_QUIT, because I don't think it's associated with the apps window.

I'm not sure if it filters out the WM_QUIT message, but passing a window handle will only collect messages for that window, whereas passing NULL will gather from the entire calling thread. Good eye on that one, kiniport.

Share this post


Link to post
Share on other sites
Quote:
Original post by Omega147
Quote:
Original post by kiniport
I'm not sure, but I think you need to pass NULL for the window handle on GetMessage. Otherwise I think it filters out the WM_QUIT, because I don't think it's associated with the apps window.

I'm not sure if it filters out the WM_QUIT message, but passing a window handle will only collect messages for that window, whereas passing NULL will gather from the entire calling thread. Good eye on that one, kiniport.


Bingo.

As LessBread noted, WM_QUIT is never passed to any window's message queue. So, if you pass a window handle to GetMessage, you won't get a WM_QUIT.

Share this post


Link to post
Share on other sites

void CWin::appLoop()
{
MSG msg;
while (GetMessage(&msg, m_hWnd, 0 , 0))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
}



LRESULT CALLBACK CWin::WndProc(HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam)
{
switch (msg)
{
case WM_CLOSE:
PostQuitMessage(0);
break;
case WM_DESTROY:
PostQuitMessage(0);
}
return DefWindowProc(hWnd, msg, wParam, lParam);
}


I'm figuring the problem could be elsewhere in the code. Any ideas?

Share this post


Link to post
Share on other sites
Your not returning 0 after you process the message. Also you only need to post a quit message in WM_DESTROY. Infact, take that WM_CLOSE message out. And like previously stated dont pass the window handle to GetMessage() -pass 0, or NULL.

Share this post


Link to post
Share on other sites

This topic is 4304 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this