Alison Balteramp;#039;s Mastering Microsoft Office Access 1002003 [Electronic resources] نسخه متنی

Understanding the Access Runtime Engine

Many developers don't understand what Access has to offer out of the box, and what the Microsoft Office Developer (MOD) tools can add to the picture. They often tell me, "I can't develop applications in Access because my company refuses to buy each user a copy of Access," or "I'm going to buy the MOD so that I can compile my applications with the Access 2003 Developer Extensions." These are just two of the many misconceptions about exactly what the Access 2003 Developer Extensions do and don't have to offer.

Features of the MOD

You no longer need to buy a separate product to create runtime versions of your Access applications. As a developer, you will likely buy the Access 2003 Developer Extensions, which include Office Premium and all the features from the old Office Developer Environment (ODE), plus many new components. An important feature of the Access 2003 Developer Extensions is a royalty-free distribution license. It allows you to distribute unlimited copies of your Access application; your users don't have to own separately licensed copies of Access. By using the Access 2003 Developer Extensions, you can create applications and distribute them to your users, along with the necessary runtime engine.

Differences Between the Standard and Runtime Versions of Access

It's important to understand the differences between the standard and runtime versions of Access. The following differences have definite implications for the way you develop any applications you expect to run from the runtime version:

• The Database, Macro, and Module windows aren't available in the runtime environment.

• No Design views are available in the runtime environment.

• No built-in toolbars are available in the runtime environment.

• Many windows, menus, and commands are invisible in the runtime environment. For example, the Window, Hide and Window, Unhide commands are invisible. Although these and other commands aren't visible, their functions are generally accessible by using code.

• You must build error handling into your runtime applications. If you don't, when an error occurs, the application displays a standard Access dialog box indicating an irrecoverable error and then exits to the desktop.

• You must build your own custom help files for each runtime application.

• Some keystrokes aren't available in the runtime application.

Some of the disabled features protect your applications. For example, the absence of the Database and Design windows means that your users can't modify your application while running it under Access's runtime version. Other disabled features translate into additional coding chores for you, such as the absence of command bars. If you want your application to offer toolbars, you have to build your own and then assign them to the forms and reports in your database.

Steps for Preparing an Application for Distribution

With all the features absent from the runtime version of Access, it's not surprising you must take some special steps to prepare your application for distribution. Most are steps you'll probably want to take so that your application seems professional to the user. The following are preparations specific to running Access from the runtime version:

• Base your application around forms.

• Add startup options to your database.

• Secure the objects in your application.

• Build error handling into your application.

• Add some level of custom help.

• Build custom command bars to be associated with your application's forms and reports.

Basing Your Application Around Forms

You should base your application around forms. It should generally begin with a main switchboard that lets the user get to the other components of your application. Or, it can start with a core data-entry form around which you base the rest of the application. If you opt to go with an application switchboard, the main switchboard can direct the user to additional switchboards, such as a data-entry switchboard, a report switchboard, or a maintenance switchboard. You can build switchboards with an add-in called the Switchboard Manager. Alternatively, you can design them as custom dialog boxes. Chapter 9, "Advanced Form Techniques," covers building custom dialog boxes; Chapter 32, "Distributing Your Application," covers using the Switchboard Manager. The main advantage of using the Switchboard Manager is that it lets you quickly and easily create a polished application interface. The primary advantage of custom switchboards is the flexibility and freedom they offer.

An alternative to the switchboard approach is to build the application around a core data-entry form, such as a contact management application based around a contacts form. The user accesses all other forms and reports that make up the application via custom menu bars and toolbars on the contacts form.

Adding Start-Up Options to Your Database

Regardless of the approach that you take, you designate a form as the starting point for your application by modifying the database's startup options. Choose Tools, Startup to open the Startup dialog box (see Chapter 32 covers these options in detail.

Securing Your Application

As you will learn in the next section, a database isn't secure just because you're running it from a runtime version of Access. Without security, anyone with a full copy of Access can modify your application, so securing your database objects is an important step in preparing your application for distribution. Chapters 27, "Database Security Made Easy," and 28, "Advanced Security Techniques," both cover security.Chapter 32).

Building Error Handling into Your Application

If you don't build error handling into your application and an error occurs while your user runs your application from Access's runtime version, Access will rudely exit the user out of the program. She won't get an appropriate error message and will be left wondering what happened. Hence, it's essential that you add error handling to your application's procedures. Chapter 16, "Error Handling: Preparing for the Inevitable," covers error handling techniques. The VBA Error Handler, included with the MOD tools, can also assist in building error handling into your application.

Adding Custom Help

In most cases, you want your users to have at least some level of custom help specific to your application. You can use the ControlTip Text property of controls and the Description property of fields to add the most basic level of help to your application. The ControlTip Text property provides a description of a control when a user hovers his mouse pointer over the control. The Description property of a field appears on the status bar when a control based on that field has the focus. If you are more ambitious, and if the scope and budget for the application warrant it, you can build a custom help file for your application. To add custom help to your application, you must build a help file; then attach parts of it to the application's forms and controls. The HTML Help Workshop, included with the MOD tools, can assist with the process.

Building Custom Command Bars

Finally, because built-in toolbars aren't available in the runtime version of Access and the use of the runtime disables most of the features on the standard built-in menus, you should build your own command bars associated with specific forms and reports. Custom command bars add both polish and functionality to your application.

After you complete these steps, you'll be ready for the final phase of preparing your application for distribution:

Chapter 32). It lets you create setup disks or perform a network install. Selecting A:Setup (or the appropriate network drive and path) provides a professional-looking, familiar setup program similar to those included with most Microsoft products.

After you run the Package and Deployment Wizard, you must test your application by running the install on a machine that has never contained a copy of either the standard or runtime version of Access. The whole idea is to test your application on a machine containing no Access-related files. This ensures that you have included all the required files on your setup disks.

I suggest you use a "ghosting" utility such as Symantec Ghost to create a complete image of your operating system and application drives. Install and fully test your application; make sure you experiment with every feature. After you have completed the testing process, restore the original machine from the Ghost image so that you can use it to test your next installation

TIP

Symantec Ghost allows you to restore individual files, selected directories, or entire hard drives as needed. When you create a backup image file, Symantec Ghost compresses it by up to 70%, greatly reducing transfer times and storage requirements. Among its many other uses, Symantec Ghost greatly facilitates the testing process by allowing you to easily restore a test machine to its pre-testing state. Learn more about Symantec Ghost at http://enterprisesecurity.symantec.com/products/products.cfm?ProductID=3.

The Access Runtime Engine: Summing It Up




You have just read an overview of the differences between the full and runtime versions of Access. Chapter 32 details the process of preparing an application for distribution with the runtime version of Access. If you plan to distribute an application with the runtime version of Access, remember which features will be available to your users; otherwise, you and your users will be in for some big surprises.