Richard Hale Shaw
Programming the Microsoft WindowsÔ graphical environment presents a formidable challenge to the applications developer. You must be proficient in C, ready to abandon the traditional, procedural programming you are accustomed to in favor of the Windows1 message-based architecture, and you need to master the Windows Application Programming Interface.
ToolBook, by Asymetrix, is one alternative to programming Windows directly. It allows you to create Windows applications more quickly and easily. It doesn't require knowledge of C, and you won't have to fathom the depths of Windows programming to master its interactive development environment (sophisticated nonprogrammers should find it usable).
Similar to traditional object-oriented programming environments in which objects encapsulate data and methods, ToolBook includes predefined objects such as buttons, fields and hypertext hotwords. You can also create your own objects by drawing them, or by importing bitmapped images. Using ToolBook's English-like, event-based programming language, OpenScript, you can associate blocks of code, called scripts, with objects such as push buttons.
Authors and Readers
A ToolBook application is composed of one or more files called books. Books have one or more pages, which in turn contain the other objects (fields, buttons, graphics, and so on) that compose a Toolbook application. In this vein, ToolBook application developers are referred to as Authors, and users of ToolBook applications are called Readers.
ToolBook has two modes of operation: Reader level and Author level. When a book is read by a user, ToolBook is at Reader level. At Author level, you can modify books and objects. The authoring version of ToolBook comes with BookShelf, a cataloglike book that displays an icon for each book in the TOOLBOOK subdirectory (see Figure 1). (ToolBook book files always have a TBK extension.) If you double-click a book's icon, BookShelf will run the selected book by starting a new instance of ToolBook, which will open the new book and display the first page. The original instance of ToolBook will continue to run BookShelf.
A run-time version of ToolBook, which allows you to work only at Reader level, is included with Windows Version 3.0; this version can be used to run the DEMO application presented with this article. The sample books "DayBookÔ," a calendar and personal organizer, and "Introducing ToolBook," come with the run-time version.
Readers have access to a subset of the commands made available for Authors; ToolBook's menu bar changes accordingly. Readers can add pages, search for text, and save a book with a new name. They can print one of the book's pages to a sheet of paper or print several pages per sheet; sheets may be previewed before being printed. Readers may also format text and access the Windows Clipboard.
The complete authoring package includes an animation primer, books of script and page ideas, clip art, reference "books" for using Windows dynamic-link libraries (DLLs) with ToolBook, a hypermedia tutorial, a calculator, and the BookShelf.
Authors can test their books by bringing up the Command Window and entering commands manually. This avoids having to go back to Reader level for testing (see Figure 2).
Authors can use tools and commands to build books, and have access to the color drawing tools and palettes (see Figure 3). At Author level, ToolBook displays a status box to show what page you're on and the number of pages in the book. You can test the modifications you make to a book by switching back to Reader level. When the application is complete, you can assign a password to a book to prevent unauthorized access to Author level and avoid unauthorized opening or saving of the book.
Pages
Every book has at least one page and one background. Each page has a unique foreground, but can share its background with any other page in the same book. Backgrounds are like templates. They make it easy to put the same objects on several pages, since objects displayed on a background have the same size, style, and position on every page that shares the background. Obviously, when you change an object in a background, the change is reflected in every page that uses the background.
Within the foreground and background, ToolBook objects lie in layers with one object in each layer, similar to a stack of transparencies. You can manipulate the order of the layers in a foreground or background to overlap objects.
Objects
ToolBook objects include buttons; fields; record fields; hotwords; imported or Author-drawn graphics; and group objects, which are several objects grouped together to form a complex visual image. Pages, backgrounds, and books are objects as well.
Each ToolBook object has a specified appearance and behavior. When an object is created, its properties are preset to default values depending on its type (button, field, or hotword, and so on). For example, all buttons appear as rounded rectangles with the text label "Button" inside. The values of an object's properties determine its behavior and appearance. Since the object's behavior is predefined, all you have to do is determine which modifications or additions to the default behavior you need for your application. You can modify an object's behavior by changing the value of a property, although you don't need to know how an object changes its appearance or behavior: ToolBook encapsulates this into the object for you. For example, all ToolBook buttons have a borderStyle property, which indicates whether buttons are normal, rounded, or shadowed rectangles; radio buttons; or check boxes (see Figure 4). If you change a button's borderStyle property to radiobutton, ToolBook will change the object to a radio button.
Text can be added to a page using borderless fields for labels or shadowed borders for titles; field text can word-wrap and be set to a variety of fonts and type sizes. Bordered fields are also available for data entry. You can create push buttons, radio buttons or check boxes and use them as labels.
Hotwords provide hypertext links to other objects and pages-like push buttons embedded in a paragraph of text. After you designate a string of characters as the hotword, ToolBook will move to another page or trigger an action if the Reader clicks it. Hotwords let you build dynamic text screens, in which extra information can be given to Readers who need it, without cluttering the display for those who don't.
Using record fields, you can easily create simple tables of information as well as data entry applications. Record fields themselves are used only in backgrounds, whereas contents of fields are stored in the foreground. This setup allows multiple foreground pages to contain different text for the same record field. Thus, you can establish a background composed of record fields that correspond to a table structure, using a different page to represent each record.
Creating Objects
You can use the built-in drawing tools to create graphical objects called draw objects, or import them from other programs to create objects called paint objects (see Figure 3). Palettes are used to create objects within ToolBook. Objects are chosen from the Tools palette. The Line Palette lets you control line thicknesses; the Pattern palette offers four pages of color patterns. A Polygon palette lets you set the number of sides in a polygon. Two other palettes, the Color Tray and the Spectrum Palette, are used to color backgrounds, draw objects, buttons, or fields. These palettes include color icons that display the currently selected stroke and fill colors and a color swatch that shows how text will look. The Color Tray contains 64 custom colors that you can customize with the Spectrum Palette, with its more than 16 million shades and tints.
To create an object, you choose an icon in the Tools palette. You can select buttons, fields, record fields, and hotwords and position them in the foreground or background. The one exception is record fields, which can only be positioned on a background. Unfortunately, it's not at all obvious what some of the icons in the Tools palette represent. You can select a drawing tool to place lines, arcs, angled lines, curves, regular and irregular polygons, normal and rounded rectangles, and ellipses on a foreground or background. When you select a tool, an indicator at the top of the palette shows you what type of object is currently selected (the indicator will be set to a pointer arrow if you haven't selected a tool). A zoom tool lets you magnify the page with four levels of magnification, up to 16x (see Figure 5).
Once you've placed an object, select it to make it the size, style, and color you want. Size the object by manipulating the square handles at its corners.
To bring clip art and other Windows bitmap images into ToolBook, all you have to do is display them with any program that lets you transfer them to the Windows Clipboard, such as the PaintBrush program included with Windows 3.0. ToolBook, however, limits the size of imported bitmaps to 64Kb. And once these images have been imported, you cannot resize or modify them as you can in paint programs.
New pages can be added to a book via a pull-down menu option or Ctrl-N. The new page is inserted after the current page; both will share the same background. You can add a new background for the current page via Ctrl-V.
OpenScript
All ToolBook objects have a script property. By default, this property has no value; that is, objects do not come with scripts already attached to them. ToolBook scripts are composed in OpenScript. You don't write programs in OpenScript as you would in C or Pascal, you create a script for any object whose behavior or appearance needs modification. For instance, to change a button named "COM1" to a radio button, you could use the following line:
set borderStyle of button "COM1" to radiobutton
Scripts are the power behind a ToolBook application. Each script contains instructions that define how an object should respond to a specific event, such as what to do when a user selects the object with the mouse. You can create scripts by recording actions you perform with the built-in script recorder or by writing them with the ToolBook Script Editor. Scripts are similar to macros, but considerably more powerful and sophisticated. For instance, besides changing the appearance of an object, scripts can modify the ToolBook graphical user interface itself, by adding menu items:
add menu "&DDE" at reader
add menuItem "&Retrieve Data" to menu "DDE" at reader
add menuItem "&Send Data" to menu "DDE" at reader
These OpenScript commands add a new menu item, "DDE," to the ToolBook menu bar, which can be activated via Alt-D. The commands install "Retrieve Data" and "Send Data" as items in the menu; these items can be selected by following the Alt-D with R or S. You can hide, gray-out, and check or uncheck these menu items just as you would in a C Windows program.
An Author can modify a ToolBook object from a script or manually via its Properties dialog box. An object's properties include its name, visual style, and optionally, a script. (Buttons and hotwords almost always have scripts.) Some objects have properties specific to their object type. For instance, a page includes a page number property; a book includes a caption or title, the page size and orientation, and passwords; a background includes color and pattern properties; other objects' properties include their layer number, size, position, colors, and vertices (see Figure 6). Some properties, such as a book's password, cannot be set from OpenScript.
The Properties dialog box for buttons and hotwords includes options for creating links between pages in the same book or different books (see Figure 7). For example, the Link To option lets you chain to another page when a button is pressed. The Link With option is the same as Link To, except it automatically creates a button on the destination page to return you to the original page. After choosing one of these linking options, select the other page (in the book you're in or another) and ToolBook will automatically link the objects.
Messages and Handlers
Like Windows, ToolBook is a message-based environment. ToolBook sends objects messages whenever a particular event occurs, such as when a Reader double-clicks an object. When it gets a message, the object's script interprets the message and reacts to it. If a script contains instructions for handling a particular message, ToolBook executes them.
The object may have built-in behavior that is triggered when that message is received. For example, if a Reader navigates to a particular page of a book, ToolBook will send the page an enterPage message. If you click an object on a page, ToolBook sends a buttonDown message to that object when you press the mouse button, and buttonUp when you release it. Upon receiving either message, ToolBook checks to see if the object has a script that prescribes the object's behavior for that message. If the object doesn't have the instructions for handling the message (because it has no script, or its script lacks the instructions for handling that message), the message is passed up to the next object in the object hierarchy (see Figure 8). ToolBook processes any messages passed to it that are not handled by any object in the hierarchy.
Each script is divided into sections called handlers. A handler contains OpenScript statements that tell ToolBook what actions to perform upon receipt of a given message. Thus, each handler defines how an object should respond to a particular event. All statements in a script (except comments) must be inside a handler. Variables are declared within handlers, user-defined functions and properties are defined within handlers, and all other instructions in scripts must be within handlers. There are three types of handlers: message handlers, "to set" handlers, and "to get" handlers.
Message handlers tell ToolBook what actions to perform when the object whose script contains the handler receives a particular message. They are the most commonly used handlers. "To set" handlers define what happens when statements set a user-defined property. "To get" handlers define new functions or how to get the value of a user-defined property.
The first statement of a handler begins with a phrase determined by the type of handler you're writing. A message handler starts with "to handle," followed by the message the handler responds to and any parameters. A "to set" handler begins with "to set," followed by the name of the property the handler defines, plus any parameters. "To get" handlers start with "to get," followed by the property that the handler returns the value of or the name of the function defined by the handler and its parameters.
Handlers end with either "end" or "end" followed by the message, function, or property named in the handler's first statement.
The key to mastering OpenScript is learning to use message handlers. This includes knowing when to use handlers for built-in messages, when to write handlers for your own messages, and where to place these handlers in the message hierarchy. You should also learn when certain objects' scripts should generate these messages themselves.
If a message is received, and an object's script has no handler for it (or if the object doesn't have a script at all), ToolBook passes the message from object to object searching for a matching handler. An object hierarchy dictates the order in which messages are passed among objects. If the message is not processed by a handler among the objects in the hierarchy, the message is passed to ToolBook itself.
The object hierarchy is how ToolBook implements object inheritance: the objects become progressively more abstract as you move up the hierarchy, so that messages are passed from lower-level objects to higher-level ones. Adding message handlers not only expands the capability of a book, it allows you to condense code. If the code in a handler is going to be repeated in the script of another object, you can write a single handler that will do the work for both objects. The trick is to place the handler high enough in the hierarchy to catch the messages each object receives that need servicing. If the handler is to be used throughout the book, place the handler in the script of the book itself. A special facility called the system book lets you trap widely used messages and functions. This is a special book whose script is available whenever another book or application is running. Using a system book, you can create global handlers for commonly generated messages. If you place a common handler in the script of the system book, you can avoid repeating the same handler in the scripts of several objects. When the corresponding message is generated, it will be passed up to the system book and handled there.
OpenScript has a number of built-in messages. These messages include buttonUp (sent to the object whose area contains the mouse pointer when the left mouse button is released), enterBook (sent to a book immediately after it is opened), make (sent to an object just after it is created; this message is comparable to the Windows WM_CREATE message) and destroy (sent to an object just before it is deleted; this message is not unlike Windows WM_CLOSE). Messages that you define must be processed by your own handlers-if they are passed all the way up the object hierarchy to ToolBook, an error will occur.
Creating Scripts
OpenScript statements are easy enough to hand-write. OpenScript has no explicit data types as do C, Pascal, and BASIC. It's similar to the dBASE language in that data types are implied by the context of the command, function, or operator being used. However, dBASE commands only work with certain data types; in OpenScript you do not have to designate a value's type or what type of data variable it may contain. Also, data variables have only two forms of scope: locals extend for the life of the handler and system variables extend for the life of the application.
For example, to initialize a local variable called x in the handler for buttonUp:
to handle buttonUp
set x to 0
o
o
o
end
OpenScript control structures (see Figure 9) include conditions/where (similar to the dBASE "do case") and step (like FOR in BASIC or C). Almost 50 functions exist (see Figure 10), primarily to perform mathematical functions and manipulate strings. More than 60 commands (see Figure 11) allow you to manipulate data files, navigate a book, control scripts and messages, modify the user interface and menus, print, and engage in dynamic data exchange (DDE) conversations with other applications.
Although the OpenScript documentation says that you can create your own OpenScript functions, these "functions" are really user-defined message handlers that return a value. Whenever a handler in one object's script needs to have something done by another object, all you have to do is send the object a message. You can define your own messages and write handlers for them in the objects that will receive them, or you can place them in a system book.
You can also extend ToolBook by accessing Windows DLLs. Any DLL that contains a published API can be called from ToolBook, including DLLs from third-party vendors as well as those you write yourself. As an example, a dBASE file-handling interface DLL is included with ToolBook.
You can create OpenScript scripts with an editor, copy them to the Windows Clipboard, and paste them into an object's script. Or you can open the ToolBook Script window and write a script there. The Script window, available via the Properties dialog box, will check the syntax and compile an OpenScript script when you exit it. If a syntax error is found, ToolBook returns you to the Script window and places the highlight on the offending statement (see Figure 12). You can also test scripts a line at a time using the ToolBook Command window. In this way, you can enter single OpenScript commands, or test entire handlers by sending messages to them. In either case, if an error occurs, ToolBook invokes the Debug window, which shows you the statement that caused the error. You can also look at the values of data variables and invoke the Script window to correct the erroneous statement.
You don't have to write every OpenScript script from scratch. As mentioned, when you use the Link To or Link With options in the Properties dialog box of a button or hotword, ToolBook creates a script that causes it to jump to the destination page when you click on the button or hotword. You can also create scripts by copying a script from one object to another or by using the Script Recorder.
Script Recording
The Script Recorder translates an Author's actions into OpenScript. Actions that can be recorded include choosing commands; filling in dialog boxes; creating, changing, and moving objects; navigating pages; opening books; and switching to Reader level. When you turn the Recorder off, ToolBook places the script in a private ToolBook clipboard. To assign it to an object, all you have to do is paste the clipboard's contents into the object's Script window. Then test the script by switching to Reader level and clicking the object. Incidentally, studying a recorded script is a good way of learning how OpenScript works.
The Script Recorder makes it easy to animate an object. You can make a script recording while moving the object; the resulting script will move the object in precisely the same way (see Figure 13). The object's position is recorded only when it receives a buttonUp. At that point, the Script Recorder records an instruction to move the object to that absolute position. As you can see, you'll need to intersperse mouse clicks among the movements; if you don't, ToolBook will record only the first and last positions.
This can be demonstrated if you click on the moving fish in the opening screen of the DEMO book. The fish's script includes a handler for buttonUp. When you click on the fish, it will loop around the large fish on that screen, then resume its regular motion from where it left off. The script for this fish was generated by the Script Recorder.
Visual Effects
A number of ToolBook commands can create interesting visual effects. You can use the fxDissolve command to dissolve one page into another, or fxWipe to wipe the screen from one side to another. The fxZoom command lets you zoom from one page to another; the hide and show commands hide or display any object. Simple application commands like ask and request let you query the user with pop-up windows, using a derivative of the WinMessageBox function in the Windows API. (Of course, you can also call this function directly since it's stored in a Windows DLL).
You can also draw an object directly from a script. For example, the following line of code will draw a rectangle from those coordinates on the current page.
draw rectangle from 1000,1000 to 5000,5000
DEMO Book
I've written a small DEMO book that demonstrates some ToolBook features of interest to developers. You can download this book from any MSJ bulletin board. It's a good idea to run the book while reading the article, to see exactly how some of the techniques work.
After loading the DEMO book, ToolBook sends it an enterBook message, notifying the book that execution has begun. The handler for this message, found in the script of the book (see Figure 14), begins by changing the menu: the menus found at Reader level (File, Edit, Page and Text) are removed, and a new menu is installed. If the book is run with the run-time version of ToolBook there will be a new File menu with a single menu item, Exit. If you are using the authoring version of ToolBook, the level menu will appear and the Author item will be available.
Changing the menu requires checking the sysRuntime property of the book, which is set to TRUE if the book is running under the run-time version of ToolBook (TBOOK.EXE) or FALSE for the authoring version. The sysLockScreen property is set to TRUE during the menu changes, so the screen changes will not be visible until they are complete. Note that a handler for the leaveBook message (which follows the enterBook handler) restores the menu bar at the Reader level. If you run another book that doesn't restore the menus and didn't have this handler in DEMO, the Reader menu for the DEMO book would appear: ToolBook's properties remain set from book to book until you reset them or close ToolBook and restart it.
Once the menu changes have been made, the enterBook handler alters the ToolBook main window size to fit the four corners of a VGA screen. This is done by modifying the bounds property of the main window (addressed as bounds of mainWindow in OpenScript). When a ToolBook property such as bounds includes more than one component, each must be addressed individually. Thus, the following statement sets the horizontal value of the bottom-right corner of the window to pixel 643.
set item 3 of bounds of mainWindow to 643
The bounds property contains four items, so each must be addressed. You'll see another example of this in the script for the first page of the DEMO book, which alters the components of the background's color property.
One other note on the book script: a handler for the user-defined movefish message controls the motion of the small fish ("MSJFish") that swims around the screen. This handler defines a system variable, pos, used only by the handler. The movefish handler uses the pos variable to select a screen position for the MSJFish. The handler's control structure is the OpenScript equivalent to a CASE construction in C or Pascal. There's a case for each value of pos from 0 to 40; when pos reaches 41, it's reset to 0.
The First Page
The first page (see Figure 15) has a script that contains two handlers: one handles the system-defined IDLE message, and the other handles a user-defined message, colorchange (see Figure 16). The IDLE message is sent by ToolBook to the current page when no other actions are occurring. When the IDLE handler receives an IDLE message, it generates a movefish message for the handler found in the book script; it sends a colorchange message for every eight IDLE messages. It does this by counting the IDLE messages in a system variable, colorcount; when colorcount is 8, the handler resets it to 0 and sends the colorchange message.
When activated, the colorchange handler alters the color of the background using three system variables; hue, lightness, and intensity. Since ToolBook initially sets these to null, the handler initializes them for the color red (where hue is 0, and the lightness and intensity percentages are 10 percent and 100 percent, respectively). Hue values can range from 0 to 360 with each color represented in increments of 60; the other two components range from 0 to 100. When a colorchange message is received, the hue is incremented to the next color, lightness (whiteness) is increased and intensity is decreased. As these values reach their limits during subsequent calls to this handler, they are reset. The background color is altered with the following OpenScript statement, which changes the fillcolor property of the current background.
set fillcolor of this background to hue, lightness,
intensity
A Reader moves to the next page in the book by clicking on the button at the bottom center of the page. The script of this button contains a handler for the buttonUp message, executing the following statement:
fxDissolve fast to page "Changing Properties"
The fxDissolve command allows you to dissolve the current page to black, white, gray, or another page. The speed parameter (slow, normal, or fast) controls the rate of the dissolve action. This statement makes the entire page appear to fade away exposing the next page, which seems to be underneath.
The Second Page: Changing Properties
The Changing Properties page demonstrates ToolBook's built-in objects; specifically, what happens when you change an object's properties (see Figure 17).
A Reader can change the color of the rectangle in the upper part of the screen by adjusting any of the three scroll bars, then clicking the Apply button or the rectangle itself. When the Apply button or the rectangle receives a buttonUp message, they generate a changeboxcolor message, handled in the script of the current page. (The page sends itself a changeboxcolor message when it receives an enterPage message from ToolBook.) Upon receiving this message, the handler (see Figure 18) sets three variables to the appropriate hue, lightness, and intensity values and sets the fillcolor property of the rectangle.
The color values are derived from the scroll property of each of the scroll bars displayed on the page. These are not true scroll bars, because unfortunately ToolBook does not offer a scroll bar object. If you want a scroll bar, you have to use a field with scroll bars, contracting the width of the field until only the scroll bar remains. Unfortunately, while fields can receive buttonUp messages, their scroll bars will not pass them on. Therefore, a scroll bar will respond to mouse messages by adjusting itself, but since it does not pass on a buttonUp message, a script cannot detect when the scroll bar has been clicked. This is why you cannot see dynamic color shifts taking place on the rectangle as you change the scroll values and why you have to click the Apply button for the color change to take effect. The lack of a scroll bar object is a serious deficiency in ToolBook.
Another object of interest on this page is the ChangeButton, which dynamically changes its borderstyle property and text when a Reader clicks on it. It will alternate rounded, shadowed, radio button, rectangle and check box styles and adjust its text from Rounded Button to Shadowed Button. The button's script (see Figure 19) uses a system variable and a conditions structure to increment the variable and reset it in order to alternate button styles.
There are several hotwords on the page that can be identified by their italic text style and by changes in the mouse pointer's shape as it passes over them. When clicked, these hotwords trigger message boxes that give you more information about how this page works.
Three buttons at the bottom of the page allow you to navigate between pages. The first lets you dissolve back to the opening page. The second uses the fxWipe command to make it appear as if the page is being turned (from right to left) to the database demo page. This is accomplished with the following statement in this button's buttonUp handler:
fxWipe left fast to first page of background "Data Entry"
The third button uses the fxZoom command to zoom to the animation demo:
fxZoom fast to page id 13
This command makes the target page appear to explode from the center of the current page outward.
The Database Demo
You click the second button, Database Demo, to move to the Data Entry screen (see Figure 20). This screen is a background with several record fields and buttons and one or more pages, sorted by the contents of the last name field. You enter name and address information into the current page, according to the fields in the background. The buttons are used to add a new blank record, delete the current record, and navigate to the previous and next records. Here, a record is synonymous with a page: to add a blank record, you only have to add a new page over this background. Similarly, deleting the current records destroys the current page. The background also maintains a record number field.
If you look at the background's script, you can see how it works (see Figure 21). The background receives an enterBackground message (see its enterBackground handler) when records are added or deleted, or when a Reader navigates from record to record. Then it sends an updaterecnum message to update the record number field. The value displayed in the record number field is the value of the current page's pageNumber property minus three. (There are three pages in front of the first page of this background.) Since the Data Entry background is at the end of the book (it follows the background for the animation demo discussed below), you can add new pages to this background.
If you study the updaterecnum handler, you'll see that it retrieves the current page's pageNumber property into a variable called "it." In many object-oriented languages, "it" is a variable that is globally available at all times: you don't have to declare "it." In the script, "it" is used to place the page number (minus 3) into the text of the record number field.
The buttons and icons at the bottom of the background have relatively simple scripts in order to avoid unnecessary repetition of code used by each button. Each button-icon pair has a buttonUp handler that sends a message indicating what type of operation must take place: Add, Delete, Previous, and Next. For example, the Delete button and the Trash Can icon have the same script:
to handle buttonUp send deleterecord end
Each button-icon pair have the same script, but each pair sends a unique message.
The handling for Add, Previous, and Next is relatively simple. To add a new record (or page), the addrecord handler in the background script sends a newPage message to the page, causing ToolBook to create a new blank page, insert it after the current page, and navigate to the new page. When this happens the recordfields on the background remain, but the data they contain is blank (since the page is blank). The handler follows by sending an updaterecnum message to update the record field.
As for Previous and Next, the handlers for previousrecord and nextrecord use the go command, as shown below.
go to next page of this background
This is the key statement in the handler for nextrecord. The previousrecord handler contains the word previous in place of next. These handlers finish by sending an updaterecnum message to the background.
The most complex handler in the background's script is the deleterecord handler. It begins by determining if only one page remains on the data entry background. If so, it sends a newPage message to the current page. This places the new page after the current one, so it navigates back to the original page. From there the delete operation can proceed uniformly: the page is selected and sent a clear message, making the page delete itself. Then the script navigates back to the new page (now page 1 of the background) and an updaterecnum message is sent. Note that the Reader sees only the results of the operation, since sysLockScreen is set to TRUE at the beginning of the operation and reset to FALSE afterwards.
You can leave the database demo by pressing the appropriate button, which uses fxWipe to turn the page back to the right to return to the Changing Properties page.
Animation Demo
The animated fish tank is controlled by the script of Page Three (see Figure 22). The script uses the IDLE message to move the objects continually, and sends a message for each object that's to be moved (see Figure 23).
All the fish move along a calculated track in the direction they are pointing. After they move offscreen, they reenter the screen from the opposite side. The seaweed moves in sequence between two positions, so that it looks like it's waving in the current. The starfish crawls between four positions.
Creating the Images
The bitmapped images used in this book were imported from bitmap drawings. The only exceptions are the backgrounds used in the animation demo (which were drawn with ToolBook) and the icons used in the data entry demo, which came from a variety of sources. The Trash Can icon was lifted via the Clipboard from an old Windows 2.0 application.
Importing these images and having them display properly in ToolBook wasn't easy. The images were originally drawn transparently on a white (empty) background in a paint program. Once imported, colors in the background or colors in other objects would "bleed" through the white areas of the imported image.
The solution was to create a white background for each image by tracing an irregular polygon around it (see Figure 24). If you try this with the authoring version of ToolBook, first draw the polygon transparently so you can see what you're tracing. Then the polygon's transparent property is turned off (via the Draw pull-down), and filled with white. The new polygon is placed behind the bitmap. Because every new object that you add to a page or a background is inserted in a layer above the topmost object, the easiest way to do this is to cut the image itself (not the white backdrop) to the Clipboard, and paste it back onto the page over the polygon backdrop. Creating an object group from the two objects fuses them together. The group can subsequently be moved or superimposed over other objects and backgrounds without losing the image's integrity.
Pasting images seems to fragment ToolBook's heap, so that it may generate a message indicating that the page or background is full. Therefore, make sure that you do not have your only copy of an important bitmap in the Clipboard. Save the book to disk and then paste the image. If, after this, you still get the "full" message, you may have to omit some objects from your background or page.
Some of the images planned for the animation demo could not be pasted into ToolBook. The large MSJ fish on the first page would simply not fit: ToolBook currently limits the size of imported bitmaps to 64Kb each. This image had to be bisected and pasted in two pieces. One piece is in the background and the other is lined up next to it on the foreground. If you have the authoring version of ToolBook, you can observe this by switching from foreground to background while in Author mode.
Conclusion
To run ToolBook, you'll need the minimum requirements of Windows 3.0 in protected mode, namely: an 80286 or 80386-based PC, DOS Version 3.1 or later, 640Kb of RAM plus 256Kb extended memory, a hard disk with 2 to 8Mb available, a mouse, a VGA or EGA monitor, and of course, Windows 3.0. As an Author, you'll be better off throwing as much firepower at ToolBook as possible: at least a 16MHz 386 with 2Mb or more of RAM. ToolBook is not terribly slow, but it's not terribly fast, either. To increase its speed, you might not want to force ToolBook to do some types of graphics redisplays in your books. (Unfortunately, some people have dismissed ToolBook's speed because of DayBook, which makes heavy use of graphics and is probably more complex than many ToolBook applications will be.)
ToolBook is currently most suitable for prototyping Windows programs, writing on-line help systems and training facilities, creating presentations, and integrating text and graphics. ToolBook does suffer from problems with speed and it cannot manipulate complex graphics images easily (at least, not without a few workarounds). ToolBook lends itself well to designing training packages and courseware: information windows and panels can be tied to objects that cause a window to appear when the Reader clicks on them. This would be ideal for programmed learning systems. You might create books that teach or supply specialized information, or create specialized financial tools, in which bar charts change as data is received through DDE. ToolBook should also be considered to create front-ends for popular database systems. Even a process control application would be impressive under ToolBook: users who don't even know how to use a computer could control an assembly line using the mouse and animated graphics. It points the way to entirely new kinds of applications and application interfaces.
1 For ease of reading, Windows refers solely to the Microsoft Windows graphical environment and is not intended to refer to such products generally.