• Advertisement
Sign in to follow this  

PeekMessage troubles

This topic is 3329 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 my understanding is that if a hwnd is specified in the second parameter the function will only handle messages for that window and its child windows? (and this is what i want) only problem is, each time i try to specifiy an hwnd my program ends up 'not responding'. while skipping through code in the debugger i discovered that the message struct is never being filled. So i went through some articles on the net that use the hwnd as a parameter for the peekmessage function (as opposed to NULL) and as far as i can see im not doing anything wrong.. but i must be. Heres my code for the HandleMessages method:
bool cWinBase::HandleMessages(bool bMain)
	{
		if (::PeekMessage(&m_Msg, m_hWnd, 0, 0, PM_REMOVE|PM_QS_POSTMESSAGE|PM_QS_SENDMESSAGE))
		{
			::TranslateMessage(&m_Msg);
			::DispatchMessage(&m_Msg);
		}
		if (bMain && m_Msg.message == WM_QUIT) return false;
		else return true;
	}
and heres the source for my main loop:
while (!GetAsyncKeyState(VK_ESCAPE))
	{
		if (!Wnd.HandleMessages(true))
			break;
	}
Its rough code for now, will clean it up after i figure this problem out. Thanks to all thoe who reply ~Reegan

Share this post


Link to post
Share on other sites
Advertisement
You won't receive any WM_QUIT if you specify a window-handle, could that be it?
At least if posted with PostQuitMessage, it won't post to any window in particular, but only to the current thread.

Share this post


Link to post
Share on other sites
The PM_QS_POSTMESSAGE|PM_QS_SENDMESSAGE flags seem to be causing the problem, if I add them to my PeekMessage() call, the window stops responding. Usually you'd just have the PM_REMOVE flag specified.

Share this post


Link to post
Share on other sites
I see well no i dont think that is it, i handle the postquitmessage in the window proc (very basic for now), if that was it, i would be complaining that my application doesnt fully close down, and only the window does.

right ok, now that works thanks loads evil steve but now the problem erik rufelt was talking about has occurd but i think i know how to fix this

Share this post


Link to post
Share on other sites
Quote:
Original post by Reegan
I see well no i dont think that is it, i handle the postquitmessage in the window proc (very basic for now), if that was it, i would be complaining that my application doesnt fully close down, and only the window does.

right ok, now that works thanks loads evil steve but now the problem erik rufelt was talking about has occurd but i think i know how to fix this
There's some messages (WM_QUIT is one) that are relevant to your thread rather than a particular window.

What I'd do is have one main message loop, whish passes NULL for the window handle to PeekMessage(). If you're managing multiple windows, I'd just make a static function of cWinBase to process all pending window messages (I.e. run PeekMessage() in a loop till it returns false). If you only process one message per tick, and one is generated every tick (By a call to InvalidateRect() for instance - which is a very common thing to do), you'll flood your message queue and start causing a large amount of lag and eventually loose data (My version of Windows has a message queue of a maximum of 10000 messages).

Then, your main loop would just have to call cWinBase::ProcessMessages() at some point. I believe this is what MFC did (Have one message pump instead of several at least).

Share this post


Link to post
Share on other sites
Ok, i suppose i will, thanks again evil steve for being as helpful as ever! ^^

Share this post


Link to post
Share on other sites
I should also point out that if you're using multiple threads, this could start to get a bit painful, since if you call PeekMessage() from a thread that didn't create a window, you won't process any messages for any windows in other threads. I'm not sure what MFC did here, I wouldn't be surprised if it forced every thread to pump messages.

Share this post


Link to post
Share on other sites
You need to have at least one message loop that passes NULL for HWND. There are a number of messages that get sent to the thread rather than the window, and those messages will only be picked up if you pass NULL for HWND.

In reality, you really shouldn't ever pass non-NULL for HWND since there's only one or two specific scenarios where it makes sense.

I suggest you restructure your message loop so that it's not part of the cWinBase class, but is something separate.

Edit: wow, I was really slow replying here! [smile]

Share this post


Link to post
Share on other sites
Quote:
Original post by Evil Steve
I'm not sure what MFC did here, I wouldn't be surprised if it forced every thread to pump messages.


With MFC you had two kinds of threads: worker threads and UI threads. Worker threads had no message pump, UI threads did.

/history lesson

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement