Programming Microsoft Windows Ce Net 3Rd [Electronic resources] نسخه متنی

Resources

Resources are read-only data segments of an application or a DLL that are linked to the module after it has been compiled. The point of a resource is to give a developer a compiler-independent place for storing content data such as dialog boxes, strings, bitmaps, icons, and yes, menus. Since resources aren't compiled in a program, they can be changed without your having to recompile the application.

You create a resource by building an ASCII file—called a resource script—describing the resources. Your ASCII file has the extension RC. You compile this file with a resource compiler, which is provided by every maker of Windows development tools, and then you link it into the compiled executable again using the linker. These days, these steps are masked by a heavy layer of visual tools, but the fundamentals remain the same. For example, eMbedded Visual C++ creates and maintains an ASCII resource (RC) file even though few programmers directly look at the resource file text any more.

It's always a struggle for the author of a programming book to decide how to approach tools. Some lay out a very high level of instruction, talking about menu selections and describing dialog boxes for specific programming tools. Others show the reader how to build all the components of a program from the ground up, using ASCII files and command line compilers. Resources can be approached the same way: I could describe how to use the visual tools or how to create the ASCII files that are the basis for the resources. In this book, I stay primarily at the ASCII resource script level since the goal is to teach Windows CE programming, not how to use a particular set of tools. I'll show how to create and use the ASCII RC file for adding menus and the like, but later in the book in places where the resource file isn't relevant, I won't always include the RC file in the listings. The files are, of course, on the CD included with this book.

Resource Scripts

Creating a resource script is as easy as using Notepad to create a text file. The language used is simple, with C-like tendencies. Comment lines are prefixed by a double slash (//), and files can be included using a #include statement.

An example menu template would be the following:

// 
// A menu template
//
ID_MENU MENU DISCARDABLE
BEGIN
POPUP "&File"
BEGIN
MENUITEM "&Open...",                    100
MENUITEM "&Save...",                    101
MENUITEM SEPARATOR
MENUITEM "E&xit",                       120
END
POPUP "&Help"
BEGIN
MENUITEM "&About",                      200
END
END

The initial ID_MENU is the ID value for the resource. Alternatively, this ID value can be replaced by a string identifying the resource. The ID value method provides more compact code, while using a string may provide more readable code when the application loads the resource in the source file. The next word, MENU, identifies the type of resource. The menu starts with POPUP, indicating that the menu item File is actually a pop-up (cascade) menu attached to the main menu. Because it's a menu within a menu, it too has BEGIN and END keywords surrounding the description of the File menu. The ampersand (&) character tells Windows that the next character should be the key assignment for that menu item. The character following the ampersand is automatically underlined by Windows when the menu item is displayed, and if the user presses the Alt key along with the character, that menu item is selected. Each item in a menu is then specified by the MENUITEM keyword followed by the string used on the menu. The ellipsis following the Open and Save strings is a Windows UI custom indicating to the user that selecting that item displays a dialog box. The numbers following the Open, Save, Exit, and About menu items are the menu identifiers. These values identify the menu items in the WM_COMMAND message. It's good programming practice to replace these values with equates that are defined in a common include file so that they match the WM_COMMAND handler code.

Table 4-2 lists other resource types that you might find in a resource file. The DISCARDABLE keyword is optional and tells Windows that the resource can be discarded from memory if it's not in use. The remainder of the menu is couched in BEGIN and END keywords, although the bracket characters { and } are recognized as well.

Icons

Now that we're working with resource files, it's a trivial matter to modify the icon that the Windows CE shell uses to display a program. Simply create an icon with your favorite icon editor, and add to the resource file an icon statement such as

ID_ICON ICON "iconname.ico"

When Windows displays a program in Windows Explorer, it looks inside the EXE file for the first icon in the resource list and uses it to represent the program.

Having that icon represent an application's window is somewhat more of a chore. Windows CE uses a small 16-by-16-pixel icon on the taskbar to represent windows on the desktop. Under the desktop versions of Windows, the RegisterClassEx function can be used to associate a small icon with a window, but Windows CE doesn't support this function. Instead, the icon must be explicitly loaded and assigned to the window. The following code fragment assigns a small icon to a window.

    hIcon = (HICON) SendMessage (hWnd, WM_GETICON, FALSE, 0);
if (hIcon == 0) {
hIcon = LoadImage (hInst, MAKEINTRESOURCE (ID_ICON1), IMAGE_ICON,
16, 16, 0);
SendMessage (hWnd, WM_SETICON, FALSE, (LPARAM)hIcon);
}

The first SendMessage call gets the currently assigned icon for the window. The FALSE value in wParam indicates that we're querying the small icon for the window. If this returns 0, indicating that no icon has been assigned, a call to LoadImage is made to load the icon from the application resources. The LoadImage function can take either a text string or an ID value to identify the resource being loaded. In this case, the MAKEINTRESOURCE macro is used to label an ID value to the function. The icon being loaded must be a 16-by-16 icon because under Windows CE, LoadImage won't resize the icon to fit the requested size. Also under Windows CE, LoadImage is limited to loading icons and bitmaps from resources. Windows CE provides the function SHLoadDIBitmap to load a bitmap from a file.

Unlike other versions of Windows, Windows CE stores window icons on a per-class basis. So if two windows in an application have the same class, they share the same window icon. A subtle caveat here—window classes are specific to a particular instance of an application. If you have two different instances of the application FOOBAR, they each have different window classes, so they may have different window icons, even though they were registered with the same class information. If the second instance of FOOBAR had two windows of the same class open, those two windows would share the same icon, independent of the window icon in the first instance of FOOBAR.

Accelerators

Another resource that can be loaded is a keyboard accelerator table. This table is used by Windows to enable developers to designate shortcut keys for specific menus or controls in your application. Specifically, accelerators provide a direct method for a key combination to result in a WM_COMMAND message being sent to a window. These accelerators are different from the Alt-F key combination that, for example, can be used to access a File menu. File menu key combinations are handled automatically as long as the File menu item string was defined with the && character, as in &File. The keyboard accelerators are independent of menus or any other controls, although their assignments typically mimic menu operations, as in using Ctrl-O to open a file.

Below is a short resource script that defines a couple of accelerator keys.

ID_ACCEL ACCELERATORS DISCARDABLE
BEGIN
"N", IDM_NEWGAME, VIRTKEY, CONTROL
"Z", IDM_UNDO,  VIRTKEY, CONTROL
END

As with the menu resource, the structure starts with an ID value. The ID value is followed by the type of resource and, again optionally, the discardable keyword. The entries in the table consist of the letter identifying the key, followed by the ID value of the command, VIRTKEY, which indicates that the letter is actually a virtual key value, followed finally by the CONTROL keyword, indicating that Control must be pressed with the key.

Simply having the accelerator table in the resource doesn't accomplish much. The application must load the accelerator table and, for each message it pulls from the message queue, see whether an accelerator has been entered. Fortunately, this is accomplished with a few simple modifications to the main mes sage loop of a program. Here's a modified main message loop that handles keyboard accelerators:

// Load accelerator table.
hAccel = LoadAccelerators (hInst, MAKEINTRESOURCE (ID_ACCEL));
// Application message loop
while (GetMessage (&msg, NULL, 0, 0)) {
// Translate accelerators
if (!TranslateAccelerator (hwndMain, hAccel, &msg)) {
TranslateMessage (&msg);
DispatchMessage (&msg);
}
}

The first difference in this main message loop is the loading of the accelerator table using the LoadAccelerators function. Then, after each message is pulled from the message queue, a call is made to TranslateAccelerator. If this function translates the message, it returns TRUE, which skips the standard TranslateMessage and DispatchMessage loop body. If no translation was performed, the loop body executes normally.

Bitmaps

Bitmaps can also be stored as resources. Windows CE works with bitmap resources somewhat differently from other versions of Windows. With Windows CE, the call

HBITMAP LoadBitmap(HINSTANCE hInstance, LPCTSTR lpBitmapName);

loads a read-only version of the bitmap. This means that after the bitmap is selected into a device context, the image can't be modified by other drawing actions in that DC. To load a read/write version of a bitmap resource, use the LoadImage function.

Strings

String resources are a good method for reducing the memory footprint of an application while keeping language-specific information out of the code to be compiled. An application can call

int LoadString(HINSTANCE hInstance, UINT uID, LPTSTR lpBuffer,
int nBufferMax);

to load a string from a resource. The ID of the string resource is uID, the lpBuffer parameterChapter 7, one quick note here. It's not a good idea to load a number of strings from a resource into memory. This just uses memory both in the resource and in RAM. If you need a number of strings at the same time, it might be a better strategy to use the new feature of LoadString to return a pointer directly to the resource itself. As an alternative, you can have the strings in a read-only segment compiled with the program. You lose the advantage of a separate string table, but you reduce your memory footprint.