October 24, 2014
Hot Topics:
RSS RSS feed Download our iPhone app

Using the Windows CE Registry

  • October 29, 2003
  • By Nancy Nicolaisen
  • Send Email »
  • More Articles »

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



Click here for a larger image.

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



Click here for a larger image.

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.





Page 1 of 2



Comment and Contribute

 


(Maximum characters: 1200). You have characters left.

 

 


Sitemap | Contact Us

Rocket Fuel