| 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 |
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.
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 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 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 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."
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.
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 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, 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 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 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.
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.
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:
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.
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.
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.
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.
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.
Keys |
Description |
|
Ctrl+Break |
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. |
|
F12 |
Displays the Save As dialog. |
|
Shift+F12 |
Saves a database object. |
|
Ctrl+G |
Displays the Debug window. |
|
Ctrl+F11 |
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.
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:
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:
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:
Figure 35.2. Creating a new switchboard.
Figure 35.3. The Switchboard Manager dialog.
Figure 35.4. The Create New dialog.
Figure 35.5. The Switchboard dialog after adding pages.
Figure 35.6. The Edit Switchboard Page dialog.
Figure 35.7. The Edit Switchboard Item dialog.
Figure 35.8. The Edit Switchboard Page dialog after adding several entries.
Follow these steps to add, remove, or edit items from an existing switchboard:
An example of a completed switchboard appears in Figure 35.9.
Figure 35.9. A completed switchboard.
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."
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)
Me![fsubClients].Requery
Exit_Form_Activate:
Exit Sub
Err_Form_Activate:
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.
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.
Option |
Description |
|
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"
DoEvents
DoCmd.Hourglass True
fAnswer = AreTablesAttached(frmAny)
If Not fAnswer Then
MsgBox "You Cannot Run This App Without Locating Data Tables"
DoCmd.Close acForm, "frmSplash"
DoCmd.Quit
End If
Call GetCompanyInfo
DoCmd.Hourglass False
If IsLoaded("frmSplash") Then
DoCmd.Close acForm, "frmSplash"
End If
Exit Sub
AutoExec_Err:
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.
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."
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.
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.
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.
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).
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.
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:
Figure 35.16. The Setup Wizard dialog after adding several files.
Property |
Description |
|
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). |
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.
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.
Property |
Description |
|
Description |
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). |
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.
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.
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.
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.
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.
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.
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:
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:
Figure 35.26. Selecting Run from the Start menu.
Figure 35.27. The Application Setup Welcome dialog.
Figure 35.28. Selecting a location for the program installation.
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.
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.
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
rst.Close
Exit Function
Else
'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
rst.Close
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
frmAny!dlgCommon.ShowOpen
'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
tdf.RefreshLink
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"
Else
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
Exit_Failed:
MsgBox "You can't run this example until " & _
"you locate Data File", 16, "Can't Run This Example"
AreTablesAttached = False
Exit_Final:
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)
Loop
'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
'database
If tdf.Connect <> "" Then
tdf.Connect = ";DATABASE=" & strAppDir & "CHAP19DATA.MDB"
tdf.RefreshLink
'Update Progress Meter
intTableCount = intTableCount + 1
vntReturnValue = SysCmd(SYSCMD_UPDATEMETER, intTableCount)
End If
Next tdf
TryAgain_Exit:
Set db = Nothing
Set tdf = Nothing
vntReturnValue = SysCmd(SYSCMD_REMOVEMETER)
Exit Function
TryAgain_Err:
TryAgain = False
Resume TryAgain_Exit
End Function
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."
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.