Program still running after PostMessageQuit(0) [SORTED]

Started by
16 comments, last by BigFreak 18 years, 1 month ago
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]
Advertisement
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.
___________________________________________________Optimists see the glass as Half FullPessimists See the glass as Half EmptyEngineers See the glass as Twice as big as it needs to be
I've always done PostQuitMessage() in WM_QUIT.

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?
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?
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.
"I thought what I'd do was, I'd pretend I was one of those deaf-mutes." - the Laughing Man
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.
No need for hooks here. Just check out the links I dropped above.

Also check out this article: Creating a Win32 Window Wrapper Class. It might save you some troubles later on, however, since messages are getting through to the WndProc, that might not be the case.
"I thought what I'd do was, I'd pretend I was one of those deaf-mutes." - the Laughing Man
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 :/

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

This topic is closed to new replies.

Advertisement