Hacker’s Guide to Visual FoxPro
An irreverent look at how Visual FoxPro really works. Tells you the inside scoop on every command, function, property, event and method of Visual FoxPro.
Registration Database
It’s been a long, strange trip for the Registry. Under Windows 3.1, this odd little file was more of a curiosity than an important file. Under Windows 95 and later versions, it’s probably the most critical set of files on your system. The Registry stores important information on the system’s hardware, startup, configuration, network protocols, and application characteristics. Perhaps most importantly from the perspective of application developers, the Registry is the primary repository of all things Active: ActiveX controls, keys to ActiveX servers and services, and anything and everything having to do with the classes and instantiating them. If the Registry is corrupt, there’s not much chance any component-dependent application will function. If ever there was a reason to make reliable and regular backups of your system, the Registry is it.
The internal structure of the Registry is beyond us, but the interface that it presents through the API is pretty straightforward. The Registry is represented as a series of tree structures, or “hives,” each with a particular purpose. Each hive branches from its root nodes into many branches, each of which, in turn, can also branch. The final leaf nodes of these keys contain one or more values, typically a single string, integer or binary value.
Each hive has a specific purpose. HKEY_CURRENT_USER, not surprisingly, is data about the logged-in client: files stored especially for him or settings he has personalized. HKEY_LOCAL_MACHINE deals with machine-specific settings and drivers, and HKEY_CLASSES_ROOT deal with software classes installed system-wide (rather than just for a specific user). The remaining hives, HKEY_USERS, HKEY_CURRENT_CONFIG, and HKEY_DYN_DATA, hold information far more useful to the system than to us as developers. You can examine the Registry by using the REGEDIT program supplied with the operating system—but be careful! A poorly considered change can make your system unbootable. Windows NT and 2000 users also have the option to use RegEdt32.EXE, which provides more options, such as opening another computer’s Registry, or editing the security privileges for specified sets of keys.
The FoxPro Foundation Classes (FFC) that come with Visual FoxPro include a great set of classes for manipulating the Registry in Registry.VCX. There are classes for basic Registry manipulation, as well as specific classes to read and write Registry settings for Visual FoxPro, ODBC, application extensions, and INI Files.
There are a few situations when you will need to manipulate the Registry. The first is when you are installing software on a client’s machine. Typically, Setup takes care of the registration issues for you. Most installation programs, such as the VFP version of InstallShield Express, which comes on the VFP CD, handle registering any ActiveX control and COM servers in the Registry as part of the install process.
Another time you’ll want access to the Registry is when your application wants to read or write settings. Registry.VCX is great for providing this interface. If these are application-wide settings, such as the location of files on the network, set up a Registry key under HKEY_LOCAL_MACHINE. If the values are more appropriate to be customized to each user, such as screen colors or positions, use HKEY_CURRENT_USER instead. In either case, you’ll want to follow the convention of storing your values in this format: \Software\YourCompany\YourAppName\Version\YourKeys. This will give you the most flexibility in supporting multiple versions of your application, perhaps importing older settings into a newer version.
The third situation is the one we wish we were never in—troubleshooting a failed installation or an application that won’t work. As we’ve said, the Registry is a complex database of branching structures and multiple values. If an errant program writes random information into the Registry, there’s a good chance that nothing will work again. We usually take as methodical an approach as possible to troubleshooting. If the troubles seem isolated to a single component, attempt to unregister and reregister that component (issue the command RegSvr32 /? from the command line for the options available). If that doesn’t cure the problem, sometimes removing and reinstalling the entire application might provide the cure.
The next step is to try to recover the Registry from a backup. Check your operating system for documentation on creating a rescue disk (RDISK) or emergency boot disk (EBD) as appropriate. Several commercial backup programs also support backup and restoration of the Registry.
If you’re still in trouble, two options remain: trying a Registry-repair program or reinstalling the operating system and all applications. The first may be your only choice if you lack all the files needed for a full reinstall; the latter is assured of working, but with a high cost in terms of time and effort. We have had some luck in recovering systems using the RegClean tool from Microsoft (search their Web site for the most recent version), but several commercial products are also out there. Check your favorite programming magazines or a good Web search engine for some ideas.
Run Regedit.EXE to browse through the Registry and get some idea of what your application may want to do. We encourage you to consider the Registry for configuration information, customizations for each user, and state information, such as the most-recently-used (MRU) files, databases, configurations, or sub-systems of your application. These items, if managed correctly and presented properly, give your application a professional look.