When you use the "Package and Deployment" Wizard to create a run-time redistribution of your custom application, the application is not compiled into a single executable file. Instead, all of the files that Microsoft Access needs to run your database are included with your setup, and the Setup program creates a run-time version of your application by setting certain Windows registry keys.
The retail and run-time versions of Microsoft Access are identical in most
respects; in fact they both use the same executable file, Msaccess.exe.
However, there are some differences that you must consider when you develop
your run-time application.
Database Windows
The Database and Macro windows are not visible in a run-time
application. Filter By Form, Filter By Selection, and Advanced Filter
windows are also hidden. The windows exist, but the run-time environment
hides them. This means your application must be form-based. Users must interact with the forms that you create, and not with the underlying tables, queries, views, and stored procedures because users cannot see these objects.
Most run-time applications contain a main switchboard form, or menu, that
you set as the Startup form in your database or Microsoft Access project. The switchboard form is the central point in your application from which users open other forms, run reports, and make changes to data. Because the Database window is invisible in the run-time version, if you do not include a Startup form, users see only a blank screen with a menu at the top when they start your application.
Design View
The Microsoft Access run-time environment hides the Design views of
tables, queries, forms, views, stored procedures, and reports. If your application contains any buttons or toolbars that switch an object to Design view, these buttons do not work in a run-time environment.
NOTE: Hiding the Design views adds a measure of protection to your application design because it prevents users from viewing or modifying your objects.
Menus
The run-time environment removes several menus and commands from the menu
bar in Microsoft Access. For example, the
View,
Tools, and
Format menus are completely removed, and certain items are removed from the
Edit,
Insert, and
Records menus. This prevents users from making changes to your application design.
In most cases, you create custom menus for each form. These menus control
which menus and commands are available to users in the application.
Even though certain menus and commands are removed from the menu bar, you
can still use the
RunCommand method in your application to run commands that are on the hidden menus.
Toolbars
All of the built-in toolbars in Microsoft Access are disabled in a
run-time environment. You must create your own custom toolbars for your
application if you want to include them.
The run-time environment does not show and hide your custom toolbars as
the context changes, so you must manipulate the toolbars in your
application by using the
ShowToolbar method in the
OnActivate and
OnDeactivate properties of your forms and reports.
Unavailable Keys
Certain keys and key combinations are unavailable in the run-time
environment to prevent users from disrupting your application. The
following table summarizes keys that are unavailable:
Keys Description
--------------------------------------------------------------------
CTRL+BREAK Stops execution of code or macro
SHIFT Prevents execution of an AutoExec macro and bypasses
database Startup properties when opening a database
ALT+F1 (F11) Displays the Database window
ALT+F2 (F12) Displays the Save As dialog box
SHIFT+F12 Saves a database object
(ALT+SHIFT+F2)
CTRL+G Displays the Debug window
CTRL+N Opens a new database
CTRL+ENTER Opens an object in Design view
(ALT+D)
CTRL+F11 Toggles custom and built-in menu bars
Visual Basic for Applications
The Visual Basic Editor is not included, so users cannot see your code in the run-time environment.
Error Handling
Error handling is critical in a run-time application. In a retail version
of Microsoft Access, an unhandled error prompts you with an error message
and in many cases enables you to view or reset the code that caused the
error. In run-time Microsoft Access, if an unhandled error occurs, your application quits unexpectedly.
You can include error handling only by using Visual Basic for Applications
code; macros do not provide error handling. Therefore, limit the use
of macros in your run-time applications.
For more information about writing error handling code, in the Visual Basic Editor, click
Microsoft Visual Basic Help on the
Help menu, type
error handling in the Office Assistant or the Answer Wizard, and then click
Search to view the topic.
Help
If you want to provide Help for your run-time application, you must create
your own Help file. Microsoft Office 2000 Developer includes the HTML Help Workshop to assist you in creating a custom Help file and the "Package and Deployment" wizard to assist you in distributing your Help file.
NOTE: The Microsoft Office 2000 Developer end-user license agreement does not permit you to distribute the Office Assistant as part of your Help system. If code in your application invokes any of the methods or properties of the Office Assistant, the code generates an error in the run-time environment.