BUG: WindowEventUtilities::messagePump

Discussion area about developing or extending OGRE, adding plugins for it or building applications on it. No newbie questions please, use the Help forum for that.
Post Reply
User avatar
stealth977
Gnoll
Posts: 638
Joined: Mon Dec 15, 2008 6:14 pm
Location: Istanbul, Turkey
x 42

BUG: WindowEventUtilities::messagePump

Post by stealth977 »

Code: Select all

void WindowEventUtilities::messagePump()
{
#if OGRE_PLATFORM == OGRE_PLATFORM_WIN32
	// Windows Message Loop (NULL means check all HWNDs belonging to this context)
	MSG  msg;
	while( PeekMessage( &msg, NULL, 0U, 0U, PM_REMOVE ) )
	{
		TranslateMessage( &msg );
		DispatchMessage( &msg );
	}
.....
.....
Embedded code to show whats wrong:
1 - Definition of messagePump says that it processes messages of REGISTERED WINDOWS (here registered means the ones created by OGRE, not the external handles)
2 - LINUX and MAC specific code correctly checks ONLY REGISTERED WINDOWS (well am not a linux/mac expert, thats as far as i can understand)
3 - As you see above, windows specific code PEEKS ALL WINDOW MESSAGES, containing UNREGISTERED WINDOWS (externals)

So, if i have a custom window and an ogre window, calling messagepump to process OGRE Window's messages screws my custom windows message processing. To make it more clear, if you have an external window running in lets say Qt, and another preview window created by OGRE, the window created by ogre becomes unresponsive if you dont call WindowEventUtilities::messagePump(), but if you do, then your Qt window can no longer process its own messages.

It would be great if someone fixed the code to only process messages of registered windows.
Ismail TARIM
Ogitor - Ogre Scene Editor
WWW:http://www.ogitor.org
Repository: https://bitbucket.org/ogitor
urosidoki
Kobold
Posts: 34
Joined: Mon Sep 27, 2010 9:14 pm

Re: BUG: WindowEventUtilities::messagePump

Post by urosidoki »

I am really interested on this post, since I got the feeling I had the same problem when I am embedding ogre in Qt.

Any idea about how to make it work properly?

PD: I have to say that when I removed from my game engine _swapAllRenderTargetBuffers it starts to render something in the Qt app, the problem is that is really really slow.
Owen
Google Summer of Code Student
Google Summer of Code Student
Posts: 91
Joined: Mon May 01, 2006 11:36 am
x 21

Re: BUG: WindowEventUtilities::messagePump

Post by Owen »

The Way of Win32 is that all windows should process messages entirely inside their WndProc. Your code should be designed such that it doesn't explode when other people pump messages. In particular, if you don't follow this, then your code will explode at random when various parts of the Windows libraries (Mostly shell32, especially COM, also a few bits of user32) start pumping messages.

If you are using Qt, it also pumps messages indiscriminately of window. You shouldn't need to call WindowEventUtilities::messagePump() unless your Qt window and Ogre window are on separate threads (and in that case the event queues are separate anyway, also note that this will make your code unportable)

Note that the Mac code seems to do nothing in the case of Cocoa (That actually looks like a bug - it'll never pump messages). Note that the closest you can do on Cocoa is CFRunLoopRunInMode(kCFRunLoopDefaultMode, 0, TRUE), which will process messages for all windows.

This should probably be considered a documentation bug
User avatar
masterfalcon
OGRE Team Member
OGRE Team Member
Posts: 4270
Joined: Sun Feb 25, 2007 4:56 am
Location: Bloomington, MN
x 126
Contact:

Re: BUG: WindowEventUtilities::messagePump

Post by masterfalcon »

The Cocoa case is not a bug. We don't need to poll for or explicitly pump messages because they are delivered to us automatically by the OS.
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5296
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: BUG: WindowEventUtilities::messagePump

Post by dark_sylinc »

mmmmmmm....... theoretically if one passes the HWND of our registered windows, we would only process the windows Ogre owns.
That's not a simple task though (but not very hard either).
Post Reply