Help System With Semitransparent Window for Disabling Controls

The present invention relates to computer systems in general, and in particular to on-screen help programs.

As computers become increasingly complex, the software designed to run on such computers becomes correspondingly powerful. As a result, many programs require significant time and energy to be spent before a user can operate the program at its full potential. To help a user, most computer programs are sold with one or more manuals that describe all the features capable of being performed by the program and how to implement those features. In addition to the written materials, most programs have some sort of "on-screen" help program. These help programs are designed to allow a user to quickly search for information regarding a feature and to present the user with a brief narrative concerning how to accomplish the desired feature.

Despite the apparent simplicity of the on-screen help programs, they suffer from numerous disadvantages that limit their utility. First, most on-screen help systems provide less information than is contained in the corresponding computer manual. Therefore, it is often necessary to read the manual in addition to using the on-screen help program. Secondly, in order to implement a task described by the help program, the user must memorize the steps described, exit the help program and attempt to implement those steps. Because the program may not appear to the user in the same fashion as was described in the help program, it is often difficult to perform the required steps--even after having read the manual or used the on-screen help program. Finally, most on-screen help programs are not context specific. That is, the information provided remains the same regardless of how the underlying program in which help is desired is operating. Because the steps required to implement a feature may vary depending on how the underlying program is operating, the user may be given incorrect or incomplete information.

To solve the problems associated with prior art on-screen help systems, the present invention is an interactive computerized help system. The help system operates simultaneously with an underlying program being run by a user in order to show the user a sequence of steps required to implement a desired task. After each step has been performed by a user, the step is marked by the help system as being completed. The help system is context sensitive with the underlying program, so that the information or sequence of steps given to the user is tailored to how the underlying program is operating. If the user does not understand how to implement a step, the user can select a "show-me" option that performs the step for the user. Finally, the user can select a "do-it-all" option that shows the user how to perform the entire sequence of steps required to implement a desired task to completion or until user input is required.

The foregoing aspects and many of the attendant advantages of this invention will become more readily appreciated as the same becomes better understood by reference to the following detailed description, when taken in conjunction with the accompanying drawings, wherein:

FIG. 1 is a block diagram of a computer system in which the help system of the present invention is implemented;

FIGS. 2A-2C are representations of a conventional graphical user interface and a prior art on-screen help program;

FIG. 3 is an illustrative example of a help screen produced by the present invention;

FIG. 4 is a representation of the simultaneous display of the help system according to the present invention and an underlying computer program in which help is desired;

FIG. 5 is a representation of how the help system according to the present invention operates to illustrate a step required to complete a desired task;

FIG. 6 is a representation showing how the computer help system of the present invention operates to disable controls that should not be selected by a user in order to complete the desired task;

FIG. 7 is a flowchart of the steps performed by the computer system to generate a sequence of steps that instruct a user how to perform a desired task;

FIG. 8 is a flowchart of the steps performed by the help system of the present invention to show a user how to complete a single step in a sequence of steps; and

FIG. 9 is a flowchart of the steps performed by the help system of the present invention to show a user how to complete an entire sequence of steps required to implement a desired task.

The present invention is an interactive computer help system that provides information to a user regarding how to complete a desired task. In addition, the computer system will show the user how to perform the steps required to complete the task, if desired.

The help system of the present invention is designed to operate with a conventional computer system of the type shown in FIG. 1. The computer system includes a central processing unit (CPU) 15 having its own internal memory 22 and digital storage mechanism such as a hard disk drive 24. The disk drive and memory are coupled to the CPU via an internal data bus 20. Commands are entered into the computer system via a keyboard 26 and/or a pointing device, such as a mouse 28, which are coupled to the CPU 15 by a set of leads 30. The computer system may be coupled to other similar computer systems by a local area network (not shown). Programs executed by the CPU preferably use a graphical user interface that is displayed on a monitor 32. An example of a graphical user interface is the Windows.RTM. operating system produced by the Microsoft Corporation.

As will be explained in further detail below, the help system of the present invention comprises a computer program that is executed by the CPU 15 simultaneously with the program in which the user desires help. The program resides either in the memory 22 or can be stored on the hard disk drive 24.

FIGS. 2A-2C show a typical Windows.RTM.-based computer program having an on-screen help program. In particular, the program shown is the Paintbrush program produced by Microsoft Corporation. As shown in FIG. 2A, most Windows.RTM. programs are displayed in an area of the screen called a window 50. The window has a title bar 52 that provides the user with the title of the program. The title bar surrounds a working area 54 in which the user can perform the task to be completed by the program. In the Paintbrush program shown, the user can create drawings or graphic illustrations within the working area. Below the title bar is a menu bar 56 that allows the user to perform specific tasks such as opening a file, saving work, changing the parameters of the program, selecting preferred options, etc. Typically, the menu bar 56 includes a special help menu 58 that can be selected by a user to obtain information regarding how a particular task can be completed by the program.

FIG. 2B illustrates a conventional prior art on-screen help program that appears when the user selects the help menu. The help program is displayed in its own window 60 that includes a separate title bar 62 and menu bar 64. Within the help window are a list of topics 66 about which the user can obtain information. By moving a mouse pointer over a particular topic and selecting it, the user is provided with a brief description of how a particular task is to be completed.

FIG. 2C shows what happens when the user selects a particular topic from the list of topics displayed in the help window. As indicated above, the user is provided with a short description of the steps the user should implement in order to complete a desired task. In the example shown, the help program provides instructions to the user regarding how a drawing should be printed. To use the information provided, the user reads the instructions, exits the help program, and attempts to implement the steps described in order to complete the desired task, i.e., to print a drawing.

As will be appreciated by viewing FIGS. 2B and 2C, the on-screen help program shown is not integrated with the underlying program in which the help was requested. That is, the help program appears in a separate window that can be moved about by a user, and the text displayed does not change depending upon the operating parameters of the underlying program.

To improve upon the on-screen help system shown in FIGS. 2B and 2C, the present invention is an interactive help program that provides instructions to a user that are context sensitive to the operation of the program in which help is being sought. In addition, the help program of the present invention may provide the user with an illustration of the sequence of steps required to complete a task.

FIG. 3 illustrates the first display screen produced by the help system of the present invention when a user has requested help from an underlying program. When the user selects the help system, the window in which the underlying program was displayed is overwritten by a help screen 70 that displays a series of icons or context jumps 72, 74, 76, . . . 82, that symbolize the topic about which information can be obtained. To view the information on a given topic, the user places a cursor over the corresponding icon and selects it. The user may then be presented with further subtopics to select in order to narrow the topic about which help is desired.

Once the user has found the topic about which information is desired, the help system of the present invention generates a screen 80 like that shown in FIG. 4. The screen 80 is comprised of two sections. The first section 82 is a re-sized window of the underlying program that was operating when the user requested help. Surrounding the window 82 of the underlying program is a help window 84 in which the sequence of steps required to complete a task are shown. Preferably, the window 82 of the underlying program is always displayed as the same size, so that if the window of the underlying application were originally larger than the area of the area of the window 82, the window of the underlying application will be made to appear smaller than before. Alternatively, if the underlying application were running in a window that is smaller than the area of the window 82, then the size of the window in which the underlying application is running will be increased.

In the help window 84 is a list of sequential steps required to perform a given task. Adjacent each step in the list is an indicator 86 that shows whether the step has been completed. For example, the current indications 86 are shown as push pins. However, other icons such as radio buttons or differently shaped bullets could be used. To use the help system, the user reads the instructions in the list and completes each step within the underlying program window 82. After the user has completed a step, the help system changes the status of the indicator 86 adjacent the step to confirm that the step was properly accomplished.

In the lower left-hand corner of the help window 84 is a "do-it-all" button 88. This button causes the help system to complete each step in the list of steps so the user can watch. The do-it-all button may be faster than performing each step by hand and therefore serves as a shortcut to complete a task.

A "show-me" button 90, also disposed at the bottom of the help window 84, operates to illustrate the next step in the series of steps required to complete a desired task. For example, if the user is unsure where to place the cursor, the user selects the show-me button 90 and the cursor is moved by the help system to the appropriate spot in the window 82 of the underlying program and the step is executed.

An "exit" button 94 closes the help program of the present invention and returns the user to the underlying application with the changes made that were performed while the help system was running.

FIG. 5 illustrates how the present invention operates to show a user how a step is performed. The cursor is moved by the computer system over the correct position in the underlying program window 82 and the application is caused to respond to the cursor as if the user had made the command by hand. For example, when the help system instructs the user to select the "View" menu, the cursor is placed at the correct position in the window 82 and the View menu 96 is brought down. In addition, the help system may place a balloon or bubble indicator 98 at the appropriate position in the window that informs the user what to do next.

To prevent the user from selecting the incorrect options in the window 82 of the underlying program, the majority of the window is disabled by placing a crosshatched screen over the active window. The only portions of the window that are not disabled are those that may be selected by the user. For example, FIG. 6 shows a dialog box prompting the user to select a watermark background. Therefore, the majority of the dialog box is disabled except for the controls that allow the user to select a watermark and its placement. By disabling the controls in the active window which the user should not select, the chance that the user can make an error is decreased. The details regarding how the controls in the active window are disabled are described in further detail below.

FIG. 7 shows the steps performed by the computerized help system of the present invention to allow a user to retrieve information regarding a desired task and to display those steps required to perform the task. Beginning at a step 200, the computer system determines whether the user has selected the help program. If not, the computer system continues to display the underlying application at a step 202 until the help program has been selected. Once the user has requested help through the help program, a window of the type shown in FIG. 3 is created at step 204 that displays a list of topics about which information may be obtained. The computer system then determines whether the user has selected a task or topic from the list at step 206. If no topic is selected, the computer system loops back to step 204 until the user selects an available topic or exits the help program.

Following the selection of a topic, the computer system retrieves from memory or the digital storage media a script that informs the help system what information should be displayed for the user at a step 208. At a step 210, the window in which the underlying program is running is re-sized and is placed within the window containing the list of the required steps that is generated at a step 212. Processing then proceeds to the steps shown in FIG. 8.

At step 216, the computer system begins a loop that processes a series of scripts each of which is associated with a step in the list of steps required to complete a given task. At step 218, the computer system recalls a script associated with the step and executes it. At a step 220, the controls in the active window 82 that should not be selected by the user are disabled by overlaying a crosshatched screen over them.

At step 224, the computer system determines whether the user has completed a step. If so, then the indicator adjacent the description of the step is modified to show the step has been completed at a step 226. The computer system then determines whether all steps in the sequence have been completed at a step 228. If not all of the steps have been completed, the computer system returns to step 216 and recalls the next script associated with the next step in the sequence of steps. If all the steps have been completed, the user is asked whether they wish to return to the main help menu or exit the help program at step 229. If the user does not want to exit the help program, processing returns to step 204. If the user wishes to exit the help program, the computer system erases the help window at step 230 and re-sizes the window of the underlying program back to the size of the window before the help system was initiated at step 232.

If the answer to step 224 was no and the user has not completed the desired step, the computer system then determines whether the user has selected the "show-me" option at step 250 (FIG. 9). If so, the computer system runs a "show me" script that causes the computer system to complete the next step. The computer system then returns to step 226 (FIG. 8) and shows that the user has completed the step.

If the answer to step 250 is no and the user has not selected the "show-me" option, the computer system determines whether the user has selected the "do it all" option at step 260. If so, the computer system begins a loop at step 270 that determines which of the required steps have not yet been completed. At a step 272, the computer system runs the remainder of the "show me" scripts to complete the desired task. A step 276 determines whether all remaining scripts have been completed. If not, the computer system returns to step 270. If the answer to step 276 is yes, and all scripts have been completed, the computer system returns to step 229 (FIG. 8) and determines if the user wishes to exit the help program.

In some instances, it is not possible to tell what action a user may take to successfully complete a step. Consequently, the event that signifies the completion of a step cannot be encoded into a script. For example, if a user is given several selections of which any one may be valid, the help system cannot know in advance which selection the user will choose. Therefore, the computer system may add a "back" or "next" button 102, 104 (FIG. 6) to a dialog box so that the user can inform the help system when a step has been completed. The computer system checks to see if these buttons have been selected at steps 262, 266. If so, either the previous or next script is re-run at steps 264, 268.

If the user has not selected the "do-it-all" option or the next/previous buttons, the computer returns to step 224 and awaits the user to make some attempt at performing the required step.

As described above, the help system of the present invention operates to illustrate the steps required to complete a task by running a series of scripts that are dependent upon the particular type of help the user has requested. When the user selects the help menu, a script is run that causes the computer system to display the help window and list of available options as shown in FIG. 3. When the user selects one of the options, the computer system is provided with the name of a script that should be run. The computer system retrieves the script from memory and executes the commands contained in the script.

Script files are small BASIC programs that direct the help program to display the list of steps required to complete a task and to perform the step if the user asks to be shown. In the example given below, the help program is designed to work with the RUMBA.RTM. product produced by Wall Data of Kirkland, Wash. The help program is called RUMBA Assist.TM.. However, from the description given, those skilled in the art will recognize how the help program can be readily adapted to other programs. Following the description of how the script files are constructed is a description of the help program that runs the script files.

A typical script consists of four parts: First, it connects to the help program Object Linking & Embedding (OLE) Automation object, allowing the help program to call other methods and set properties in the object. Second, it tells the help program what topic to display in the `text` window. Third, it sets up what conditions must be met in order for the next step in the list of steps to be executed. Lastly, the script tells the help program what script to execute on completion of the step and what script to execute if the "ShowMe" or "DoItAll" buttons are selected.

The following is a sample script file consisting of the first script of the `Select a watermark` script.

The above script interacts with the help program that is running simultaneously with the underlying program. As can be seen, the script operates to create a handle to the help program and then determines whether the menu function required to implement the desired task can be selected in the current configuration of the program. Assuming that the menu option is available, the script erases the screen and recalls from memory the appropriate text with the list of instructions that are to be displayed to the user and jumps to the appropriate place in the text. In the example shown, the computer system recalls a file called "demo/TutorX.M13". The computer system then jumps to the context point labeled "WaterMark" within the text.

All the indicators showing the completion of the individual steps are then reset. The statement Rumba.PanelType=LESSON.sub.-- PANEL causes the computer system to erase the screen display shown in FIG. 3 and to draw the two windows 82 and 84 shown in FIGS. 4, 5, and 6. In addition to configuring the screen each script contains an indication of the next user action to be expected. The help program is looking for this action and will proceed to the next script when the user performs it. The help program has no way of monitoring when the user has performed a given task. Therefore, the script informs the help program what will be the next action that the underlying computer program will take when the user has performed the desired task. For example, in the RUMBA.RTM. program, the program creates a dialog box called ConfigureWaterMark after the user selects the WaterMark option from the menu. The script informs the help program of this so that the help program can monitor the list of windows created by the program. When the help program sees the new window created, it knows the desired step has been performed and then executes the next monitor script stored in the variable Rumba.NextMonitorScript. If the user selects the "ShowMe" option at any time, the computer system runs the script that is stored in the location Rumba.NextShowScript. The help program then retrieves the next script and the process repeats until all the scripts have been completed. Each script takes care of changing the status of the indicator (i.e., the pushpin) to indicate that that step has been performed.

The following script is an example of a "ShowMeScript" that causes the help program to automatically select the WaterMark menu.

As indicated above, it is not always possible to know what step the user may take in order to complete a step. For example, the user may have more than one valid option that could be selected in order to complete the required step. In order to determine when the user has completed the task, the help system of the present invention supplies the "back" and "next" buttons 102, 104 as shown in FIG. 6 that he user selects when he or she has completed the desired task. If the next button is selected, the computer system runs the next script indicated. Conversely, if the previous button is selected, then the previous script (assuming there is a previous script) is run.

The following is another example of a script.

The above script illustrates several additional features of the help program. As indicated in connection with Step 220 described above, the help program operates to disable all the controls of the underlying program except for those controls that should be selected by the user. The script informs the help program which controls should be enabled at any given time. Once the help system has executed the first script for the desired task, it reads what options should be enabled. For example, in the diagram shown in FIG. 5, the user is only allowed to select the View menu. Therefore, everything is disabled except for the view menu.

Once the window has been properly set up and the appropriate controls enabled, the help program waits for a user-generated event, such as the correct mouse click or a menu selection in order to proceed to the next script.

When the next action specified by the script has been successfully completed by the user, the help program will execute the NextMonitorScript which was set in the current script. If ShowMe button was clicked, then the help program will execute the NextShowScript, which will fulfill the requirements set up by the first script, making the help program execute the NextMonitorScript.

The script files described above are manually generated by a script writer working with the underlying program, taking note of the next action that will appear on the screen and noting what controls should be accessed. The help program may call many scripts to complete a task. All the script files are preferably stored on a hard disk within the computer system. Having described how the script files drive the help program, the following describes how the help program itself is constructed. As will be appreciated, the help program is designed to be "dumb" so that it makes as few decisions as possible. Instead the script file dictates all the actions of the help program.

The help program is broken up into several functionally separate pieces. They are as follows:

OLE Automation Interface

COM Object interface

Method/Property handling

Script Execution

Window/Dialog/Control handling

Control subclassing

Windows CBT (Computer Based Training) hook and window subclassing.

Detecting step completion

Hatching

Display of the bubble

Menu handling

Media View control (text and pins)

OLE Automation Interface

Object Linking and Embedding (OLE) Automation is the means that is used for the script files to communicate with the help program. OLE Automation allows the script files to connect to the help program and call methods and properties within the help program. The properties and methods that are supported by the help program are listed below. OLE Automation is part of the Microsoft Windows OLE2 architecture, and is described in detail in a number of readily available books and therefore need not be discussed in further detail.

COM Object interface

The COM (Common Object Model) interface is another OLE interface that is used by the underlying program to interface with help program of the present invention. This is a much more limited interface which is used by the underlying program to start the help program and set some parameters in it. The interface is as follows:

The only methods that are necessary for starting and using the help program are the IUnknown members (since it is a COM object) and StartRUMBAAssist, CloseRUMBAAssist, and RunSBLScript methods. StartRUMBAAssist initializes the COM object, CloseRUMBAAssist uninitializes (but does not remove) the COM object, and RunSBLScript executes a script file (typically the opening script, which displays the menu). The Shared COM/Script functions are used to set variables that the script files can query. This is used to allow the running application to communicate with the scripts. The WdRasist.Ocx methods are not currently used since the help program was not made into an ocx. The SetScriptPath method tells the help program where in the hard drive directory structure to find the script files.

CreateCustomCtrlType allows the underlying program to set up a new control type. Control types are based on the class name of the window. Some controls have pre-defined class types (defined by the help program). For example, a button has the class name "button" and the help program type of TYPE.sub.-- BUTTON. A listbox has the class name "listbox" and the help program type of TYPE.sub.-- LISTBOX and so on for all the common control types. The TYPE.sub.-- identifiers are simply numeric values that the scripts use to identify different control types to the help program. For example, if the underlying program has a new control for the help program to be able to identify, the underlying program could set this as a new control type by calling CreateCustomCtrlType( "NewCtrlType", TYPE.sub.-- NEWCTRL) and the scripts could then identify controls with the class name "NewCtrlType".

The help program is started by the underlying program by performing a CoCreateInstance on the help program's COM object, and calling the StartRUMBAAssist method on the returned pointer.

Pitfalls:

Since the help program subclasses all the windows that an application brings up (or at least all the windows it wants to interact with) it is important to not release the help program's COM object from memory until ALL other windows have been destroyed. This is because the windows subclassed may get subclassed again, on top of the existing subclasses. If this happens, the help program cannot release its subclass and just puts the subclass procedure into a `passthru` mode that sends the data through to the next procedure in the subclass chain. If the help program is removed from the computer memory before this window has been destroyed, the help program will fault because the subclass procedure immediately preceding the help program's subclass procedure will try to call the help program's hook procedure, which no longer exists.

Method/Property handling:

Methods and Properties are called from the scripts. The scripts attach to the help program via the OLE Automation object, and the OLE Automation object calls the appropriate methods/properties in the help program. The methods and properties allow the scripts to control exactly what the help program does. A list of all the help program methods and properties are given below.

Script execution:

The help program uses the Softbridge Basic Language (SBL) to implement its scripts. SBL allows us to compile and execute the SBL scripts. When StartRUMBAAssist is called, the help program looks for all script catalog files (*.sbc) in the scripts directory (set by the SetScriptPath method in the COM object). Since there can be hundreds or thousands of script files, the scripts are pre-compiled and placed into a `catalog` file, to be extracted when requested. When the help program is told to execute a script, it will first search the catalog files for a script of the same name with .SBX (pre-compiled) appended to it. If it does not find it, it will search for the same file but with a .SBL extension (un-compiled) appended to it. If it still does not find the file, it will look for the .SBL file in the Script directory. If the file is found in the catalog, it is extracted to a read.backslash.write directory and compiled (if necessary) into an SBX file. The SBL SblRun function is then invoked the compiled file.

Scripts are executed when:

The criteria for the completion of a step is met (i.e.: a dialog is created, a button is clicked, etc.)

The user selects the `Next` or `Back` button

ShowMe is selected, causing the NextShowScript to be executed.

Do It All is selected, causing the help program to alternately execute the NextShowScripts and NextMonitorScripts until user action is required or all the steps are completed.

The current script tells the help program to automatically skip to the NextMonitorScript (Rumub.Skip=TRUE).

The client calls RunSBLScript on the help program's COM object interface.

Window/Dialog/Control handling.

The help program subclasses every window that it may care about. That includes the underlying programs main application window and all of its sub-windows (controls), and any dialogs that are brought up by the underlying program that the help program has been instructed to subclass (see WillCreateDialog and DialogCaption properties). This is so the help program can monitor what the windows are doing and respond accordingly. The following messages are intercepted:

Dialogs/Windows:

WM.sub.-- SETCURSOR

Used to eliminate unwanted mouseclicks.

WM.sub.-- COMMAND:

Used to eliminate unwanted menu item/control actions

WM.sub.-- NOTIFY:

Used to determine when the current tab on a tab control is changing

WM.sub.-- NCLBUTTONDBLCLK:

WM.sub.-- NCLBUTTONDOWN:

WM.sub.-- NCRBUTTONDBLCLK:

WM.sub.-- NCRBUTTONDOWN:

Used to keep user from sizing the main application window except on one side (the left edge is still active)

WM.sub.-- ENTERIDLE:

Used during menu selection to let the help program know when a menu popup is done painting.

WM.sub.-- SYSCOMMAND:

Used to keep the user from closing dialogs before the help program is done with them.

WM.sub.-- SIZE:

Used to keep the hatch window, help text bubble, and Next-Back dialog in the correct place and correct size

WM.sub.-- MOVE:

Used to keep the help text bubble and Next-Back dialog in the correct place and correct size

WM.sub.-- SHOWWINDOW:

Used to show the Next-Back dialog at the appropriate time and to update the hatch window.

WM.sub.-- INITMENUPOPUP:

Used to tell the help program that a new menu has been opened, and we need to reposition the bubble so it points to the appropriate item on the sub-menu.

WM.sub.-- MENUSELECT:

Tells the help program when a menu has been closed by the user. If we were looking to click on the menu, we need to go back and open the menu again at this point.

WM.sub.-- ACTIVATEAPP:

Tells the help program that we need to show the text bubble. We hide it when the application loses activation.

WM.sub.-- ACTIVATE:

Used to close any popups that the Media View.TM. help engine may have displayed.

WM.sub.-- WINDOWPOSCHANGING:

WM.sub.-- WINDOWPOSCHANGED:

Used to set the help program window behind the underlying program window in the Z-Order.

WM.sub.-- HELP:

Used so we can eliminate bogus help from appearing when help is invoked on the hatch window.

WM.sub.-- RBUTTONDBLCLK:

WM.sub.-- LBUTTONDBLCLK:

Used to eliminate unwanted double click events.

WM.sub.-- PARENTNOTIFY:

Sometimes a tab on a tabbed dialog box can be created dynamically, and we must subclass it. We get this message in the parent dialog box with a WM.sub.-- CREATE parameter to let us know to check for a new tab on the dialog.

Tabs:

Tabs on a tabbed dialog box are separate windows, and process a slightly different set of messages. They process a subset of the messages that a normal dialog would process, and use them for the same things. The help program only looks for the following:

WM.sub.-- SETCURSOR:

WM.sub.-- COMMAND:

WM.sub.-- SIZE:

WM.sub.-- MOVE:

WM.sub.-- SHOWWINDOW:

WM.sub.-- INITMENUPOPUP:

WM.sub.-- MENUSELECT:

WM.sub.-- NOTIFY:

WM.sub.-- WINDOWPOSCHANGING:

WM.sub.-- RBUTTONDBLCLK:

WM.sub.-- LBUTTONDBLCLK:

WM.sub.-- HELP:

Controls:

WM.sub.-- NCHITTEST:

Used to eliminate unwanted mouseclicks.

WM.sub.-- ENABLE:

Used to keep the application from changing the state of the control. We don't want a control being enabled by the underlying application when the help program explicitly disables it.

WM.sub.-- DESTROY:

Used to eliminate the information the help program keeps on all controls that are subclassed.

WM.sub.-- RBUTTONDBLCLK:

WM.sub.-- LBUTTONDBLCLK:

Used to eliminate unwanted double click events.

WM.sub.-- PAINT:

Used to monitor when the hatched window needs to be updated. If a control paints, it means that we need to repaint the hatched window on top of it or we get unhatched portions of the underlying program window showing through.

With the preceding set of messages captured from all the dialogs, tabs, controls, and windows the help program can effectively limit what the user is able to do by eliminating those messages it doesn't want the control to know about. It also uses the messages for its own internal state. These are used so the help program knows when the underlying program is active, when the underlying program has a menu item open, and when the underlying program is being moved around on the screen.

Control Subclassing

Controls are subclassed and their enabled/disabled state modified immediately after the execution of each script file. The help program enumerates all the controls on the current dialog/window (the last dialog that was subclassed, as discussed in the next section), subclasses them, and determines the state of each control based on the following parameters, which were set from the script.

DisableControls

Defaults to TRUE. This means that the default state for a control is disabled.

SetEnabledCtrl(Ex)(ControlId, ControlType)

Overrides the `disabled` setting for the control specified

SetRestrictedCtrl(Ex) (ControlId, ControlType)

Overrides the `enabled` setting for the control specified.

NextUserAction

A single id for a control that will cause the execution of the next script. Always enabled

NextActionCtrlType

The type of the NextUserAction control.

When a control is enabled, it is both enabled (not grayed out) and has a hole punched through the hatch. When a control is disabled, it is grayed out and covered by the hatched window.

One problem with this is that some controls are created dynamically, well after the routine that subclasses/enables/disables has executed. This means that one or more controls may not be subclassed and their state may not be set. This is worked around by using the Windows CBT hook, as described in the next section.

Windows CBT (Computer Based Training) hook and window subclassing

The help program uses a `Message Hook` to monitor certain events in the system. In particular, it uses the Windows CBT (Computer Based Training) hook to obtain three events from the running application (See SetWindowsHookEx() in the Microsoft Win32 API reference). The help program needs to know when a window is created, activated, or destroyed. This information is used to determine what windows are to be subclassed as described above. The help program takes the following actions:

HCBT.sub.-- CREATEWND

Check to see if a script has finished executing. If it has, then this could be a new control that should be subclassed and hatched over. This is the case with dialogs that get subclassed, then have controls dynamically created on them.

HCBT.sub.-- ACTIVATE

Check to see if the window that was activated is one of the windows that the help program are looking for. That is, in the script, the script developer specifies that he is expecting a new dialog or window to appear and tells us the title of that window. In the code for this action, the help program determines if the window that was activated is the one it is looking for. Many times, however, the window doesn't have the title set when the help program gets the activate message. The window is usually not visible at that time either. In this case, the help program subclasses the window with a `WaitProc` which just waits for the WM.sub.-- SHOWWINDOW message, unsubclasses itself, and checks for the title. When the help program determines that it has the correct window, it subclasses it and the tab (if it is a tabbed dialog box) that was specified in the script (should be the tab that is currently visible). If the help program subclasses the dialog and WillCreateDialog is true, then the help program launches the NextMonitorScript.

HCBT.sub.-- DESTROYWND

This method checks to see if it is one of the windows that the help program has subclassed. If it is, the help program unsubclasses at this time. It also must adjust the hatch window to hatch the previous dialog (the dialog/window that was subclassed just before the current dialog). It is here that the help program checks the WillCloseDialog property. This is the opposite of the WillCreateDialog, in that it waits for the dialog to close. When it closes, if WillCloseDialog is true, the help program launches the NextMonitorScript.

Hatching

The disabling is accomplished by creating a semi-transparent window (shown as 100 in FIGS. 5 and 6) that paints a pattern of dots over what is currently on the window shown to the user. To accomplish this, the help system uses a feature of the Microsoft Win32 API. A transparent crosshatched window is created which gets painted on the screen after all updates have been painted. This allows any dialog boxes to be updated before they are disabled.

The crosshatched window, since it is transparent, will receive a WM.sub.-- PAINT message of its own, so that it can refresh and redraw the hatch on top of any existing dialog boxes in the window. However, there are some limitations. The transparent window does not always receive a WM.sub.-- PAINT message when a control is painted. In order to get around this problem, everything that the hatch window covers must be "subclassed," meaning that the help program gets to interpret messages sent to the windows before they get to the control. The help program lets the control paint and sets a timer waiting for all painting to subside before painting the hatch over the controls.

The crosshatched window does not cover all the controls on the window screen, otherwise the user would not be able to perform any function. Therefore, the semi-transparent window has holes punched in it where the controls can poke through and be operational. This is accomplished using the "SetWindowRegion" function provided by the Win 32 API which allows a window to be broken into numerous regions. The script file tells the help program what controls it wants to be enabled using the control's ID and control type (i.e., TYPE.sub.-- MENU, TYPE.sub.-- BUTTON, TYPE.sub.-- LISTBOX, etc.), in order to get a placement on the screen of the control itself.

Detecting step completion

A step is complete when the criteria set up by the script is met. Using the subclassing and the CBT hook, the help program can determine when certain events occur. The help program waits for the events that will cause it to launch the next script. In the first script described above, the help program waits for the user to select the IDM.sub.-- WATERMARK command from the menu. Since the help program also sets the WillCreateDialog property, the program will actually wait for a dialog with the title "Configure Watermark" to appear. This event is noticed in the HCBT.sub.-- ACTIVATE event (described above). If WillCreateDialog was not set, then the help program would proceed to the next step as soon as it detected the WM.sub.-- COMMAND message for IDM.sub.-- WATERMARK. Of course, since the help program would not be expecting a dialog to appear the dialog would not be subclassed.

With the hook procedure and the subclassing, the help program can detect all button/mouse clicks, creation/destruction of windows, menu item selections, tabbed dialog tab changes, listbox/combobox selection changes, and nearly any other user action. Unfortunately, this is not enough. Suppose, for example, the user wants to configure a checkbox. A checkbox can be either `checked` or `unchecked`. The checkbox in question is completely arbitrary, in that it is completely a user preference so there is no right or wrong state for the control. The help program will have no idea when the user is finished configuring that control, so it has no way to detect that the step has completed. The only solution is for the user to tell the help program when he/she is finished configuring the option. This is accomplished with the Next/Back dialog. The script writer will know when this sort of problem will exist, so in the script will be the command:

SetNextBackScripts("XWatMrk4","XWatMrk2")

This brings up a small dialog box that tracks with the dialog we are currently working with a Next and/or Back button on it. The XWatMrk4 and XWatMrk2 parameters are the scripts that are to be executed if the Next or Back button is pressed, respectively. This is how a step can be completed without the script having to know what the final state of the control must be.

Displaying the Bubble

The bubble is just sort of a helping hand to lead users through the sequence of steps required to complete a task. The text the bubble displays is dynamic and can be changed from the script files. The bubble will appear if the script indicates a timeout value as well as specifies (directly or indirectly) something for the bubble to point to. The bubble window itself is a region window, much like the hatch, built from two ellipses and two triangles. One ellipse and one triangle are used for the bubble itself, and the other set is used for the shadow. The help program simply figures out how big the ellipse should be (depends on the text ), where the `tail` or `pointer` triangle should be. The Windows SetWindowRgn function is used to cut it out of its surrounding (rectangular) window. The bubble finds its position in the same way the hatch window knows where to punch holes in the hatch. It has a control id and a control type, which can be used to find the rectangle of a control. When pointing to a menu item, it uses the menu selection code (described in the next section) to find the position where it should place the bubble.

Menu handling

Windows menus can be very difficult to work with, especially with Window NT 3.51 and below. In older versions of the OS, there is no easy way to find the rectangle bounding a menu item. In newer versions (those with the new shell) it is less difficult.

The following is a description of the logic the help program uses to finding a menu.

The difference in getting the menu item rectangles between the old (preWindows 95) interface and the new interface is that Windows 95 implements a very handy function called GetMenuItemRect. This function has some problems, but it works great to find the top level menu items, which are the more difficult ones to obtain. The help program uses the method described above to find sub-menu items no matter what user interface is being used.

In order for this algorithm to work, both the height of a menu item and the height of a menu separator must be computed. The menu item is easy: In Windows 95 just call GetMenuItemRect on a menu item in a popup window (popup window must be visible), in older versions just use GetSystemMetrics(SM.sub.-- CYMENU) to obtain the height. Separators are more difficult. When a popup is opened, it must be determined if the popup has any separators. If it does, the number of separators and menu items on it must be counted. Calculate the height of the popup window using GetClientRect on the popup, then subract off the height of all the menu items. What is left is the combined height of the separators. Divide by the number of separators and the height of a single separator is determined.

Mediaview control

The help program of the present invention uses the Microsoft's Mediaview.TM. 1.3 library with a 3rd party OCX wrapper to display the text/menus/lessons associated with the scripts. This is just a typical help engine, which is embedded in an OLE frame window. When the user selects an option from the menu presented by Mediaview, the help program of the present invention receives an event, which tells it to run a macro. The macro name is the name of the script file, which is promptly executed. Any sort of menu system could be used for this, but using a help engine has the advantage of already supporting context jumps and such.

Given the above description of how the help program of the present invention operates, the following are the properties and methods to be implemented. It is considered to be within the skill of a computer programmer with Windows.RTM. experience to complete the source code. ##SPC1##

As can be seen from the above, the present invention provides an interactive help system whereby a user is shown how to complete the steps required to complete a desired task. In addition, the steps performed by the user are actually implemented on the underlying program being run by the user. Therefore, when the user leaves the help system, the changes made while the help system was operating will have been implemented. The present invention does not require the user to memorize the list of steps described in the help system and then attempt to recreate them without the benefit of the help system running at the same time. Furthermore, because the present invention disables that portion of the screen containing options not available to the user, the chance that a user will make a mistake during the help process is minimized.

While the preferred embodiment of the invention has been illustrated and described, it will be appreciated that various changes can be made therein without departing from the spirit and scope of the invention.