Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
From an application developers’ point of view, the Registry is the place where application-specific state information is stored between executions. Predictably, the Windows CE Registry is a leaner version of its desktop cousin. This means that you may want to re-evaluate the kind and amount of data your application stores in the Registry.
The most convenient way to become familiar with the structure of the CE Registry is with the Windows CE Remote Registry Editor. To use the Remote Registry Editor to examine the Registry of a specific device, you must add your device to the editor’s list. Select the Registry menu’s Add Device command, and choose a device from the list displayed in the “Select A Device” dialog.
The Remote Registry Viewer behaves in a fashion similar to its desktop counterpart, RegEdit. Let’s use it to take a look a closer look at the structure and content of the CE Registry.
Figure 1: Add Your Device to the Remote Registry Viewer
Notice that when the Registry listing for the handheld PC is expanded, there are only three root keys: HKEY_CLASSES_ROOT, HKEY_CURRENT_USER, and HKEY_LOCAL_MACHINE. All the examples in this article will deal with adding, querying, and modifying keys and values under HKEY_LOCAL_MACHINE. This is the conventional location in which to store applications’ state information.
Figure 2: The Root Keys In the Windows CE Registry
Windows CE Registry Access Functions
There are two basic groups of functions for accessing Registry data on a CE device: The ones that access data in place, and the ones that access the Registry of the device from the desktop. We’ll be looking into the desktop Registry access functions in the upcoming examples, because the true power of CE is unleashed by seamlessly integrating Windows devices of different classes. For now, be aware that the remote access functions’ names are the same as the “in place” functions, except that they are prefixed with the letters “Ce”. For example, the CE side function for accessing a Registry key looks like this:
//CE side registry function call
RegQueryValueEx(hKey, lpValueName, lpReserved, lpType,
lpData, lpcbData );
To perform the same operation on a connected device from an application executing on the desktop, you would use this function instead of the one shown above:
//Desktop side remote registry function call
CeRegQueryValueEx(hKey, lpValueName, lpReserved, lpType,
lpData, lpcbData );
And now, on to the business of designing and using the Registry, CE style.
Accessing the Registry on a CE Device
Some people avoid using the Registry at all, being intimidated by the implications of a misstep. Certainly, corrupting the Registry could create serious problems. However, when all is said and done, the CE Registry is simply a database. Like any database, we need to treat the Registry in a way that ensures its consistency, keeps it as compact as possible, and accesses it in the most efficient fashion. I make this point because on the desktop, the Registry has become more like a five-family garage sale with every passing year. On CE, its important to be organized and thrifty when deciding what data an application registers. Use the Registry sparingly and efficiently. If your Win32 application stores information in the Registry that isn’t specifically necessary to re-create the previous application’s startup state, consider eliminating these items or devising another way to get the same information with runtime queries.
Most especially, you’ll want to consider redesigning deeply nested or widely branched Registry data structures. Under CE, significant size and performance penalties occur when accessing deeply nested keys. For this reason, try to make Registry trees as flat as possible. Also, because Registry access in general is a fairly expensive operation, another way of optimizing Registry data storage is to aggregate individual named key values into a single element. By using this strategy, your application makes one call to retrieve Registry information and parses data items from the aggregate. This approach has the dual advantages of reducing both the number of key accesses and the storage space used by the values.
Porting Tip: Redesigning the structure of your Registry tree may give your application a big performance boost.
- There is a storage and performance advantage to making Registry trees as “flat” as possible.
- Combine multiple named values into a single named value element that is parsed by the application, so you can retrieve startup information in a single key access.
It’s time to explore Registry manipulations. In the RegDemo example, you’ll see how to create, open, write, read, and delete keys and their associated values. We’ll also see how you can use a single Registry entry to store a variety of items of data. The RegDemo example is designed to be used in combination with the Remote Registry Editor. As you use the example menu choices, try inspecting the registry of the device to observe the changes in keys and values.
As in previous examples, we include only the main source file RegDemo.cpp in the example code files. You can generate the rest of the source using development environment wizards, and then paste the functional elements of the example into your generated code skeleton. This approach protects you from path name conflicts that might occur if you used my support code files.
Adding Registry Keys
You can add Registry keys with either the RegOpenKeyEx() or RegCreateKeyEx() function. The advantage of using RegCreateKey() is that it creates a key if the key doesn’t already exist as well as opening it. In the RegDemo example, we use RegCreateKeyEx() in response to the IDM_ADD_KEY message.
case IDM_ADD_KEY:
//if !n2
//reg me
//else open my key
rc = RegCreateKeyEx (HKEY_LOCAL_MACHINE,
TEXT("Softwaren2"), 0,
TEXT (""), 0, 0, NULL,
&hKeyN2, &dwDisp);
The parameters to RegCreateKey, in the order shown, are the handle to the parent key; the name, as aUnicode string, of the key to add; a NULL placeholder for a reserved parameter; the class name of the key as aUnicode string; three more place holders set to 0,0, and NULL respectively; the address of a variable to receive the returned handle if the key is created successfully; and the address of a Variable to receive the disposition of the call.
Notice that the value of the first parameter is HKEY_LOCAL_MACHINE, which corresponds to one of the root key names in the Registry. Used in this context, HKEY_LOCAL_MACHINE identifies a reserved handle to this key, and can be treated just as though it were returned by RegCreateKey() or RegOpenKey(). There are four reserved key handles you may use to access the top level of the CE Registry.
Figure 3: Windows CE Reserved Handles
| Handle Name |
| HKEY_CLASSES_ROOT |
| HKEY_CURRENT_USER |
| HKEY_LOCAL_MACHINE |
| HKEY_USERS |
Now, take a look at the second parameter:
TEXT("Softwaren2"),
Notice that we have descended two levels in the Registry tree to create and open the key “n2”. You don’t have to traverse the Registry’s hierarchy one step at a time if you know the full name of the key you want to open.
Finally, make note of the dwDisp parameter. After a successful return, dwDisp will contain one of two values: REG_CREATED_NEW_KEY or REG_OPENED_EXISTING_KEY. Use this value to detect whether or not the key existed before the call.
Skipping over the message box code, we finish the handling of this case by closing the key handle. This is a very important step because leaving the key open may cause subsequent accesses to fail.
//clean up after ourselves RegCloseKey( hKeyN2 ); break;
Looking Ahead
In the next installment, we’ll continue exploring the RegDemo example, and learn how to access and enumerate Registry keys.
About the Author
Nancy Nicolaisen is a software engineer who has designed and implemented highly modular Windows CE products that include features such as full remote diagnostics, CE-side data compression, dynamically constructed user interface, automatic screen size detection, entry time data validation.
In addition to writing for Developer.com, she has written several books including Making Win 32 Applications Mobile.
# # #
