MOD2000: How to Avoid Common Mistakes When You Create Distributable Run-Time Applications

This article was previously published under Q247530
This article has been archived. It is offered "as is" and will no longer be updated.
For a Microsoft Office 97 Developer Edition version of this article, see 180284.
For a Microsoft Office XP Developer version of this article, see 304007.
The process of creating a distributed run-time application is explainedstep-by-step in Chapter 2 of "Microsoft Office 2000/Visual Basic Programmer's Guide" Help topic (clickthe Contents tab in Microsoft Office 2000 Developer Edition Tools Help, andthen click to expand the MSDN Library - Office 2000 Developer, Office 2000 Developer Topics topic). This article lists available resources and troubleshooting steps that you should use to avoid making common mistakes when you create a custom application.

Things to Consider When You Create and Distribute a Run-Time Application

When you create and distribute the run-time application, consider thefollowing questions:
  • How was the application created?
  • Was the application tested and debugged?
  • Were Help files and topic files created?
  • Was the application tested in the run-time environment?
  • Were disk images created by using the Package and Deployment Wizard?
  • Was the application packaged and distributed?
The following sections contain more information about these questions.

How Was the Application Created?

Before you can consider the application finished, answer the followingquestions:
  • Did you develop a plan?
  • Did you build the application around forms?
  • Did you include error handling?
  • Did you create custom menu bars and toolbars?
  • Did you add startup options?
  • If security is required, did you properly secure the application?

Did You Develop a Plan?

The first step in the process is to develop a design for the application.Make sure you have answered to the following questions:
  • Was the application secured? If so, how?
  • Was the database split? If so, how?
  • Will the application be run from a network? If so, how?
  • What is the best way to update the application after it is distributed?

Did You Build the Application Around Forms?

In general, it's a good idea to build your application around forms. Usersshould interact with the application through the forms that you createinstead of through the underlying queries or tables. By building your application around forms, you can control the following:
  • The commands that are available to users.
  • The flow of the application.
  • The appearance and behavior of the application.
  • The way that users access data.
  • The way that data is displayed.
For more information about using forms in the application, see Chapter 5 of the "Microsoft Office 2000/Visual Basic Programmer's Guide" Help topic (click the Contents tab in Microsoft Office 2000 Developer Edition Help, and then click to expand the MSDN Library - Office 2000 Developer, Office 2000 Developer Topics topic). Expand the tree of Chapter 5 in Help to find the topic Working With Forms, Reports and Data Access Pages.

For more information about form features that you cannot include in yourcustom application, please see the following article in the MicrosoftKnowledge Base:
262094MOD2000: Filter-by-Form Is Not Available in Run-Time Applications

Did You Include Error Handling?

It's important to include error-handling code in the application's VisualBasic for Applications procedures. When Microsoft Access encounters VisualBasic run-time errors that are not handled, it closes the applicationwithout displaying any error messages.

Microsoft Access also closes the application without displaying any errormessages if it encounters any run-time errors in the application's macros.However, you cannot trap errors in macros. If you want to ensure that yourapplication traps run-time errors, use Visual Basic procedures instead ofmacros.

NOTE: Avoid using the End statement in the run-time application. The End statement closes the application without producing a trappable run-time error.

For more information about implementing error handling and handling run-time errors in the application, see Chapter 8 - Error Handling And Debugging of "Microsoft Office 2000/Visual Basic Programmer's Guide" Help topic (click the Contents tab in Microsoft Office 2000 Developer Help, and then click to expand the MSDN Library - Office 2000 Developer, Office 2000 Developer Topics topic). Expand the tree of Chapter 8 in Help to find the topic Handling Errors.

Did You Create Custom Menu Bars and Toolbars?

To prevent users from making changes to the application, the run-timeenvironment removes several menus and commands from the menu bar. Forexample, the View, Tools, and Format menus are removed from all windows. Commands on the Edit, Insert, and Records menus are also removed from themenu bars in Datasheet view of tables and queries, in Form view, andin print preview.

You must control the menus and commands that are available to users of theapplication by building the application around forms that have custommenus. The run-time environment disables all built-in Microsoft Accesstoolbars. However, even though the run-time environment does not supportbuilt-in toolbars, you can add your own custom toolbars to the application.When you create a custom toolbar, it is stored in the current database. Itis automatically available to the application.

For more information about creating custom menu bars and toolbars, pleasesee the following article in the Microsoft Knowledge Base:
209974ACC2000: How to Create Command Bars by Using Visual Basic Code

Did You Add Startup Options?

You can set the following startup options for the custom application:
  • Application title
  • Application icon
  • Name of Custom menu bar
  • Name of startup form

If Security Is Required, Did You Properly Secure the Application?

When you distribute the run-time application to users who have MicrosoftAccess 2000 on their computers, you should take several precautions toprotect the database. To prevent users from making modifications to theobjects and code, or from inadvertently causing problems with theapplication, consider these recommendations:
  • Specify the /runtime option on all command lines that you use to start the application.
  • Use the Security Wizard that is provided with Microsoft Access to secure all the objects in the database.
  • Use customized menus and toolbars in the application.
  • Set the AllowBypassKey property to False to disable the SHIFT key.
  • Set any database startup properties that could potentially give users access to the Database window or any Design view.
  • If the database contains Visual Basic code, distribute it as an MDE file.
For more information about securing your Access application, see Chapter 18 - Securing Access Databases of Microsoft Office 2000/Visual Basic Programmer's Guide Help topic (click the Contents tab in Microsoft Office 2000 Developer Help, and then click to expand the MSDN Library - Office 2000 Developer, Office 2000 Developer Topics topic).

Was the Application Tested and Debugged?

When you program an application, you must consider what happens when anerror occurs. An error can occur in an application for either of tworeasons. The first reason is that some condition at the time theapplication is run causes the otherwise valid code to fail. For example, ifthe code attempts to open a table that the user has deleted, an erroroccurs. The second reason is that the code may contain improper logic thatprevents it from doing what you intended. For example, an error occurs ifthe code attempts to divide a value by zero.

If you have not implemented error handling, Visual Basic halts executionand displays an error message when an error occurs in the code. The user ofthe application is likely to be confused and frustrated when this happens.You can forestall many problems by including thorough error-handlingroutines in the code to handle any errors that may occur.

When you add error handling to a procedure, you should consider how theprocedure routes execution when an error occurs. The first step in routingexecution to an error handler is to enable an error handler by includingsome form of the On Error statement in the procedure. The On Error statement directs execution in event of an error. If there's no On Error statement, Visual Basic simply halts execution and displays an error message when an error occurs.

When an error occurs in a procedure that contains an enabled error handler,Visual Basic does not display the normal error message. Instead, it routesexecution to an error handler if one exists. When execution passes to anenabled error handler, that error handler becomes active. Within the activeerror handler, you can determine the type of error that has occurred andaddress it in a manner of your choosing. Microsoft Access provides twoobjects that contain information about errors that have occurred, theVisual Basic Err object and the DAO Error object.

Were Help Files and Topic Files Created?

Your application should use its own Help file rather than the fullMicrosoft Access Help file (Acmain90.hlp). If you want to provide Help foryour run-time application, you must create your own Help file, and then setthe AppHelpFile registry key. You can also provide topic IDsfor your Help file so that you can create context-sensitive help for yourtopics. Microsoft Office 2000 Developer Edition includes a Help Workshop toassist you in creating custom Help files.

For more information about setting the AppHelpFile registry key when you create your Setup files, please see the following article in the Microsoft Knowledge Base:
243051MOD2000: AppHelpFile Run-Time Option Does Not Work
For more information about creating your own Help files, please see thefollowing article in the Microsoft Knowledge Base:
202314MOD2000: How to Display Context-Sensitive Help for the What's This Button

Was the Application Tested in the Run-Time Environment?

You should always test and debug your application on a clean computer. Thiswill ensure that when you package your application you are including allthe files that you need to successfully run your application. To test yourapplication on a clean computer, follow these steps:
  1. Run your Setup program on a clean computer. This should be a computer that does not have any of the components that you are including with your custom application.
  2. Back up your Windows and Windows/System folders.
  3. Test your application.
  4. Delete the application.
  5. Delete everything in the Windows and Windows/System folders.
  6. Restore Windows and Windows/System folders from the backup.

Were Disk Images Created by Using the Package and Deployment Wizard?

When your custom application is complete and ready to distribute to users,you need a way for users to install it. Microsoft Office 2000 DeveloperEdition provides the Package And Deploy Wizard, which helps you create a custom Setup program for your application.

When you run the Package And Deploy Wizard, you answer questions about the files that you want to copy to users' hard disks, the Microsoft Access features that your application requires, and how the Setup program should customize the installation of your application. Then the Package and Deployment Wizard compresses your application files and groups them so you can copy them to a CD or to a network drive. If your users do not already have Microsoft Access installed on their computers, the Package And Deploy Wizard can create an installation that includes the run-time version of Microsoft Access.

The Package And Deploy Wizard compresses and groups files based on your choices and creates a custom template that the Setup program will use to install your application.

NOTE: If you choose Network Installation when you create your disk images, remember that the user must connect to the folder or directory in which the files are stored to run the Setup.exe file. This means that the folder must be shared. In a Windows NT or a Netware environment, the user must also have the necessary permissions to run the Setup program and copy files.

Was the Application Packaged and Distributed?

After your Setup program is complete, you're ready to distribute yourapplication. To install your application, users can simply run the Setupprogram file included on your CD or in your network installationfolder.

For more information about installing your custom application, please seethe following articles in the Microsoft Knowledge Base:
208792MOD2000: File compression Ratio Less Than Other Programs
241738MOD2000: Custom Installation of Access 2000 Run-Time Component May Overwrite Access 97 Default Installation
255516MOD2000: You Are Prompted to Restart and Update System Files Every Time That You Try to Run Setup on a Windows 2000-Based Computer
253662MOD2000: "An Error Occurred While Registering the File Msado21.tlb" Error Message When You Install Package
236534MOD2000: You Cannot Change Default "Start In" Setting for Shortcuts
240961MOD2000: Internet Explorer 5 Is Included in all Access Run-Time Installations
NOTE: If you want to modify your custom Setup program after running the Package and Deployment Wizard, or if you need to update files included in your application, run the Package and Deployment Wizard again. On the first page, choose the Setup script name that you saved in a previous Package And Deploy Wizard session.

Article ID: 247530 - Last Review: 11/02/2013 05:43:00 - Revision: 2.0

Microsoft Office 2000 Developer Edition

  • kbnosurvey kbarchive kbhowto KB247530