barcode generator in c# code project ADDING A PROFESSIONAL LOOK AND FEEL in Font

Paint Data Matrix 2d barcode in Font ADDING A PROFESSIONAL LOOK AND FEEL

// or advances to the next board if a board // is done: try { if(myGameOver) { reset(); flushKeys(); myDungeon.resumeGame(); } else { setMenuMode(); } } catch(Exception e) { myDungeon.errorMsg(e); } } } /** * Respond to softkeys in the case where * lcdui commands are used instead of custom * graphical softkeys. */ public void commandAction(Command c, Displayable s) { try { if(c == myMenuCommand) { setMenuMode(); } else if(c == myOkCommand) { removeCommand(myOkCommand); addCommand(myMenuCommand); reset(); flushKeys(); myDungeon.resumeGame(); } else if(c == myExitCommand) { myDungeon.quit(); } } catch(Exception e) { myDungeon.errorMsg(e); } } } You can see that another advantage of this version over the version in 5 is that the timer is also drawn with a set of five sprites (all using the same image) instead of being drawn with one of the platform s built-in fonts onto an ugly black bar drawn across the bottom of the screen. Figure 10-7 shows the difference.

Figure 10-7. The difference in how the timer number appears in the two versions The trickiest part of the menu code in Listing 10-8 is the implementation of the softkeys, explained in the next section.

Nearly every MIDP device uses a system of softkeys to drive its built-in GUI. A softkey is a physical button on the device whose function changes depending on the context. The button corresponding to the softkey is generally placed right next to the screen so that the program can display the current label for it such as Exit, Options, or OK. A typical platform has two softkeys a right softkey and a left softkey at the base of the screen. When writing your own custom GUI, naturally you want to be able to implement the softkey functionality so that you can be sure that the softkey labels match the look of the rest of the graphical components. Unfortunately, the designers of MIDP decided that they didn t want to make it easy for you to do this. The philosophy seems to be that the softkeys are a platformspecific implementation detail that you don t need to know about, and if you start fiddling with them, you can mess up the platform s consistent user experience by perhaps putting your Exit key on the left when the platform normally puts it on the right, or you might assume the softkeys are at the bottom of the screen when for a particular platform they re at the top. So MIDP encapsulates softkeys (and possibly other related input features) in Command objects and says in essence We ll handle them you don t touch them.

However, since so many devices use this same consistent design of placing the softkeys at the bottom left and bottom right of the screen, it s natural to want to try to implement them yourself to create a consistent, attractive look for your game. It would have been nice if the designers of MIDP had at least thrown in some minimal support such as a system property you can query to determine whether the platform uses standard (bottom left and bottom right) softkeys, and then provide the corresponding key constants in the GameCanvas class. As it is, it s possible to receive and interpret the softkey events, but you have to do some additional work, and the resulting code isn t terribly portable. Essentially you have to customize the JAR file for every target device (or at least every manufacturer) that you d like to use custom softkeys on. Here s how to do it. If you look at Listing 10-8, you ll see that in addition to querying for key states (as in the corresponding class in 5), the keyPressed() method is also implemented. This is because the return value of the getKeyStates() method only returns information about the standard Java key constants. However, the AMS calls the keyPressed() method with the platform s raw keycode integer corresponding to the key that was pressed. Since these keycodes vary from one device to the next, you usually follow with the getGameAction class to translate the platform-specific keycode into a recognizable Java constant (as explained in the section Using the Graphics and Canvas Classes from 2). But if you happen to know the current device s codes for the left and right softkeys, this is where you use that information. Figuring out what keycodes your game should be using at any given moment is a two-step process: (1) identify the platform, and (2) load and use the correct keycode values for the current platform. Identifying the platform is a challenge all its own, discussed in the Identifying the Platform sidebar earlier. Then figuring out the keycodes for all of your target devices is a separate challenge. Some manufacturers (Sony Ericsson, for example) publish developer guides that contain the keycodes. Additionally, there are online databases listing the keycodes for many popular devices, such as the device database on the J2ME Polish web site (see the Using J2ME Polish sidebar). Many devices follow the WTK s example for their keycode mapping: -6 for the left softkey and -7 for the right softkey. (These are the values used by Sony Ericsson, for example.) But many don t. My Sagem my700x, for example, uses exactly the reverse. Once you know the keycodes for the current device, implementing the softkeys is a snap. As you can see in Listing 10-8, you set your canvas to full-screen mode, then paint on the softkey labels in the lower right and left corners of the screen, and handle the softkey actions in the keyPressed() method. However, it s good to provide a fallback for the case where the game is running on a device that you can t identify and/or don t have the keycodes for. In this case, we can still use the custom menu code, but the menu screen is put up and down using standard lcdui Command objects, implemented in the commandAction() method of Listing 10-8. It s not quite as pretty, but it s not the end of the world. Figure 10-8 shows what that looks like.