Jump to content
  • Advertisement
Sign in to follow this  
BigFreak

Program still running after PostMessageQuit(0) [SORTED]

This topic is 4555 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
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.

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
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!