Distributing Applications with the Microsoft Access 95 Developer's Toolkit

by Dan Haught
Vice President of Product Development
http://www.fmsinc.com

Introduction

The Microsoft Access Developers Toolkit for Windows 95 is the latest version of Microsoft's collection of tools for Microsoft Access developers. It is designed to be used with Microsoft Access 95 and contains new tools and custom controls. The following topics are covered in this presentation:

What the Toolkit Contains
An Overview of the Setup Wizard
Developing Runtime Applications
Working with the Runtime Environment
What's Different About the Runtime Environment
Using the Setup Wizard to Create Your Custom Setup Program
Wrapping Up

Back to Main Technical Papers Page

What the Toolkit Contains

• While most people think of the ADT mostly in terms of its runtime license and setup capabilities, there are several components in the toolkit that add value to the overall package.
• The kit contains a royalty-free run-time distribution license. This allows you to distribute the Access components necessary to run your application to as many sites as you want.
• The Setup Wizard steps you through the process of creating a custom setup program that you can create distribution disks from. Your application's users can run this setup program to install your application on their systems. And, unlike generic installation tools, the Setup Wizard understands the components needed for an Access application. It is very complete, and quite automatic. For example, the setup program can update the Windows registry on your user's system, and register any OLE custom controls you need.
• If you are using Replication in Microsoft Access 95 or in Visual Basic 4, you will find the Replication Manager program included in the ADT to be a real boon. It provides you with a graphical interface to create and manage replicated databases.
• Several manuals are included: the Access Language Reference and the Data Access Reference for Office 95.
• Several OLE Custom Controls (OCX's) are included.
• There are tools for creating Help files, such as the help compiler and the new graphical Help Workshop for Windows 95.

An Overview of the Setup Wizard

Microsoft has substantially upgraded the Setup Wizard in this latest version of the ADT. If you have used the ADT in previous versions, you are familiar with the Setup Wizard's role as an easy-to-use program that steps you through the process of creating a custom setup program.

In a nutshell, you step through the pages of the wizard, filling in information about your application and how it is to be installed. After answering all the questions, the wizard creates disk images that contains compressed versions of the files necessary to run your application. You can then install your application from these disk images.

The Setup Wizard provides a great deal of flexibility in creating your custom setup program. According to the ADT Help File, the Setup Wizard can:

• Copy your application's files to specified locations on a user's hard disk. To save space, the files can be stored in a compressed format in the disk images, in which case the Setup program decompresses them automatically when the user installs your application.
• Create Windows shortcuts that start your application or peripheral files, and specify various options used to open or run the files.
• Add Windows Registry keys and entries for your application.
• Group files, shortcuts, and Registry keys and entries into components that users can select.
• Install the run-time version of Microsoft Access so that users won't need to have Microsoft Access previously installed in order to run your application.
• Install other Microsoft Access files, such as drivers for accessing various data sources.
• Run an application or open a file after the Setup program finishes installing your application.

Using Saved Settings

If you ever create more than one setup, you will be happy to know that the Setup Wizard allows you to save any number of setup "configurations". You can use these at a later time without having to re-specify all the options and answer all the questions again.

You can also use this functionality to create a single "template" that you use often, and save different versions that correspond to differing setup needs you may have.

Creating Setup Programs with Single or Multiple Components

You have probably notice that when you install most software nowadays, you get one or more options that define how much of the software is to be installed. For Microsoft software, such as Microsoft Access or Microsoft Word, you can specify a "typical" or a "custom" setup. The typical setup copies the most common components to your system, while the custom setup allows you to tell the setup program exactly which components you want to install.

The Setup Wizard allows you to use the same sophistication in your setup programs. You can create custom setup programs that allow Single or Multiple components. When you specify a Single component, the user running the setup program is not give the choice as to which components to install. It is all or nothing. However, with a Multiple component installation, you can control options that the user can select or de-select for installation.

Developing Runtime Applications

Before you start work on creating your custom setup program, you want to be sure that the Access application you designed works correctly within the Runtime Environment. This section describes common tricks and techniques for accomplishing this.

Steps in the Development Process

When you develop an application that will be used in the runtime environment, there are several factors you must remember. The runtime environment behaves differently is some cases, and your application must handle these differences. Typically, you develop your application as you would any other Access application. The key thing to be aware of is how the runtime environment differs from standard Access.

The basic steps for creating a runtime application are:

• Create your application objects (tables, queries, forms, reports, macros, modules, menus and toolbars) using a standard installation of Microsoft Access. This allows you to use all the development and debugging tools available in Access.
• Fully test and debug your application using a standard installation of Microsoft Access.
• If your application needs security, use the Security Wizard in Microsoft Access
• If your application needs on-line documentation such as help files, create them using the Help tools included in the ADT (or any other help-authoring tools)
• Test and debug your application under the runtime environment using the /Runtime command line option for MSACCESS.EXE.
• Use the Setup Wizard to create your applications custom setup program and distribution media (typically diskettes)

Forms: The Backbone of Runtime Applications

When you are working with a standard installation of Microsoft Access, you can view tables, edit code, modify forms, write queries and more. This is possible because the standard installation of Access provides design tools to make these tasks easy. However, in the runtime environment, all of the interactive tools and design tools are disabled. This means that your application's users will not be able to create objects, or work with objects in an interactive mode.

Because of this, it is important to realize that Access forms make up a large part of the user-interface of your application. If you don't provide a form to allow a user to accomplish a specific task, the user will not be able to use your application. As such, you should design your application with as many forms as are necessary to allow the user to accomplish all the necessary tasks.

Error-Handling: Why You (Really!) Need it

If your application is running under a standard installation of Microsoft Access and an error occurs, the user remains in Access, and has the opportunity to try and resolve the error. However, in the runtime environment, Microsoft Access automatically closes the database if an untrapped error occurs. Because of this, it is very important to have some form of error handling in your application.

Which brings us to the topic of macros. You should not use macros in your application if it going to be used in a runtime environment. (In fact, it could be argued that macros should never be used except for creating menus-more on that in a moment). This is because macros provide no mechanism for error handling. Under a standard installation of Microsoft Access, and error that occurs while a macro is executing cannot be trapped or handled. And in the runtime environment it gets worse: Microsoft Access does not even display the error message. Your application simply disappears when Access unloads the database in response to the error.

So the bottom line is: if you are developing applications that are to be used in the runtime environment, you must replace your macros (if any) with Visual Basic code. Using Visual Basic, you can anticipate, trap and handle error messages with useful prompts and error-recovery routines.

Testing Under the Runtime Environment

One of the application developments steps given previously in this paper is to test your application under the runtime environment. Unlike Access 1.x and Access 2.0, the runtime environment provided by the newest version of the ADT does not utilize a separate executable. In other words, the MSARN...EXE program is a thing of the past. Now, the same MSACCESS.EXE program file is used.

To ensure that your application works in the runtime environment, you must test it running in the runtime environment. You do this by starting Access with the /Runtime command-line option, as in:

C:\MSOFFICE\ACCESS\MSACCESS.EXE /RUNTIME

Doing this forces Access to startup in Runtime "mode" which, for all intents and purposes, is the same thing as running under the runtime environment.

Working with the Runtime Environment

The Runtime Licensing Key and Microsoft Access

After you use the Setup Wizard to create a custom setup program, you end up with a set of disks that can be installed on a user's machine. One of the files that is included on these disks is the very same MSACCESS.EXE that is on your machine. When your application is installed on the user's machine, it copies the MSACCESS.EXE file, and updates the user's Windows registry with an entry in the software licensing section. This entry is in the form of a set of numbers and letters known as the license key.

When the MSACCESS.EXE program is started, it searches the registry to see what keys are available. On your machine (which supposedly has a full copy of Microsoft Access installed), the program sees a full license key and allows you to run Access with restrictions. However, on your user's machine, only the runtime license key will be found, and MSACCESS.EXE will automatically start in runtime mode.

The setup program on your application's distribution disks automatically handles writing the appropriate keys to the registry and installing the necessary files.

Note that if no licensing key is present in the Windows registry, the run-time application will not start.

Microsoft Access Runtime Option Settings

As with previous versions of the Access runtime component, there are various options that you can specify to control how your runtime application works. However, unlike previous version, you no longer deal with text INI files to control options. As with all other options and settings in Windows 95 compliant software, the system registry is now used.

The following text from the ADT Help File shows how to create runtime option settings:

• Create a user profile. You can create a user profile by using the Setup Wizard, or by directly modifying keys in the Windows Registry.
• Under your user profile key, create a key called Run-Time Options.
• Under the Run-Time Options key, you can create keys to specify the following settings for your application:

Using Runtime Applications on Workstations that already have Microsoft Access Installed

Your runtime application may be installed on a workstation that already has Microsoft Access installed. Fortunately, the custom setup program you created with the Setup Wizard can detect and handle this situation without any intervention on your part.

However, if your application must be secure against a user opening it with a standard installation of Microsoft Access, you must plan ahead and structure your application accordingly. The following techniques allow you to accomplish this:

• In every command line option that can be used to start your application, specify the /Runtime command-line argument to force Access into runtime mode.
• As mentioned earlier, you can use Access security to prevent users from opening objects that they don't have permissions for.
• Access 95 has the new AllowBypassKey property. Set this property to False to disable the use of the SHIFT key to bypass the Autoexec macro.

Getting the Access Version Number and Checking for the Runtime Environment

There are several options to the built-in SysCmd function that can be useful in runtime applications. You can check both the version of Microsoft Access running, and determine if the runtime environment is active. The following two Visual Basic procedures illustrate this:

Function fIsRuntime() As Boolean
' Check if this application is using the run-time environment.
fIsRuntime = SysCmd(acSysCmdRuntime)
End Function
Function strGetVersion() As String
' Determine the version of Microsoft Access
' used to create this application.
strGetVersion = SysCmd(acSysCmdAccessVer)
End Function

What's Different About the Runtime Environment

As mentioned earlier, the runtime environment behaves differently from a standard installation of Microsoft Access. The key difference is that the design surfaces are disabled. This means that you cannot create of modify object definitions using Design mode as you can in standard Access. It is important to note that design tools are still available programmatically-that is, any Visual Basic code in your application that opens objects in design view and makes changes will still work. The point here is that the design view is not visible to the user.

The basic differences between the Runtime environment and standard Access are listed in the following sections.

Some Windows are Hidden

Because the runtime environment does not allow the user to create or change object definitions, it hides the design windows for tables, queries, forms, reports, macros and modules. Additionally, the Database window is hidden.

Additionally, the Filter by Form, Filter by Selection and Advanced Filter windows are hidden. As mentioned earlier, these windows are really "there", but are hidden from appearing on the screen.

It is important to note that the Database window is hidden by settings its colors to the same colors as the Windows background color. So even though it does not appear, your application can still interact with it if necessary.

Issues with Keystrokes

There are several keystrokes in standard Microsoft Access that you would not want to be available in your runtime application. These are disabled automatically by the runtime environment:

Some Menu Items are Hidden

Because the default menu system in Microsoft Access allows you to make changes to object designs, some of the menu choices are disabled in the runtime environment to prevent unwanted changes to your application. The following table shows which menu items are hidden:

Note that even those commands do not appear on the menus in the runtime environment, your application can still use them through the DoMenuItem command just as in standard Access.

Issues with Toolbars

As with menu items, there are toolbar buttons built into Microsoft Access that could allow your application to be modified by the user. To prevent this, the runtime environment disables all built-in Access toolbars.

You can still create your own custom toolbars to provide your application with any needed operations. Remember that the run-time environment automatically starts with toolbars turned off. If your application uses custom toolbars, you must turn toolbars on.

Using the Setup Wizard to Create Your Custom Setup Program

Now that you have created and tested your application, it is time to create your custom setup program. This is accomplished by using the Setup Wizard that comes with the ADT. This wizard guides you through the process of describing the components your application needs and how it is to be installed, and creating the actual disks for distribution.

To Start the Setup Wizard

Under Windows 95, Select [Start] [Programs] [ADT] [Setup Wizard]. In the Windows NT Program Manager, open the Microsoft ADT program group, and then double-click the Setup Wizard icon.

Filling in the Blanks - A Page by Page Tour

The following section steps through the Setup Wizard page by page, explaining each of the available options:

Page 1 - The Welcome Screen

This page displays introductory text and allows you to create a new custom setup program, or load a template (an existing set of information you previously saved). Select the option you want and press the [Next] button.

Page 2 - The Add Files Screen

One of the most important pieces of information the Setup Wizard needs is a list of files that are needed by your application. This is handled by the Add Files screen. Press the [Add] button to add new files. Use the File dialog to browse through your file system to find the correct files.

After selecting a file, you can set various properties that control how the file is to be included in the distribution set, where it is to be installed on the users machine and several other options:

One important thing to note here is that the Destination Folder text box has a strange looking entry called $(AppPath). This entry tells the setup program to put the file in the directory specified by the user for installation. Using this, you can avoid hard-coding destination paths into your setup program, allowing the user to specify the destination for your application's files. You can also use other special tags, as illustrated in the following table:

For complete information on all the options and their uses, click the [Help] button on this page.

Page 3 - The Shortcuts Page

Use this page to define any shortcuts that you want your setup program to create on the user's machine. These shortcuts can include opening your application's database, a help file, or repairing and/or compacting databases. The following form shows the available options:

For complete information on all the shortcut options and their uses, click the [Help] button on this page.

Page 4 - The Registry Values Form

If you have used Access 95, you are probably aware that it does not use INI files like the previous versions. Instead, it stores all of its configuration and option information in the Windows Registry. The Setup Wizard takes care of updating the Windows Registry with all the necessary keys to start your application in the Runtime Environment. However, your application may have special needs that require the ability to update the Windows Registry on the user's machine with keys of your choice. Use this form to specify registry entries to be installed on the user's machine.

The following form shows the options available for registry settings:

Page 5 - Specifying Microsoft Access Components

Microsoft Access has several components that are not part of the core MSACCESS.EXE program file. These include the drivers to read non-Access data, Replication support files, the Workgroup Administrator program, and the Microsoft Graph runtime files.

Use this page to specify which components your application needs. You should only specify the components that your application needs, as unnecessary choices will increase the number of disks you must distribute.

The following form shows the available components:

Page 6 - Organizing Components

As mentioned earlier, a new feature in the 95 version of the ADT is the capability to create several Setup options. You can create a setup program that gives the user the option of:

• a Typical installation
• a Compact installation
• a Full installation

You use this form to specify which of the components are to be included in each of these installation types.

Page 7 - Miscellaneous Information

This form allows you to specify information such as your application's name and version, and the default installation paths. The following form shows the available options:

Note that the installation path options allow you to specify different defaults for systems that support long files names and systems that only support 8.3 naming.

Page 8 - Running a Program After Setup

There may be cases where you want your custom setup program to run an external program after it is complete. For example, you may want to display a README file containing late-breaking information. You can use this page to specify the program to run and several options for controlling how the setup program interacts with that program. The following form shows the available options:

Page 9 - Describing the Disk Images

Now that you have described your application and the files it needs, you tell the Setup Wizard how you want to create the disk images. Remember that disk images are directories on your hard disk that contain the contents to be copied to disks for distribution.

The following form shows the available options:

Finishing Up - Creating the Disk Images

When you press [Finish] from the last page, you are give the opportunity to save your settings. This is highly recommended because if something goes wrong while creating the disk images, you may have to re-enter all the necessary information. By saving your settings, you can avoid this problem.

After saving your settings, the Setup Wizard begins building the disk images. A status form appears showing you the progress of this operation. Note that the compression program used by the Setup Wizard is not known for its blazing speed. Depending on the size and number of files that need to be compressed, this can take a while.

Testing Your Custom Setup Program

You should test both the installation of your application, and the application itself before distributing it to users. Be sure to test the installation on a workstation that doesn't have Microsoft Access installed. This will allow you to ensure that all the necessary component are installed.

You may also want to test the installation on a workstation that has a full copy of Microsoft Access installed to ensure that your custom setup program does not interfere with the operation of the existing copy of Microsoft Access.

Files That You Can Redistribute with Your Runtime Application

There are files that you can distribute with your run-time applications and files that you cannot. See the ADT documentation for complete information.

Wrapping Up

The Access 95 Developers Toolkit contains far more functionality than can be covered in a brief presentation. Hopefully, you now have a basic understanding of what the ADT can do for you. You are encouraged to read the documentation included with the product (and the online help files) to get the complete picture.

Back to Main Technical Papers Page

Copyright © 1998, FMS Inc. All rights reserved. This information may not be republished, reprinted or retransmitted in any form without the express written permission of FMS Inc. The information provided in this document is provided "as is" without warranty of any kind.