VBA includes a number of commands to give developers Registry access. They are pretty straightforward to use when you have an idea how to work with the Registry, which at this point you should.
Six commands deal with the Registry; Table 18.2 lists four.
Note
Although these commands are available to all development environments that use VBA, there is also some Access-specific commands for setting Access options:
The SetOption statement lets you set the individual options in Access (refer to Figure 18.4). To see more about this command, check out the help in Access.
An individual user profile is a special set of Windows Registry keys that you can create to override standard Microsoft Access and Microsoft Jet database engine settings and to specify additional runtime options. You then can use a user pro file when opening an Access database by specifying /profile with the name of the user profile file in the command line. More on this can be found by looking up profiles in the Access help.
A number of commands also work with Jet objects and references. These commands work in all VBA environments when working with these objects.
The first command I want to discuss is the SaveSetting statement, the last in Table 18.2. From VBA you can use SaveSetting to store the default settings you want to create for your application. You can see this in Listing 18.1. This routine, part of the modVBARegRoutines module, can be found in Chap18.mdb, which is located in the ExamplesChap18 folder on the CD-ROM.
Sub CreateRegSettingDefaults() ' Place some settings in the registry. SaveSetting appname:="Chapter 18 - Registry Example App", _ Section:="Settings", key:="UseJet", setting:=True SaveSetting appname:="Chapter 18 - Registry Example App", _ Section:="Settings", key:="BackendName", setting:="Chap18BE1.mdb" SaveSetting appname:="Chapter 18 - Registry Example App", _ Section:="Settings", key:="BackendPath", _ setting:="c:BooksPwrPrg2000AppCDChap18" SaveSetting appname:="Chapter 18 - Registry Example App", _ Section:="Settings", key:="UseReplication", setting:=False SaveSetting appname:="Chapter 18 - Registry Example App", _ Section:="Settings", key:="ProdOrDev", setting:="Development" SaveSetting appname:="Chapter 18 - Registry Example App", _ Section:="Settings", key:="ProdServer", setting:="Fortknox" SaveSetting appname:="Chapter 18 - Registry Example App", _ Section:="Settings", key:="DevServer", setting:="Abednego" SaveSetting appname:="Chapter 18 - Registry Example App", _ Section:="Settings", key:="MenuType", setting:="User" End Sub |
Normally, you would want to track default values by using a more data-driven method, rather than the hard-code values shown here. I will show you this method in a moment. However, running the CreateRegSettingsDefaults routine creates the Registry entries as shown in Figure 18.5.
To take this a step further, let's use Access to store initial values that will be stored in the Registry. The next routine deletes all the settings for the application, cycles though a table, and generates the defaults. Figure 18.6 shows the values stored in the tblDefaultSettings table.
Listing 18.2 shows the code to perform this latest task.
This routine uses two Registry commands, DeleteSetting and SaveSetting. It works great when you want to re-create all the default settings for an application. If you want only to add settings and not overwrite current settings, however, you need to add the command GetSetting and modify the CreateAllSettingsFromTable routine. Listing 18.3 shows how this is done in CreateNewSettingsFromTable.
This routine is useful when you're updating an application and don't want to overwrite current settings, but want to add any new defaults used by the system. Also, when using the application on the same machine, people can have the default settings recorded into the Registry without overwriting other user's settings because VBA puts the entries under the HKEY_CURRENT_USER key.
Now, to use the defaults recorded in the Registry, you use only the GetSetting command with the name of the setting (value) you desire. A wrapper function, GetDefaultSetting(), performs this task:
Public Function GetDefaultSetting(strNameOfSetting As String) As String GetDefaultSetting = _ GetSetting(appname:=CurrentDb().Properties("AppTitle"), _ Section:="Settings", key:=strNameOfSetting) End Function
Note
Wrapper routines are VBA routines that you create to simplify the calling of more complex routines and commands. These include API calls as well.
To round out the routines for simple Registry manipulation using VBA commands, here are a couple that allow you to update individual settings and delete a setting. Note that the setting would be added again if any create setting routines are called.
Public Sub SetDefaultSetting(strNameOfSetting As String, strValue As String) SaveSetting appname:=CurrentDb().Properties("AppTitle"), _ Section:="Settings", key:=strNameOfSetting, setting:=strValue End Sub Public Sub DeleteDefaultSetting(strNameOfSetting As String) DeleteSetting appname:=CurrentDb().Properties("AppTitle"), _ Section:="Settings", key:=strNameOfSetting End Sub
There you have it. These routines are all you need to create and maintain Registry settings for your application. Although these will work for simple tasks of working with defaults, there are a number of limitations, including the following:
All the settings will be maintained in the key path
HKEY_CURRENT_USERSoftwareVB and VBA Program Settings
Sometimes you might not want to have the settings in this path.
If your path is more complicated and you need to have more keys and values with different branches, using the straight VBA commands can be somewhat cumbersome.
The solution to these limitations is using API calls to the Registry. Now, before running off in terror, you can use the wrapper routines supplied with the sample database and not have to worry about shooting yourself in the foot (too much). Remember that a wrapper routine in this case is a VBA routine created to set up variables needed for calling API routines. They make life much easier, especially because you can usually cut and paste the routines into your own application without knowing all that's going on behind the API routine.
18.216.190.167