LOOKING AT THE HISTORY OF THE WINDOW'S REGISTRY

In 16-bit applications, developers used to keep track of application-specific options by using INI (*.ini) files, also known as profiles. These files were set up in a way that you could specify sections and items with values assigned so that you could read from within your application to perform tasks or customize your application. Applications such as Access 2.0 would use one of these files to specify:

• The workgroup file (System.mdb) to be used

• ISAM driver options

• Jet locking options

• Other system defaults

When switching over to 32-bit, using NT and Windows 95/98, applications changed to using the Windows Registry.

Now that you have an idea of where the Registry comes from, look at some reasons you might want to use the Registry for your own applications.

Using the Windows Registry in Your Applications

At this point, you might be saying to yourself, “Okay, I realize that there's a Registry out there, and that commercial applications such as Office use it to keep track of things. But why should I hassle with it?” There are a number of reasons for doing so.

One main reason to use the Registry is to store custom properties for each application and each user. Access has a custom property page in the Database Properties dialog (choose Database Properties from the File menu). You can keep track of custom properties for your own purposes. In custom properties, you can keep track of items such as

• Back-end name and location

• Whether the client is using replication

• Version number of the application

• Whether the application is using a Jet or SQL Server back end

• Whether the application is being used with a production or development machine

• The names of the production and development servers

• What type of menu to display for the current user

There are many other items as well, some of which are shown in Figure 18.1.

Other applications store this information in different ways. Even in Access, many developers store these pieces of information in a table. The problem with just storing configuration data or database properties in a table is that you have to worry about writing over it when the application is updated. For example, when working on an application that uses a SQL Server back end, the development machine used might have a different server location than the production server used by the client. If a flag whether to use the product or development server is in the front-end database, you have to set the flag each time you give a copy to the client. It obviously can't be kept in the back end because that's what the application is trying to link to. A good answer is the Registry. In Figure 18.2, the same properties that were stored in the Database Properties dialog are now stored in the Registry.

You can see all the parts of the Registry in Figure 18.2, so let's discuss them.

Parts Making Up the Registry

Technically, the Registry is actually made up of two types of items: keys and values presented in a tree view format, similar to the Explorer. When working with the Registry, you will use a couple of types of keys, predefined keys, and subkeys.

Predefined Keys

Predefined keys are the base keys predefined by Windows and should definitely not be messed with (see Table 18.1).

Subkeys

A subkey is simply a child key of a parent. All keys below the predefined keys are subkeys. You will see plenty of examples of subkeys throughout the chapter.

Values

The last part making up the Registry can be set for every key except the predefined keys. Keys can also have multiple values. Every key also has a default value, which can be set. With values, you specify the name, data type, and the data (value) itself.

In Figure 18.2 are examples of everything discussed in this section. In the lower-left portion of the figure are four of the predefined keys mentioned. You can see keys as a whole up and down the left side of the figure. Located on the right you can see multiple values and the default values for the Settings key.

I hope this gives you an idea on what makes up the Registry. Later in the chapter, you see how to create, update, and delete keys and values in the Registry. The tool used to display the Registry in Figure 18.2, Regedit.exe, is part of the tool set included in all 32-bit Windows versions for editing the Registry.

Tools Used For Working with the Registry

As mentioned, all versions of the 32-bit version of Windows use Regedit.exe to edit the Registry. To use it, choose Run from the Start menu, type Regedit, and click OK. You're then brought into the Registry Editor, which displays something similar to Figure 18.3.

In the Registry Editor for keys, subkeys, and individual values you can

• Add

• Delete

• Edit

• Find text and numbers within them (you use this when you want to find some values you enter through code later in this chapter)

• Import and export part or the entire Registry

The last feature allows you to restore the Registry from a previously saved version. It's a good idea to export the current settings before making major changes to the Registry.

Before performing any of these tasks, from the Regedit menu choose Registry and then Export Registry File. Then supply a file name for the Registry file you're going to create, and click OK.

Snoop around the Registry a bit to get comfortable with it. It probably isn't a good idea to change any values at this time, but find the Access settings starting at the HKEY_CURRENT_USER predefined key. To do this, follow these steps:

To change a value, let's choose a fairly safe one to modify. In the list of Access options, double-click Debug Window on Top. The Edit DWORD Value dialog appears, showing Edit DWORD Value. To change it, simply supply the opposite value of what it now is, and then click OK.

To add keys and values, right-click the key you want to add the key or value to, and then choose New and the type of item you want to add. This can be a key or the various types of values: Binary, String, or DWORD (numeric). You can also edit, rename, and copy keys and values from this right-click menu.

You will get much experience with Regedit.exe as you work with the Registry. Let's look at the other tool used—Regsvr32.exe.

Regsvr32.exe is used to add and delete entries into the Registry for ActiveX components, DLLs, and other system files that accompany tools and applications. This process is called registering or unregistering the files. Although most applications perform this as a step in their setup programs, in some cases you have to do this yourself.

To register a DLL, choose Run from the Start menu. Then type Regsvr32 with the full name and path of the DLL following it. The syntax would be

Regsvr32 PathName.Ext

After you type Regsvr32 into the Run dialog, you can also drag and drop the file from the Windows Explorer if you have it open.

Some files and utilities have an accompanying file with the extension of *.reg. If you double-click this file, Window will register all the files listed in the *.reg.

To unregister files, place the command-line argument /u before the filename. When registering and unregistering files, it's a good idea to reboot the machine so that Windows will be sure to include the entry.

That's about it for the built-in tools. It's time now for the fun stuff of working with VBA and the Registry.