User Interface Programming - Game Coding Complete - page 298

'

The tough thing about implementing a new kind of control in your game isn t how

to draw a little “ x ” in the check box. If you want to learn how to do that, you can
trace through the source code in the CDXUTCheckBox and find out how it works.
Rather, the tough thing is knowing what features your controls will need beyond
these simple implementations. You also need to be aware of the important

“ gotchas ”

you ' ll need to avoid. Let ' s start with the easy stuff first.

n Identification: How is the control distinguished from others on the same screen?
n Hit Testing/Focus Order: Which control gets messages, especially if they over-
lap graphically?
n State: What states should controls support?

I suggest you approach the first problem from a device-centric point of view. Each
device is going to send input to a game, some of which will be mapped to the same
game functions. In other words, you might be able to select a button with the mouse
to perform some game action, like firing a missile. You might also use a hot key to
do the same thing.

Control Identification
Every control needs an identifier — something the game uses to distinguish it from the
other controls on the screen. The easiest way to do this is define an enum , and when
the controls are created, they retain the unique identifier they were assigned in their
construction:

enum MAINSCREEN_CONTROL_IDS
{

CID_EXIT,
CID_EXIT_DESKTOP,
CID_PREVIOUS_SCREEN,
CID_MAIN_MENU,
CID_OPTIONS
};

void CALLBACK CGameScreen::OnGUIEvent( UINT nEvent, int nControlID, MyControl*
pControl )
{

switch(pControl->GetID())
{

case CID_EXIT:
// exit this screen
break;