When we have a menu selection that we use a lot, it's nice to put a button on the toolbar so that you can do this action with one click. Although we can, in principle, have a toolbar button that does not correspond to an existing menu selection, it's considered good practice to always do it both ways. For this reason, even if you really just want a toolbar button for something, you ordinarily implement it first as a menu selection and then add toolbar button functionality for the menu selection.
You will notice that many of the Pop menu controls have toolbar buttons corresponding to them. According to which style of game is active, some of the buttons may be grayed out, or inactive.
Generally you want to put your most commonly used controls onto the toolbar to make the interface easier for the user. Any menu selection that you use more than two or three times during a typical play session should probably be a toolbar button. On the other hand, you don't want too crowded a toolbar as it then becomes confusing. The author makes no claim that the toolbar design for Pop is particularly good, the particular set of buttons on it got there by a slow process of accumulation, and should really be rethought. When you design your own computer game with Pop Framework, take a hard look at the toolbar, and make sure that you only have buttons that the users will need; you will want to remove some of the existing buttons and add others.
Let's look at the steps involved in adding a toolbar button for the Game | Play Sound. We open the Resource View window, click on TOOLBAR and double-click on IDR_MAINFRAME. The simplest practice is to use the same toolbar throughout your program; adding a new one yourself is quite a hassle. Rather than adding a new toolbar, we simply add buttons to the existing one.
The Resource Editor will show an image of your toolbar at the top, with an enlarged view of one of the buttons below. You can drag the buttons around on the toolbar as you like. To add a new button, highlight the blank button on the toolbar image. You can use the Resource Editor's graphics tools like a little paint program to draw something onto the button. If you don't see the graphics controls right-click on the Visual Studio menu bar and make sure that the Image Editor toolbar is checked. [In Version 6.0, make sure that the Graphics and Colors toolbars are checked.]
Once you've decorated the button to your liking, you need to connect the control to your program. To do this you need to open the toolbar button Properties dialog, which will look very similar to the menu item Properties dialog from before. Opening the toolbar button Properties dialog is a little harder though, because your mouse is busy acting like a graphics editor. You can't get to the toolbar botton Properties with a double-click or a right-click. The easiest way to open the Properties dialog for a highlighted button is to press Alt+Enter.
Once you've got your toolbar button Properties open, use the arrow on the ID field to scroll to the name of the ID of the menu item you want to imitate, in this case ID_GAME_PLAYSOUNDS. And make sure that the Prompt field ends with something like \nSounds to specify a 'tool tip' for Windows to show when your mouse pauses over the button.
At this point you're done! The OnGamePlaySounds and the OnUpdateGamePlaySounds message handlers we wrote earlier are already in place, and are already linked to all menu items and/or toolbar buttons that happen to have the ID_GAME_PLAYSOUNDS. And the SetCheck function will show the button as either in state 0 (looking normal) or in state 1 (pressed down).
If the message handler for a button lives inside the CView or the CDoc class, Windows knows to SetCheck that toolbar button to the 'indeterminate' state 2 when all the documents are closed. The nice thing about all this is that we the programmers don't need to worry about when to call the control update methods. Windows calls these all by itself; in fact each time your program has nothing else to do (no messages to process), Windows will call your program's control update methods.
By the way if you really did want to have a toolbar button that doesn't correspond to any menu selection, this would be perfectly fine. The only difference is that instead of scrolling through the existing ID_ values, you'd make up a new ID_ name for your toolbar button. And then you'd have to use Class Wizard to add handlers for the corresponding COMMAND and UPDATE_COMMAND_UI messages.