Game Development Reference
In-Depth Information
if (m_HasModalDialog & 0x10000000)
{
assert(0 &&
“
Too Many nested dialogs!
”
);
return defaultAnswer;
}
m_HasModalDialog <<= 1;
m_HasModalDialog |= 1;
pView->VPushElement(pModalScreen);
LPARAM lParam = 0;
int result = PumpUntilMessage(G_MSGENDMODAL, NULL, &lParam);
if (lParam != 0)
{
if (lParam==G_QUITNOPROMPT)
result = defaultAnswer;
else
result = (int)lParam;
}
pView->VRemoveElement(pModalScreen);
m_HasModalDialog >>= 1;
return result;
}
The first thing that
GameCodeApp::Modal()
method does is find an appropriate
game view to handle the message. You can imagine a case where you have nothing
but AI processes attached to the game, and they couldn
t care less about a dialog box
asking them if they want to quit. Only a human view can see the dialog and react to
it, so you iterate through the list of game views and find a view that belongs to the
human view type. If you don
'
'
t find one, you return a default answer.
If the entire game is running in a window and that window is minimized, the player will
never see the dialog box. The player needs a clue that the game needs interaction with the
player, and a good way to do this under Windows is to flash the window until the player
maximizes the window again, which is what
FlashWhileMinimized()
accomplishes.
The next thing you see is a dirty trick, and I love it. You can imagine a situation
where you have a modal dialog on the screen, such as something to manage a player
inventory, and the player presses Alt-F4 and wants to close the game. This requires
an ability to nest modal dialog boxes, which in turn means you need some way to
detect this nesting and if it has gone too deep. This is required because the modal
dialogs are managed by the game application. I use a simple bit field to do this, shift-
ing the bits each time you nest deeper.
