Game Development Reference
In-Depth Information
}
}
}
if (pLParam)
*pLParam = msg.lParam;
if (pWParam)
*pWParam = msg.wParam;
return 0;
}
The
PumpUntilMessage
function works similarly to the message pump in your
main loop, but it is a special one meant for modal dialog boxes. One message,
WM_CLOSE
, gets special treatment since it must terminate the dialog and begin the
game close process. Other than close, the loop continues until the target message is
seen in the message queue. I define this custom message myself:
#define G_MSGENDMODAL ( WM_USER + 100 )
If there are no messages in the queue, the pump calls the right code to make the
game views update and render. Without this, you wouldn
'
t be able to see anything,
especially if you drag another window over your game.
As soon as the modal dialog wants to kill itself off, it will send the
G_MSGENDMODAL
into the message queue, and the
PumpUntilMessage
method will exit back out to
the
Modal
method you saw earlier.
G_MSGENDMODAL
is a special user-defined mes-
sage, and Win32 gives you a special message range starting at
WM_USER
. I usually
like to start defining application-specific Windows messages at
WM_USER+100
instead of starting right at
WM_USER
,sinceI
'
ll be able to tell them apart in the
message queue.
The trick to this is getting the answer back to the calling code, which is done with the
parameters to the
G_MSGENDMODAL
. In this case, we look at the ID of the control that
was clicked on. Recall
CMessageBox::OnGUIEvent():
void CALLBACK CMessageBox::OnGUIEvent(
UINT nEvent, int nControlID, CDXUTControl* pControl, void *pUserContext )
{
PostMessage(g_pApp->GetHwnd(), G_MSGENDMODAL, 0, nControlID);
}
This posts
G_MSGENDMODAL
to the message queue, which is what the
PumpUntil-
Message
method was looking for all along. This breaks the tight loop, and the
GameCodeApp::Modal()
method can extract the answer the player gave to the
modal dialog box.
