Using the AutoPackager Feature of ToolBook Assistant
This presentation was prepared for the Asymetrix OnLine Learning 1997 Conference held in Seattle Washington, September 7 - 10, 1997.
Example: Very simple, single book, no external files. Full installation to hard drive. The procedures detailed below were documented using Asymetrix Assistant 6.0 under Windows 95.
For this example, I am using a lesson that we are currently developing for the University of Illinois Institute of Aviation. The following figures document how I can use the AutoPackager feature built into Assistant to create a set of 1.44 MB installation disks.
STEP #1. OPEN YOUR PRIMARY TOOLBOOK FILE.
Use Assistant to open your primary book. (This example includes only one .tbk file.) [The AutoPackager is accessed from the book you wish to package. This is a big change from using Setup Manager, which functioned as an independent application.]
Figure 1. The Assistant Application to be Packaged for Distribution.
STEP #2. ACCESS THE AUTOPACKAGER OPTION.
Switch to Author level by pressing the F3 key. From the File menu, select AutoPackager.
Figure 2. Access the AutoPackager option from the File Menu.
STEP #3. SELECT OPTIONS IN AUTOPACKAGER.
Examine the AutoPackager options dialog (Figure 3). There are 4 sections to this dialog window:
The application name is initially set from the title you have given your book in Assistant. (This setting can be viewed by selecting Object-Book Properties -- but not once you've started the packaging process.) You can leave it the way it is, or change it.
The default settings assume you wish to create an installation that will be distributed via a Compact Disc (CD-ROM). It is also assumed that your users will install the application files to the hard drive, but leave media files on the CD.
If you're using Assistant under Windows 95, the default installation directory will be under Program Files on the boot drive + the name of the subdirectory in which you're currently working. If you will be distributing your application for Win 3.x users, you should change the default directory to NOT include the long "Program Files" as part of the default path. If your Win 3.x end-user tries to install to a default directory including "Program Files," an error will occur and the setup program will terminate.
Figure 3. AutoPackager Dialog with Default Settings.
You can change the default installation directory in two ways. (1) Click inside the entry field, select the current path, and edit it. When you use this method, you can enter a subdirectory that doesn't necessarily exist on your computer. (2) You can click the browse button [·] to access a file selection dialog window (Figure 4). You can then navigate your computer's drive:directory structure to locate the desired subdirectory. Of course, to use this approach you must have already created the subdirectory. This location is written into the setup file and will be presented as the default destination to the user who installs your application. No files are written to this location during the autopackaging process.
Figure 4. Browse Option for Selecting Default Target Directory.
My application will be distributed on 1.44 MB floppy disks, so I need to change the Compact disc distribution to 1.44 MB (3.5-inch) disks. Notice that the Installation options are now dimmed (Figure 5). When you install from floppy disk, you have to place all files on the hard drive -- there's no other choice available. I also changed the default installation directory to "c:\radiocom."
Figure 5. AutoPackager Dialog after Changing Settings.
Options
If you click the Options button on the dialog window, you will see a screen similar to the one in Figure 6. Notice the two default settings: run-time files will be included in the package and any media files that are not present in the subdirectory shown will be gathered up and copied to that location. The defaults are fine for us, especially since we have only a single book and no external media files to deal with. We'll just click OK to close this option dialog. Click OK again at the AutoPackager dialog window (Figure 5) to proceed.
Figure 6. AutoPackager Options.
When you click OK, you're given the option of saving the settings you have just selected (or the defaults) as part of the book you're packaging (Figure 7). This will be convenient if you need to start the process over again after making changes/corrections to your book. While we don't know the exact way these settings are saved, it's pretty certain that the information is being saved as special user properties of the book.
Figure 7. Prompt that Lets You Save AutoPackager Settings with Book.
STEP #4. BUILD THE PACKAGE FILES.
The AutoPackager will next prompt you to indicate a location where it will build the package files. I prefer to create a temporary directory that will contain only these files. You can't create a subdirectory directly from this dialog, so it's a good idea to create one in advance. (In Windows it's relatively easy to switch to the desktop and create a new subdirectory somewhere and then return to the AutoPackager.)
Figure 8. Select a Location for Building the Package Files.
After you locate the subdirectory you wish to use and click the OK button, the AutoPackager first gathers the application, media, and run-time files needed. (This goes by pretty quickly in our case!) If you were to examine the log file at this point, you would see that the AutoPackager encountered no problems locating the necessary files. It also checked our one ToolBook file for the various run-time extensions that it used. As shown in Figure 9, the AutoPackager informs you of its progress and requires you to click "Continue" to actually start creating the package files.
Figure 9. AutoPackager Progress Dialog.
The AutoPackager then generates an install script. Next, the progress window shown in Figure 10 is displayed. AutoPackager is based on InstallShield 3.0, and it uses InstallShield's own setup mechanisms to package the files.
Figure 10. InstallShield Wizard Progress.
The AutoPackager compresses the various files needed for the application. If you watch closely, you'll be able to see the files listed in the progress dialog window (Figure 11).
Figure 11. Compression Progress Dialog.
STEP #5. LET THE AUTOPACKAGER COPY THE PACKAGED FILES.
When all of the files have been compressed and the build process is complete, it's time to copy the package. You need to select a different location using the file selection dialog shown in Figure 12. (As before, you can easily switch back to the desktop, create a suitable subdirectory and return to the AutoPackager, if you failed to create a subdirectory in advance. If you try to copy the packaged files to the same directory you built them in, you'll get the error dialog displayed in Figure 13.) You can have these files copied directly to floppy disk, by placing a blank, formatted disk in your floppy drive and selecting that location. You will then be prompted to insert new disks, as needed. I prefer to create these files on the hard drive first. I created a separate directory called "radioInstal" and located that subdirectory (Figure 14) and clicked OK to proceed.
Figure 12. Select File Copy Location.
Figure 13. Error Dialog .
Figure 14. Selected an Appropriate Directory for the Copied Files.
After a brief delay, the AutoPackager Progress dialog appears, indicating that "Packaging is complete."
Figure 15. Packaging is Complete.
Now that the AutoPackager has successfully completed its work, what do we have? In the "tempRadio" subdirectory (Figure 16), we have the files as they were built by the AutoPackager.
Figure 16. Files Built by the AutoPackager.
STEP #6. MANUALLY COPY DISK CONTENTS TO FLOPPY DISK.
(If you decide to work directly with floppy disks in the previous step, skip this step.)
In the RadioInstal subdirectory, we now have a set of additional subdirectories, one for each 1.44 MB floppy disk required to hold all of the compressed files (Figure 17). To prepare your set of installation disks, you will need one properly formatted disk for each of the subdirectories. You do not need to copy the single file, "_package.id," to any disk. To create the disks, copy the contents of each folder to a disk, but not the folder itself. The AutoPackager has done more than simply copy the contents of the build directory to a new set of subdirectories. If you look inside the disk1 subdirectory, you'll see several files that weren't in the build directory (Figure 18). The other disk subdirectories each contain two files: a diskID file and a numbered, compressed setup file (Figure 19).
Figure 17. Files Ready to Be Copied to Floppy Disks.
Figure 18. Contents of subdirectory "disk1."
Figure 19. Contents of the other 5 Subdirectories.
STEP #7. TEST YOUR INSTALLATION DISKS.
If at all possible, test your installation on a machine that doesn't already have the Assistant application or run-time files already installed. As you test your application, verify the directions that you will provide your end-user. A brief example:
. Insert disk 1 in the floppy drive.
. From the File Manager in Windows 3.x (Start menu in Windows 95), select run and type: a:\setup.exe and press the ENTER key.
. Follow the directions provided by the installation program.
A note on Uninstall
If you run the setup program for the application under Windows 3.x, an Uninstall icon will be placed in the program group. Under Windows 95, youâre expected to use the Add/Remove programs control panel. Both methods launch the InstallShield uninstaller. The uninstaller will remove your application, but it does not remove the shared run-time components. Under Windows 95, the uninstaller does not remove the program listing from the Start menu.
Should your uninstaller remove the shared components (e.g., the runtime files)? This is risky. It might be that the user has more than one application that is using these files. A novice user might not realize that by uninstalling everything, he will be messing up other applications. What I would prefer to see is a separate uninstall icon (Win 3.x) or entry in the Add/Remove Programs listing (Win 95) for the runtime components added. Then, your software documentation could provide information to the user about uninstalling these components.