9 replies to this topic

[SteveDeFacto]

So I decided to try my hand at multi threading today. I thought making a thread to handle window messages would be a simple place to start. However, the window is unresponsive when I try this. Here is the function I am using for my thread:

void DoEvents(void *params)
{
Window* window = (Window*)params;
MSG msg = {0};
while( 1 )
{
if( PeekMessage( &msg, NULL, 0, 0, PM_REMOVE ) )
{
TranslateMessage( &msg );
DispatchMessage( &msg );
}
}
}

So why would this not work?

[alphadog]

How and when do you plan on exiting the loop?

Usually, there's a:

if (Msg.message == WM_QUIT)
	break;

in the PeekMessage() block.

[SteveDeFacto]

alphadog, on 18 May 2012 - 01:18 PM, said:

How and when do you plan on exiting the loop?

Usually, there's a:

if (Msg.message == WM_QUIT)
	break;

in the PeekMessage() block.

I planed on using my IDE to break the loop. Any idea why the window is not processing messages?

[}:+()___ (Smile)]

As far as I remember, you must process messages in the thread where you created target window.

[TheNut]

Indeed you shouldn't separate the message loop from the thread that created your window. All windowing systems I know of adhere to that requirement, including OpenGL contexts. I've never had the need to offload the message loop to a separate thread. I keep the message loop in the main application thread and create additional threads as needed when I want to execute logic separate from the main (aka UI) thread.

[alphadog]

I realize I did not answer the root question and others did. As has been said by Smile and TheNut, Windows sends messages to the thread that created the window. For additional info, I refer you to this and this. Of course, there are ways to beat the system into submission, but it is usually so much overhead that it isn't worth it.

[SteveDeFacto]

I want to have my library process messages and not have to have the user call a command to do it every frame. What would be the best way to do that? AttachThreadInput? Or is there a way I can do it with the main thread?

[TheNut]

Make your library static, add your WinMain function and your win32 message callback function in your library, as well as your message pump. When you link your library into your main project and run it, the compiler will link your win32 entry point and execute the window logic as you defined. The main app doesn't need to concern itself with any window logic. Just add some events and other helpful methods in your library so you can override or extend the message loop. For example, in your message pump after you peeked at all messages, dispatch a "render" event. The main app can listen for this and draw a frame or do whatever.

[SteveDeFacto]

TheNut, on 19 May 2012 - 03:55 AM, said:

Make your library static, add your WinMain function and your win32 message callback function in your library, as well as your message pump. When you link your library into your main project and run it, the compiler will link your win32 entry point and execute the window logic as you defined. The main app doesn't need to concern itself with any window logic. Just add some events and other helpful methods in your library so you can override or extend the message loop. For example, in your message pump after you peeked at all messages, dispatch a "render" event. The main app can listen for this and draw a frame or do whatever.

I kinda wanted to be able to compile the library as a DLL.

[TheNut]

That's fine. You'll just have to include the WinMain function in your main app instead of your library because you can't have the main entry point in a DLL. The static library would allow you to fully encapsulate the Win32 system so your main projects can use a standard startup routine rather then deal with window creation and setting up the message pump. This would be beneficial if you wanted to write portable code that uses different window systems. You can still have your library process the win32 messages, just have your main app call the necessary class or function to startup the loop.