home   Java Script   MS Access   Perl   HTML   Delphi   C ++   Visual Basic   Java   CGIPerl   MS Excel   Front Page 98   Windows 98   Ms Word   Builder   PHP   Assembler     Link to us   Links    

Previous Page TOC Index Next Page Home


Distributing Your Application with the Access Developer's Toolkit

Distributing Your Application: An Introduction

Many developers are responsible for designing applications that will be distributed to many users. The most basic distribution option is to require each user to purchase a copy of Access and then simply provide each user with a copy of the database (.MDB) files required for the application. The developer can then go to each user and configure the application appropriately.

Although distributing an application by copying it to each user's machine does not require much specialized knowledge on the part of the developer, it is generally not very practical. For one thing, it is often prohibitively expensive for each user of the application to own a copy of Access. Furthermore, in many situations the developer is distributing an application to users who are geographically dispersed throughout the country or even the world. Many Access applications are mass-marketed to hundreds or even thousands of users. It is very impractical to require such a user base to own Microsoft Access or properly install the application without a professional setup program. Finally, without the Access Developer's Toolkit, it is much more difficult for you as a developer to provide the user with the professional look and feel that you want your application to have. For these reasons, it is necessary for most developers to purchase the Access Developer's Toolkit and learn how to take advantage of what it offers.

What's in the Access Developer's Toolkit?

The Microsoft Access Developer's Toolkit is a product that enables you to package and distribute professional-looking applications, without requiring your users to purchase the Access application software. Actually, the Access Developer's Toolkit, more commonly referred to as the ADT, is like several products in one. It includes the following tools:

Each of these components are discussed in the sections that follow.

The Royalty-Free Runtime License

The royalty-free runtime license provided with the ADT allows your users to take advantage of your application and all that it provides, without owning their own copy of Access. As you will see in the "Understanding the Differences between Full and Runtime Versions of Access" section of this chapter, your users cannot directly create new database objects with the Access runtime. Nor do they have access to the Database window, built-in toolbars, numerous menu items, and several other features that are part of the full Access product. In many situations, you won't want the user to have access to all of these features. Instead, you want to provide your users with a very complete, fully integrated application that only you will be responsible for modifying. Furthermore, you want to provide all of this to your users without requiring them to purchase Access. The ADT, with its royalty-free runtime license, enables you to do exactly that.

The Setup Wizard

The Setup Wizard enables you to easily create distribution disks containing all of the files necessary to run your application. The Setup Wizard creates a highly professional-looking setup program that your users will run when they want to install your application. Using the Setup Wizard, you can customize what is included with your application. You can even provide your users with the familiar Standard, Compressed, and Custom options that they have come to know from installing other Microsoft products. The Setup Wizard is covered in detail in the "The Setup Wizard" section of this chapter.

The Replication Manager

The Replication Manager is a tool that enables you to manage Replication within your custom application. This highly powerful, very sophisticated tool contains a runtime that can be distributed with your applications. The Replication Manager is covered in detail in Chapter 23, "Replication Made Easy."

Two-Volume Language Reference

To many people's surprise, Access includes neither a Language Reference nor a Data Access Reference as "standard equipment." Although such documentation is available online, many developers prefer to view their documentation in print. Both the Access Language Reference and the Data Access Reference are included in hard copy with the ADT.

32-Bit OLE Controls

OLE controls provide your application with significant functionality with little work on your part. Only one OLE control ships with Access: the Calendar control. The ADT ships with 12 additional, extremely utilitarian custom controls. They include the Common Dialog control, Rich Text Box control, Status Bar control, and Data Outline control, just to mention a few. These controls all help you to build highly professional applications with minimal effort. OLE custom controls are covered in detail in Chapter 25, "Using OLE Controls."

The Win32 API Text Viewer

The Win32 API Text Viewer facilitates the process of including the Declare statements, Type declarations, and Constant declarations required for you to utilize DLL functions in your applications. The ADT ships with Win32API.txt. This file, when loaded into the Win32 API Text Viewer, enables you to select Declare statements, Type declarations, and Constant declarations and copy them into your modules with the click of a mouse. This time-saving tool is discussed in detail in Chapter 28, "External Functions: The Windows API."

The Windows 95 Help Compiler

The Windows 95 Help Compiler, officially called the Microsoft Help Workshop, significantly eases the pain associated with the process of building custom Help into your applications. It assists with the process of creating the Help project, allowing you to easily specify all of the components of the project. The Windows 95 Help Compiler and Microsoft Help Workshop are covered in detail in Chapter 33, "Developing a Help File."

The Microsoft Access Developer Sample CD

The Microsoft Access Developer Sample CD is a sampler CD containing information about the Microsoft Developer Network. It also includes numerous articles and white papers that can assist you with the completion of many complex tasks.

The Microsoft Graph Runtime Executable

The Microsoft Graph Runtime Executable enables you to distribute this graphing engine with your application. This means that you can add graphing functionality to your applications without mandating that your users own some other product that includes Microsoft Graph.

Distributing Your Application to Run With a Full Copy of Access

Many developers distribute their applications to end-users who own and have already installed Microsoft Access. These users might be responsible for designing their own ad hoc queries and reports. For these users, it is important that you properly secure your application, ensure that you provide the users of your application with only the functionality that you want included in your application, and provide professional polish to your application.

Many of the topics in this chapter apply to your application whether you are distributing the application to users with the Access runtime or with the full copy of Access. For example, you probably should include a Switchboard, custom menu bars, and custom toolbars in your application, whether you are distributing your application with the runtime or for use under the full version of Access.

Understanding the Differences between Full and Runtime Versions of Access

Many people have the misconception that using the Setup Wizard and distributing your application using the Access runtime somehow means that the application is compiled. This is not the case at all! In fact, if the database is not properly secured, anyone can install his or her own copy of Access and modify the application's data and other objects just as you can. Using the Setup Wizard and distributing your application with the Access runtime does not modify the database in any way. It simply gives you the license to freely distribute the engine required to run your application.

Actually, the engine is not even a modified version of the Access executable! The MSACCESS.EXE that you distribute is the same as the MSACCESS.EXE that you use to build your application. When you use the Setup Wizard to create installation disks for your users, the same MSACCESS.EXE that you use is copied to the installation disks. So how can there be any difference between the retail and runtime versions of Access?

When the user installs your application, the MSACCESS.EXE is copied to the user's machine. During this process, the installation program checks a Windows Registry licensing key to see whether the user owns a copy of Access. If the licensing key indicates that the user does not own a copy of Access, or if the licensing key does not exist, the licensing key (which is a set of numbers and letters) is updated to indicate that the user will be using the runtime version of the product. Whenever Access executes and the runtime licensing key is found, the product launches in runtime mode.

When the runtime licensing key is found, Access behaves differently than when the full licensing key is found. If you are not aware of the differences, you will be quite surprised when certain aspects of your application no longer function as expected. The following is a list of differences between the full and runtime versions of the product:

Hidden Database Window

When users launch your application using the runtime version of Access, the Database window is not visible. It's actually there, but it is hidden because its colors are set to the same colors as the Windows background color. This means that you can interact with the Database window using code, but the users of your application will be unable to interact with the Database window directly.

The fact that the Database window is hidden tends to be a double-edged sword. On one hand, it prevents most users from modifying the objects within your application. On the other hand, it puts the onus on you to build a complete interface for your application. Remember that, for you as a developer, the Database window is a starting point. You must provide a different starting point and navigational tools for your users to maneuver about your application.

Hidden Design Views

The users of your application won't directly have access to any design views, which means that they are unable to create or modify tables, queries, forms, reports, macros, or modules. You can still get to all of this functionality through code. This means, for example, that you can build a wizard that allows your user to define all aspects of a query or some other object and then build the query (or other object) using DAO code. Again, this helps protect your application from novice users, but it puts the pressure on you to ensure that your application provides its users with all of the functionality that they need.

Built-In Toolbars Not Supported

All built-in toolbars are completely unavailable with the runtime version of Access, which means that you must design your own toolbars and attach them to your forms and reports as appropriate. This is covered in the "Adding Custom Menus and Toolbars" section of this chapter.

Unavailable Menu Items

Built-in toolbars are not supported at all when using the runtime version of Access, but menus are simply modified when the runtime key is found. Many menu items are hidden in the runtime version. These hidden menu items prevent users from making changes to your application. The easiest way to obtain a list of hidden menu items is to look in the Access Developer's Toolkit help file. The Help file contains a topic "Hidden Menu Commands in the Runtime Environment," which is shown in Figure 35.1. This Help topic shows each hidden menu command, within which menu it is contained, and from which windows it is removed.

Figure 35.1. Help on hidden menu commands in the runtime environment.

Although many of the menu commands are hidden from the user, they can be accessed using the DoMenuItem command. In other words, the functionality is there, but it is simply hidden from your users.

Disabled Keys

Several keystrokes are unavailable to your users when they run your application with the runtime version of Access. These keystrokes are listed in Table 35.1.




Halts macro and code execution.

Shift (when opening the database)

Prevents execution of the AutoExec macro and ignores Startup properties.

Alt+F1 / F11

Displays the Database window.


Displays the Save As dialog.


Saves a database object.


Displays the Debug window.


Toggles between custom and built-in toolbars.

As you can see, these are keys that you would rarely, if ever, want your users to use. You might consider the disabling of these keystrokes a positive side-effect of using the runtime version of the product.

Preparing Your Database for Use With the Access Runtime

Several steps are required to prepare your database for use with the Access runtime. Although many of these steps are mandatory when distributing your application with the runtime, they are also good as a general practice in developing a polished application. To prepare your application for use with the Access Runtime, follow these steps:

Create the Application

You need to be concerned about several things when designing an application for use with the Access runtime. Although the following items are niceties in any application, they are a mandatory aspect of developing an application for use with the Access runtime:

Build the Application Around Forms

The first step in creating the application with runtime distribution in mind is to build the application around forms. This means that everything in the application needs to be forms-driven. Your application should generally begin by displaying a Main Switchboard. The Main Switchboard can then navigate the user to additional switchboards such as a Data Entry Switchboard, Reports Switchboard, Maintenance Switchboard, and so on. The easiest way to create such a switchboard is by using the Switchboard Wizard. Here's how it works:

  1. Select Tools|Add-ins|Switchboard Manager. If you have not yet created a switchboard for your application, the Switchboard Manager dialog appears (see Figure 35.2).

Figure 35.2. Creating a new switchboard.

  1. Click Yes. The Switchboard Manager dialog appears (see Figure 35.3). Notice that a Main Switchboard is created.

Figure 35.3. The Switchboard Manager dialog.

  1. Begin by adding additional switchboard pages. To do this, click New. The Create New dialog appears (see Figure 35.4).

Figure 35.4. The Create New dialog.

  1. Type a name for the new switchboard page and click OK.

  2. Repeat steps 3 and 4 for each switchboard page you want to add.

  3. When you are done adding pages, the Switchboard Manager window should look something like the one in Figure 35.5. You are now ready to add items to each switchboard page. To add items to the Main Switchboard, click the Main Switchboard entry and click Edit. The Edit Switchboard dialog appears (see Figure 35.6).

Figure 35.5. The Switchboard dialog after adding pages.

Figure 35.6. The Edit Switchboard Page dialog.

  1. Click New to add a new item to the Main Switchboard. The Edit Switchboard Item dialog appears (see Figure 35.7).

Figure 35.7. The Edit Switchboard Item dialog.

  1. Select the text for the new switchboard item.

  2. Select an appropriate command from the Command drop-down. Available commands control the capability to go to another switchboard, open a form, or open a report.

  3. The third item in the Edit Switchboard Item dialog varies depending on which command you select from the Command drop-down. For example, if you select Go to Switchboard from the Command drop-down, the third option allows you to select from available switchboards. If you select Open Form in Edit Mode, the third option allows you to select from available forms. Select the third option and click OK.

  4. Repeat steps 7 through 10 to add each item to the Main Switchboard.

  5. After adding entries to the Main Switchboard, the Edit Switchboard Page dialog should look similar to the one in Figure 35.8. Click Close to return to the main Switchboard Manager dialog.

Figure 35.8. The Edit Switchboard Page dialog after adding several entries.

  1. Repeat steps 6 through 12 for each switchboard page.

  2. When you are ready to generate the switchboard, click Close from the main Switchboard Manager window. The switchboard is then generated.

Follow these steps to add, remove, or edit items from an existing switchboard:

  1. Select Tools|Add-ins|Switchboard Manager. The Switchboard Manager dialog appears.

  2. Select the Switchboard page that you want to affect. Click Delete to delete the page, or click Edit to make changes to the page. If you want to add a new page, click Add.

  3. If you select Edit, the Edit Switchboard Page dialog appears. You can use the Move Up and Move Down buttons to move items up and down on the Switchboard page. You can also Add, Edit, and Delete items from the page.

  4. When you are finished, click OK. The changes take effect immediately.

An example of a completed switchboard appears in Figure 35.9.

Figure 35.9. A completed switchboard.

Build Error Handling into the Application

It is imperative that you build error handling into your application. If an error occurs when the user is using the runtime version of Access and no error handling is in place, an error message is displayed and the user is instantly returned to the Windows desktop. Therefore, it is crucial that you build error handling into all of your routines. Creating a generic error handler to assist you with this task is covered in Chapter 17, "Handling Those Dreaded Runtime Errors."

Adding Custom Menus and Toolbars

As mentioned in the "Understanding the Differences between Full and Runtime Versions of Access" section of this chapter, limited versions of the standard Access menus are available under the Access runtime, but toolbars are not available at all. It is therefore necessary that you provide your users with whatever menu bar and tool bar functionality is required by the application.

As discussed in Chapter 13, "Let's Get More Intimate With Forms: Advanced Techniques," a menu bar can be attached to a form using the Menu Bar property of the form (see Figure 35.10). When a specific menu bar has been associated with a particular form or report, the menu appears whenever the form or report becomes the active window (see Figure 35.11). It is generally easier to base a form or report's menu on one of the standard Access menus and then add or remove menu items as appropriate.

Figure 35.10. The Menu Bar Property of a form.

Figure 35.11. A custom menu for the frmClients form.

You must build each toolbar that you want to use with your application. As covered in Chapter 13, you must write code to ensure that a toolbar is visible when a form or report is displayed and is hidden when it no longer applies. This is illustrated by the following code placed in the Activate event of the form or report:

Private Sub Form_Activate()

On Error GoTo Err_Form_Activate

    Call ToolBarShow("tbrMainForm", True)



    Exit Sub


    MsgBox Err.Description

    Resume Exit_Form_Activate

End Sub

The Activate event of the frmClients form calls a user-defined procedure called ToolbarShow. It passes the ToolbarShow routine two parameters: the name of the toolbar that it will affect and a Boolean indicating whether the specified toolbar should be shown or hidden. The ToolbarShow routine looks like this:

Sub ToolBarShow(strToolbar As String, fShow As Boolean)

   DoCmd.ShowToolbar strToolbar, _

         IIf(fShow, acToolbarYes, acToolbarNo)

   DoCmd.ShowToolbar "Form View", _

         IIf(fShow, acToolbarNo, acToolbarWhereApprop)

End Sub

The ToolBarShow routine is one routine that handles both the showing and hiding of custom toolbars. It receives a string and a Boolean variable. It uses the ShowToolbar method of the DoCmd object to set the visibility of a specific toolbar. The particular toolbar that ToolShowBar either shows or hides is governed by the name that was passed to it along with the value of the associated Boolean variable. For example, if the ToolBarShow routine is passed the string tbrMainForm and the Boolean True, it shows the toolbar called tbrMainForm (see Figure 35.12).

Figure 35.12. A form with a custom toolbar.

In case the application will run in both the retail and runtime versions of Access, you should ensure that the standard toolbar is hidden when the form is active. The second ShowToolbar method indicates that the Form View toolbar will be hidden if you are displaying the custom toolbar and will be shown, where appropriate, if you are hiding the custom toolbar. The Deactivate event of the form looks like this:

Private Sub Form_Deactivate()

    Call ToolBarShow("tbrMainForm", False)

End Sub

This routine serves to hide the tbrMainForm toolbar and show the Form View toolbar where appropriate.

Clearly, it is important that you do all of the menu and toolbar handling required by your application. This ensures that all menu bars and toolbars are available when they should be, and only when they should be.

Setting Startup Options

Access 95 provides you with several startup options that enable you to control what happens to your application when it is loaded. The Startup dialog is shown in Figure 35.13 and includes the Advanced options. Each option in the Startup dialog is displayed in Table 35.2.

Figure 35.13. The Startup dialog.



Application Title

Sets the AppTitle property. This property is used to display a custom title in the application title bar.

Application Icon

Sets the AppIcon property. This property is used to display a custom icon in the application title bar.

Menu Bar

Sets the StartupMenuBar property. This property is used to specify the custom menu bar that is displayed by default when the application is loaded.

Allow Full Menus

Sets the AllowFullMenus property. This property is used to allow or restrict the use of Access menus.

Allow Default Shortcut Menus

Sets the AllowShortcutMenus property. This property is used to allow or restrict the use of standard Access shortcut menus.

Display Form

Sets the StartupForm property. This property is used to specify the form that is displayed when the application is loaded.

Display Database Window

Sets the StartupShowDBWindow property. This property is used to determine whether the Database window is visible when the application is opened.

Display Status Bar

Sets the StartupShowStatusBar property. This property is used to determine whether the status bar is visible when the application is opened.

Shortcut Menu Bar

Sets the StartupShortcutMenuBar property. This property is used to specify a menu bar that is displayed by default as the shortcut menu bar.

Allow Built-in Toolbars

Sets the AllowBuiltInToolbars property. This property is used to indicate whether built-in toolbars are available to your users.

Allow Toolbar Changes

Sets the AllowToolbarChanges property. This property is used to determine whether your users can customize toolbars within the application.

Allow Viewing Code

Sets the AllowBreakIntoCode property.

After Error

This property is used to indicate whether Ctrl+Break places the user in the Code window after an error.

Use Access Special Keys

Sets the AllowSpecialKeys property. This property determines whether the user can use keys such as F11 to display the Database window, Ctrl+F11 to toggle between custom and built-in toolbars, and so on.

As you might have guessed, many of these options apply only when you are running the application under the retail version of Access. For example, you do not need to set the Display Database Window property if your application will only be running under the runtime version of Access. The Database window is never available under the runtime version of the product, so this property is ignored when the application is run under the runtime version. Regardless, I like setting these properties to ensure that the application behaves as I want it to under both the retail and runtime versions of the product.

All of the properties can be set using either the Startup dialog or code. If you use code, you must make sure that the property exists for the Database object before you set it. If the property does not exist, you must append the property to the Database object.

Only users with Administer permission for the database can modify the Startup properties. If you want to ensure that certain users cannot modify the startup options of the database, you must ensure that they do not have Administer permissions.

As part of the startup options for your database, you should determine what code, if any, is run when the application is loaded. You can accomplish this in one of two ways. You can start the application with an AutoExec macro and then issue a RunCode action to execute a VBA procedure. The other option is to designate a Startup form for the application and then call a custom AutoExec routine from the Open event of the Startup form. The following code is called from the Open event of the Startup form for the Time and Billing application. This code, and the rest of the code in this chapter, can be found in the CHAP35.MDB database file found on the sample code CD.

Sub AutoExec(frmAny As Form)

   On Error GoTo AutoExec_Err:

   Dim fAnswer As Boolean

   DoCmd.OpenForm "frmSplash"


   DoCmd.Hourglass True

   fAnswer = AreTablesAttached(frmAny)

   If Not fAnswer Then

      MsgBox "You Cannot Run This App Without Locating Data Tables"

      DoCmd.Close acForm, "frmSplash"


   End If

   Call GetCompanyInfo

   DoCmd.Hourglass False

   If IsLoaded("frmSplash") Then

      DoCmd.Close acForm, "frmSplash"

   End If

   Exit Sub


      DoCmd.Hourglass False

      MsgBox "Error # " & Err.Number & ": " & Err.Description

      Exit Sub

End Sub

This generic routine receives any form as a parameter. It uses the OpenForm method to open a form called frmSplash. Then it issues a DoEvents command to give the form time to open. An hourglass mouse pointer is displayed and the routine calls a user-defined function that ensures that the database tables are linked successfully. This AreTablesAttached routine is covered in the "Automating the Process of Linking Tables" section of this chapter. If the AreTablesAttached function returns False, the user is warned that he or she cannot run the application. The frmSplash form is closed and the application is exited. As long as the table links were successfully established, the AutoExec routine proceeds to call a routine called GetCompanyInfo, where it loads frequently used information into an array. The hourglass mouse pointer is removed and the splash screen is unloaded.

Securing the Application

Don't fool yourself! Remember that the runtime version of Access in no way secures your application. It simply allows you royalty-free distribution. You must perform all the same measures to secure your application under the runtime version of Access that you perform under the retail version of the product. The bottom line is that if you want your application and its data to be secure, you must take measures to secure it. The basics of security are covered in Chapter 29, "Database Security Made Easy," and the intricacies of security are covered in Chapter 30, "Complex Security Issues."

Add Custom Help to the Application

To add polish to your application and ensure that the help you provide to your users applies to what they are looking at within your application, you must provide a custom Help file. Adding Help to your application is covered in detail in Chapter 33, "Developing a Help File." In essence, it involves creating an RTF file and other supporting files and using the Windows 95 Help Workshop to build a compiled Help file. You must then add help to the various objects within your application.

Test and Debug the Application

Before you even bother trying to run your application under the runtime version, you should fully test and debug the application under the retail version of the product. When you are fairly confident that you have all of the kinks worked out of the application, you are ready to test it within the runtime environment.

Run and Test the Application with the /Runtime Command Line Switch

Microsoft provides you with a very easy way to test an application to see how it will perform under the runtime version of Access, without having to actually create distribution disks. This can be accomplished using the /Runtime command line switch. The /Runtime switch forces Access to load in runtime mode. Here's how it works:

c:\msoffice\access\msaccess.exe c:\clients\sams\master~1\_

databases\chap35.mdb /runtime

After you load the application with the /Runtime switch, you should once again test all aspects of the application. At times, you might want to test to see whether the application has been launched with the runtime or retail version of the product. You can accomplish this with the following code:

If Not SysCmd(acSysCmdRuntime) _

      And CurrentUser <> "Admin" Then

      MsgBox "You aren't allowed here"

End If

The SysCmd function, when passed the constant acSysCmdRuntime, checks to see whether the application was launched using the runtime version of Access. In this case, if the program was run with the retail version of Access and the CurrentUser is not Admin, a message is displayed indicating that the user is not allowed. Of course, this routine could easily be modified to check for other users and to quit the application if an unauthorized person attempts to launch the application without the runtime version of the product.

Run the Setup Wizard

When you have fully tested and prepared your application for distribution, you are ready to run the Setup Wizard. The Setup Wizard walks you through all of the steps required to build distribution disks that include all of the components your application needs to run. The Setup Wizard can be launched from the Windows 95 Start menu or by using a desktop shortcut. When you launch the Setup Wizard, the Setup Wizard Welcome dialog appears (see Figure 35.14).

Introductory Screen

The Setup Wizard Welcome dialog gives you the opportunity to create a new set of setup options or use a previously saved set of options. Using a previously saved set of options is covered later in this section. If you select "Create a new set of setup options for my application's custom Setup program" and click Next, the next step of the Setup Wizard appears.

Figure 35.14. The Setup Wizard Welcome dialog.

Adding Files To Be Included on the Distribution Disks

The second step of the Setup Wizard enables you to specify files that you want to add to the setup disks (see Figure 35.15). The types of files you will add from this dialog include the following:

Figure 35.15. Adding files to the setup disks.

Follow these steps to add a file:

  1. Click Add. The Select Files dialog appears.

  2. Locate the file you want to add and click Add. After you add several files, the Set Wizard dialog looks like the one in Figure 35.16.

  3. Set the options for each file included on the distribution disks. Table 35.3 shows each option included on this step of the Setup Wizard and describes the purpose of each option.

  4. When you are done setting the options for all of the files, click Next.

Figure 35.16. The Setup Wizard dialog after adding several files.



File Name and Path

Specifies the location and path of the component being included.

Destination Folder

Specifies where the file will be placed when the Setup program is executed. The options are $(AppPath), $(AppPath)\subfolder, $(WinPath), or $(WinSysPath). These specify the application path, a subpath to the application path, the Windows folder, and Windows System folder respectively.

Overwrite Existing File

This option applies when the user has previously installed a copy of your application. It is used to indicate whether the new file only overwrites an existing file if the existing file is older, always overwrites the existing file, or never overwrites the file.

Compress File

Indicates whether or not the selected file should be compressed on the Setup disks.

Include File on First Disk

This option enables you to designate that the selected file will always be found on the first Setup disk.

Set as Application's Main File

This option is used to indicate that the selected file is your application database.

Set as Workgroup File

When distributing a .MDW file, this option is used to designate the file as the system workgroup file.

Component Name

By default, all files belong to the Application component. You can define custom components and specify when and how those components will be installed (see the "Adding Components" section of this chapter).

Adding Components

By default, the only type of component is Application; anything that is an Application component is defined to install under Typical, Compact, and Custom installations. By defining additional components, you can categorize Application components and set their properties as a group. For example, you can create a component called HelpFiles and install anything with a Component Name of HelpFiles only under Typical and Custom installations (see Figure 35.17). When you have defined components, you assign to a specific component category each file that you are including with your application.

Figure 35.17. Creating component categories.

Defining Shortcuts

The third dialog of the Setup Wizard enables you to define desktop shortcuts that your application will create. Figure 35.18 shows the Shortcut step of the Setup Wizard. You generally should establish shortcuts for your application and possibly for the compact and repair processes. The properties included in the dialog are explained in Table 35.4.

Figure 35.18. Defining shortcuts.




Specifies the text that appears for the desktop shortcut.

File to Open

Specifies the file that the shortcut opens.

Command-Line Style

Determines whether you want the wizard to build the command line or you want to type your own command line.

Command Line

The command line that runs when the user selects the shortcut.

Icon File

Used to select the icon that appears on the desktop.

Component Name

Allows you to select within which component category the shortcut is included.

Database Shortcut

Determines what you want the shortcut

Action Options

to do.

Database Command-Line Options

Specifies how you want the application to work. For example, selecting the Workgroup option causes the application to run with a custom .MDW (workgroup information file).

Adding Registry Values

The next step of the Setup Wizard enables you to add Registry values when your application is installed. You can add Registry values for anything that you would like. For example, a predefined Registry value used by an application is the AppHelpFile key. Using the AppHelpFile key, you can specify a Help file that you want your application to use. Figure 35.19 illustrates the process of defining a Registry entry.

Figure 35.19. Defining a Registry entry.

Designating Access Components

The next step of the Setup Wizard enables you to designate Access components that you want to include with your application (see Figure 35.20). It is imperative that you select all ISAM drivers and other runtime components that your application requires to run. Otherwise, your application won't run properly.

Figure 35.20. How to include needed runtime components.

Reordering Components and Setting Their Properties

The next step of the Setup Wizard enables you to reorder the various components of the application and set their properties (see Figure 35.21). All custom categories have the properties that you defined when you added the component. You can override those properties here.

Figure 35.21. Reordering components and setting their properties.

Setting Key Attributes of the Application

The next step in the Setup Wizard enables you to specify some key attributes of your application (see Figure 35.22). These attributes include the name of the application, the version number, the name of your company, and the suggested folder for the installation.

Figure 35.22. Specifying key attributes of the application.

Specifying For a Program To Execute After Setup is Completed

The next step in the Setup Wizard enables you to designate the name of an executable that will run after the Setup program is complete (see Figure 35.23). This can be used, for example, to run Notepad.exe and load a designated Read.Me file.

Figure 35.23. Specifying a program that will execute after setup is completed.

Specifying a Location for the Setup Files

Finally, you can determine where the installation files will be located when the wizard creates them (see Figure 35.24). It is a good idea to create a Network setup from which your users can install the application. You can also specify whether or not the files will be compressed on the network server.

Figure 35.24. Telling the setup wizard where to store its output files.

Always save the Setup template when prompted (see Figure 35.25). This ensures that if the Setup process does not complete successfully or if you need to rerun the Setup process at a later time, you won't have to redefine all of the options.

Figure 35.25. Saving the setup options as a template.

Package and Distribute the Application

The most important thing that you must do when packaging and distributing your application is to test the application on a machine that has never had a copy of either Access or any Access runtime application installed. This ensures that your application includes all required components. I like to keep a "virgin" machine available especially for testing my application setups. Here's what I do:

  1. Back up the Windows and Windows\System folders on the machine.

  2. Install my application.

  3. Test my application.

  4. Delete my application.

  5. Delete everything in the Windows\System folder.

  6. Restore the Windows System folder from backup.

By following these steps, I ensure that I always have a "clean" machine on which to test my application. Obviously, it is imperative that you test all aspects of your application on the machine on which you performed the installation from your Setup disks.

When you are ready to test the Setup process, follow these steps:

  1. Select Run from the Windows 95 Start menu.

  2. Locate the Setup files that the Setup Wizard created (see Figure 35.26).

Figure 35.26. Selecting Run from the Start menu.

  1. Click OK. The Application Setup dialog appears (see Figure 35.27).

Figure 35.27. The Application Setup Welcome dialog.

  1. Click Continue.

  2. Select a location for the application installation (see Figure 35.28).

Figure 35.28. Selecting a location for the program installation.

  1. Click OK.

  2. Select the type of installation that you want: Typical, Compact, or Custom (see Figure 35.29). If you select Typical or Compact, you are asked no further questions and the installation process proceeds. If you select Custom, the Application: Custom dialog appears, allowing you to select the components that you want to install (see Figure 35.30).

  3. Allow the setup routine to run and make sure that everything works as you anticipate.

Figure 35.29. Selecting a Typical, Compact, or Custom installation.

Figure 35.30. Custom installation.

The installation process is completed. If you opted during the Setup Wizard to create desktop shortcuts, they are automatically created when the Setup program is executed.

Other Issues

Two additional issues have not yet been covered regarding the distribution of your application. The first issue involves ensuring that the application database can establish any links that it has to external tables. The second involves the prospect of using Replication to effectively distribute changes to or within your application.

Automating the Process of Linking to Tables

Access hard-codes locations for Table Links. This means that if you install your application on another machine, unless the other machine has exactly the same folder structure as you do on your machine, the tables will not link successfully. The following code checks to see whether the required tables are available. If they are not found in the expected location, the routine attempts to locate them in the same folder as the application database. If they still cannot be found, the user is given an opportunity to locate the files. If they still cannot be found, the application terminates. The code looks like this:

Function AreTablesAttached(frmAny As Form) As Boolean

    'Update connection information in linked tables.

    'Set up required constants

    Const MAXTABLES = 8

    Const NONEXISTENT_TABLE = 3011

    Const DB_NOT_FOUND = 3024

    Const ACCESS_DENIED = 3051

    Const READ_ONLY_DATABASE = 3027

    'Declare required variables

    Dim intTableCount As Integer

    Dim strFilename As String

    Dim vntReturnValue As Variant

    Dim tdf As TableDef

    Dim db As DATABASE

    Dim rst As Recordset

    Dim strAppDir As String

    'Point Database object variable at the current database

    Set db = CurrentDb

    'Set default return value of True

    AreTablesAttached = True

    ' Continue if links are broken.

    On Error Resume Next

    'Open one linked table to see if connection

    'information is correct.

    Set rst = db.OpenRecordset("tblClients")

    'Exit if connection information is correct.

    If Err.Number = 0 Then


      Exit Function


      'Otherwise, determine location of current database

      strAppDir = Left(db.Name, LastOccurrence(db.Name, "\"))

      'Try to establish the connection searching for the linked

      'tables in the same folder as the application database

      If TryAgain(strAppDir) Then


         Exit Function

      End If

      'If connection still cannot be established, continue

      'Warn the user

      MsgBox "You Must Locate the Data Tables"

      'Set the DialogTitle property of the Common dialog control

      frmAny!dlgCommon.DialogTitle = "Please Locate Data File"

      'Invoke the File Open common dialog


      'Store the name and location the user selected

      strFilename = frmAny!dlgCommon.filename

    End If

    'If the user did not select a file, bail out

    If strFilename = "" Then

        GoTo Exit_Failed ' User pressed Cancel.

    End If

    'Initialize progress meter.

    vntReturnValue = SysCmd(SYSCMD_INITMETER, "Attaching tables", MAXTABLES)

    ' Loop through all tables, relinking those with 

    ' nonzero-length Connect strings.

    intTableCount = 1  ' Initialize TableCount for status meter.

    For Each tdf In db.TableDefs

        If tdf.Connect <> "" Then

            tdf.Connect = ";DATABASE=" & strFilename

            Err.Number = 0


            If Err.Number <> 0 Then

               If Err.Number = NONEXISTENT_TABLE Then

                  MsgBox "File '" & strFilename & _

                     "' does not contain required table '" & _

                     tdf.SourceTableName & "'", 16, "Can't Run This App"

               ElseIf Err.Number = DB_NOT_FOUND Then

                  MsgBox "You can't run Time and Billing App " & vbCrLf & _

                     "Until you locate Data File", 16, "Can't Run Application"

               ElseIf Err.Number = ACCESS_DENIED Then

                  MsgBox "Couldn't open " & strFilename & _

                     " because it is read-only or it is located " & _

                     "on a read-only share.", 16, "Can't Run This App"

               ElseIf Err.Number = READ_ONLY_DATABASE Then

                  MsgBox "Can't reattach tables because Data File " & _

                     "is read-only or is located on a read-only share.", _

                     16, "Can't Run This App"


                  MsgBox Error, 16, "Can't Run This App"

               End If

               AreTablesAttached = False

               GoTo Exit_Final

            End If

            intTableCount = intTableCount + 1

            vntReturnValue = SysCmd(SYSCMD_UPDATEMETER, intTableCount)

        End If

    Next tdf

    GoTo Exit_Final


    MsgBox "You can't run this example until " & _

      "you locate Data File", 16, "Can't Run This Example"

    AreTablesAttached = False


    vntReturnValue = SysCmd(SYSCMD_REMOVEMETER)

End Function

The routine begins by declaring several required constants and variables. It then points a database object variable to the current database. It establishes a default return value of True and then uses the On Error Resume Next statement to instruct Access to resume on the next line if an error occurs. Next, the routine attempts to base a recordset on the tblClients table. If no error occurs, you know that the link was successfully established and you can exit the function. Otherwise, the routine uses the LastOccurrence function (found immediately after this explanation), along with the VBA Left function to locate the folder where the application database resides. It uses the TryAgain function (also found later in this section) to attempt to link to the files, looking in the same location for the data database as the application database. If the tables still cannot be successfully linked, the user is prompted for the location of the data tables. If the user cancels or if the routine is still unsuccessful at locating the tables, a value of False is returned from the function.

The LastOccurrence routine receives two parameters: the string you want to search and the string you want to search for. It proceeds to find the last occurrence of the string you want to search for in the string you are searching. For your purposes, you want to search the db.Name string (the name and location of the current database) for the last backslash. By doing this and then looking at everything before the last backslash, you can obtain the path in which the application database is located.

Function LastOccurrence(strSearchString As String, _

            strLastOccurrence As String) As Integer

    Dim intVal As Integer, intLastPos As Integer

    'Find the first occurrence of the specified character

    intVal = InStr(strSearchString, strLastOccurrence)

    'Find each next occurrence of the specified character

    Do Until intVal = 0

        'Keep track of the last position found

        intLastPos = intVal

        intVal = InStr(intLastPos + 1, strSearchString, strLastOccurrence)


    'Return the last position found

    LastOccurrence = intLastPos

End Function

The TryAgain function uses the strAppDir variable, which contains the path that the application database is running in, to once again attempt to locate the linked tables. If it is successful, it returns True. Otherwise, it returns False.

Function TryAgain(strAppDir As String)

    'Invoke Error Handling

    On Error GoTo TryAgain_Err

    'Declare Required Variables and Constants

    Dim db As DATABASE

    Dim tdf As TableDef

    Dim vntReturnValue As Variant

    Dim intTableCount As Integer

    Const MAXTABLES = 8

    'Initialize Progress Meter

    vntReturnValue = SysCmd(SYSCMD_INITMETER, "Attaching tables", MAXTABLES)

    'Point to the current database

    Set db = CurrentDb

    intTableCount = 1

    'Set default return value of True

    TryAgain = True

    'Loop through each table in the database

    For Each tdf In db.TableDefs

        'If the connection string is bad, attempt to locate

        'the data tables in the same folder as the application


        If tdf.Connect <> "" Then

            tdf.Connect = ";DATABASE=" & strAppDir & "CHAP19DATA.MDB"


            'Update Progress Meter

            intTableCount = intTableCount + 1

            vntReturnValue = SysCmd(SYSCMD_UPDATEMETER, intTableCount)

        End If

    Next tdf


    Set db = Nothing

    Set tdf = Nothing

    vntReturnValue = SysCmd(SYSCMD_REMOVEMETER)

    Exit Function


    TryAgain = False

    Resume TryAgain_Exit

End Function

Using Replication to Efficiently Distribute Your Application

You might not want to rebuild and redistribute Setup disks each time you change the design of your application database. Not only is this time-consuming, it is difficult to ensure that each user runs the Setup process in order to obtain the application database. If your organization is networked, it is generally much more effective to distribute application updates using Replication. This involves making design changes to the Design Master and then synchronizing with a hub once the changes have been completed and properly tested. Replication is covered in detail in Chapter 23, "Replication Made Easy."

Practical Examples: Distributing the Time and Billing Application

The completed Time and Billing application, found on your sample code CD as CHAP35.MDB, has been modified to prepare it for distribution. Switchboards have been added to assist the user with the process of navigating in the application. Error handling has been built into most of the application's routines. Custom toolbars and menu bars have been added to the application's forms and reports. Startup options have been set. The application has been fully tested under the runtime version of the product. All that is left is to properly secure the application to meet the specific needs of your organization and to build the Setup disks.


The process of preparing an application for distribution actually starts in the planning of the application. It involves everything from providing a means by which the users of the application can navigate from task to task, to preparing the distribution disks. It also involves important steps such as properly securing the application to ensure that the integrity of its data and objects are maintained, and building in a solid error-handling routines to ensure that all errors are handled gracefully. Remember that whether your users will be running your application using the full or runtime version of Access, by using the techniques you learned in this chapter, you can add professional polish and pizzazz to any application.

Previous Page TOC Index Next Page Home