[WinAPI & DirectX]A common message loop for normal programs

Started by
5 comments, last by savail 11 years, 11 months ago
Hey,
I'm not sure if I put my stuff correctly in the message loop(Render()):
while(GetMessage(&msg, NULL, 0, 0) > 0)
{
TranslateMessage(&msg);
DispatchMessage(&msg);

if(!Graphics::Obj().Render())
{
MessageBox(NULL, "Failed to render", "Error", MB_OK | MB_ICONEXCLAMATION);
break;
}
}


becouse when I close the window I get an error from the MessageBox function above. Probably becouse when I'm handling messages before rendering the window is firstly destroyed and then DirectX doesn't have a window to draw on. When I put my Render() function above translating and dispatching messages I don't get the error, but mostly people advise to handle messages before doing anything else?This is how I'm handling messages to close window:

LRESULT CALLBACK WndProc( HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam )
{
switch( msg )
{
case WM_CLOSE:
DestroyWindow( hwnd );
break;

case WM_DESTROY:
PostQuitMessage( 0 );
break;
//...
default:
return DefWindowProc( hwnd, msg, wParam, lParam );
}
return 0;
}
Advertisement
You should do something like this for message loop:
bool running = true;

while (running)
{
while (PeekMessage(&msg, NULL, 0, PM_REMOVE))
{
if (msg.message == WM_QUIT)
{
running = false;
break;
}

TranslateMessage(&msg);
DispatchMessage(&msg);
}

if (running)
{
if (!Graphics::Obj().Render())
{
MessageBox(NULL, "Failed to render", "Error", MB_OK | MB_ICONEXCLAMATION);
break;
}
}
}


Processing only one message per frame is really bad.
but I need a message loop not for a game but for a normal windows program (like Ms Paint etc).
So for normal (for example Ms Paint, Word) programs, the message loop should use GetMessage() function in order to pick messages? And where should be done rendering in such message loop?
When handling WM_PAINT message maybe?

Best regards!
Most "normal" programs redraw the client area in their WM_PAINT handler, since this message is sent to notify the app that a portion of the client area needs to be redrawn for some reason (for instance, if a portion of the client area was obscured by another window but is now visible).

A good portion of apps won't even explicitly draw anything manually...they'll just use common controls (buttons, scrollbars, listview's, etc.) that can handle drawing themselves.
I see, thanks a lot

This topic is closed to new replies.

Advertisement