System and method for improved computer-based training5627958Abstract The present invention includes a computer-based training system (CBT) having one or more Application Translation Units (ATUs), a message engine, and a script engine. For one or more target applications of interest, an ATU is provided for processing events specific to that application, thereby trapping events and translating them into abstract messages or "meta-messages" for conveying information about a particular event to the system. A general operating system ATU is also provided for trapping general system events. Translated event messages are processed by event handlers. System or application-specific messages which are not of interest are simply allowed to pass through. The individual handlers dispatch their respective messages to the script engine, which includes instructions for directing the activity of the target application(s). The script engine, in turn, acts upon an incoming message. The dispatched message triggers appropriate action (as specified by instructions within the script). Claims What is claimed is: Description COPYRIGHT NOTICE
______________________________________
while (GetMessage (&msg, NULL, 0, 0))
{
TranslateMessage (&msg) ;
DispatchMessage (&msg) ;
}
return msg.wParam ;
______________________________________
where a message (&msg) is retrieved by a call to GetMessage (step 263); if needed, the retrieved message may be translated by a call to TranslateMessage() and then dispatched by a call to DispatchMessage (step 269). This "while" loop continues until the GetMessage function returns a value of zero--indicating that the loop has read a WM.sub.-- QUIT message from the queue, telling the application to end (yes at step 265). In addition to the messages generated by Windows, applications can create their own messages and place them in the application queues of other applications. The SendMessage and PostMessage functions let applications pass messages to their windows or to the windows of other applicatiens. The PostMessage function directs Windows to post the message by placing it in the application queue. Control returns immediately to the calling application, and any action to be carried out as a result of the message does not occur until the message is read from the queue. The SendMessage function, on the other hand, directs Windows to send a message directly to the given Windows function, thereby bypassing the application queue. Windows does not return control to the calling application until the Windows function that receives the message has processed it. Such an unqueued message, however, is generally a message that affects the window only. The general mechanism for retrieving and dispatching messages in an event-based system, such as Microsoft Windows, is known in the art; see, e.g., Petzold, C., Programming Windows, Second Edition, Microsoft Press, 1990. Additional information can be found in Microsoft's Window Software Development Kit, including: 1) Guide to Programming, 2) Reference, Vols. 1 and 2, and 3) Tools, all available from Microsoft Corp. of Redmond, Wash. The disclosures of each of the foregoing are hereby incorporated by reference. Computer-Based Training System The following description of the CBT system of the present invention will focus on the presently preferred embodiment which includes components implemented in an event-driven architecture with the C++ programming language. In particular, an object-oriented model is adopted whereby new objects may be created from existing objects (classes). The general features of C++, including data encapsulation, inheritance, and polymorphism, as well as C++ techniques for implementing class hierarchies and class methods are known; see e.g., Ellis, M. and Stroustrup, B., The Annotated C++ Reference Manual, Addison-Wesley, 1990. Additional information about object-oriented programming and C++ in particular can be found in Borland.RTM. C++ 3.1: 1) User's Guide, 2) Programmer's Guide, and 3) Library Reference, all available from Borland International of Scotts Valley, Calif. The disclosures of each of the foregoing are hereby incorporated by reference. A. Overview Referring now to FIG. 3, a computer-based training system 300 of the present invention includes one or more Application Translation Units (ATUs) 340, a Message Engine 350, and a Script Engine 330. Also shown, the system 300 includes a CBT window object 370 operably coupled to the Script Engine; CBT window object 370, in turn, may be linked to one or more custom Dynamic Link Libraries (DLLs) 380. Driven by a set of instructions or script 320, the system 300 monitors various events of the Windows system and desired target applications. Messages from these events, including system messages 310 and target application messages, are trapped by the ATUs 340 and reported to the Message Engine 350 as CBT messages. The Message Engine, in turn, dispatches the messages according to handlers specified by the Script Engine 330, operating under the control of script 320. Messages of interest are processed as desired; others are simply allowed to pass through. The construction and operation of these components will now be described in further detail. 1. Application Translation Units and Their Target Applications In normal operation of the system 100, a user is using one or more Windows application programs, for example, programs 145 of FIG. 1B, which can be a spreadsheet, wordprocessor, database, or the like. For each application where CBT support is desired, an application-specific ATU 340 is provided for processing events specific to that application (now shown as target application 360 in FIG. 3). Thus, each ATU 340 is a module, preferably implemented as a dynamic link library (DLL), for processing messages for a specific target application. In addition to the application-specific DLLs, ATUs 340 include a Windows ATU. In contrast to the other ATUs which hook into specific target applications, the Windows ATU processes all Windows events, including system messages 310. In this manner, general system events, that is, ones not specific to any particular application, may be processed by the CBT system 300 as well. Whether application specific or not, each ATU functions to trap events and convert them into "CBT messages"--a lingua franca or common language for all events, whether Windows or application-specific, occurring within the system. More particularly, a CBT message is a meta-message, that is, a high-level message describing one or more events which have occurred. For instance, instead of monitoring numerous, low-level system messages, such as WM.sub.-- RBUTTONDOWN, WM.sub.-- LBUTTONDOWN, WM.sub.-- RBUTTONUP, WM.sub.-- LBUTTONUP, and the like, the user/script writer need only monitor a single message CBT.sub.-- MOUSECLICK; the task of determining what the Windows system or application is doing is left to the ATUs. By abstracting low-level system messages into highlevel (and more meaningful) CBT messages, the system of the present invention greatly simplifies script design and writing. A CBT message, which is stored internally as an integer, represents a particular type of event. Information or data particular to each event, such as active window, cursor location, and the like, on the other hand, are packaged as a discreet data object (EventInfo object) fully describing the event. EventInfo objects, along with CBT messages, are dispatched from the ATU to the Message Engine 350 for further processing. 2. Message Engine and Script The Message Engine 350 determines which of the many CBT messages it receives is of particular interest to the CBT system, as it operates under the direction of a script 320. At startup, each target application of interest to the script 320 is registered with the Message Engine. The script 320, which itself includes a collection of objects, may be compiled, pre-compiled, pseudocompiled, or the like, as desired for a particular platform. In a preferred embodiment, script 320 is pre-tokenized, whereby source listings and comments (optionally) are stored in a compact form which may be reconstructed into the original source. Thus, script 320 need only be a set of instructions; no particular format is required by the present invention. For each application registered, the Message Engine maintains one or more "handlers" or modules for processing events specific to that application (as represented by the CBT messages). Thus, the Message Engine manages a list of target handlers for determining which CBT messages are of interest to the script 320, that is, which messages map into the list. Messages which are of interest to the system, i.e., those specified by the script 320, are trapped and forwarded to a designated handler. Those messages which are not of interest are allowed to "fall through" (i.e., be passed on to) the individual target applications 360. In essence, the Message Engine filters the events for a particular application so that only those of interest, that is, those having a handler defined for the event, are processed. B. System operation 1. Method: CBT Session Referring now to FIGS. 4A-B, the general method of operation for the system 300 is illustrated by a flowchart 400. While the general methodology remains the same from one CBT session to another, the reader should understand that the specific steps of any one CBT session are dictated by instructions and script objects defined in the script 320. For instance, the script 320 states which specific target applications will be registered with the Message Engine and which events of those applications will be dispatched. Thus, the following description illustrates the basic framework in which the CBT system operates. Under the direction of the script 320, at step 410 the CBT system registers a target application of interest by creating a CBTApplication object. Serving as the main entry point for the CBT system, this object initializes and executes the script tutorial. Moreover, the object initiates sessions with the Message Engine and Script Engine and acts as a centralized dispatch point for all external functions and object method calls within each CBT lesson. From here individual CBT lessons are loaded and performed. When a lesson script is loaded the CBTApplication object creates a CBTLesson object which is responsible for managing that particular lesson. The CBTLesson object reads the lesson script and builds a deck of CBTScene objects, with each corresponding to a scene described in the lesson script. Alternatively, each scene may be constructed on-the-fly, particularly in high-performance environments. The CBTLesson object resembles a state machine; it maintains the active scene (active state) and sends appropriate script scenes (CBTScene objects) to the Script Engine 330 for presentation. Each object is directly accessible to the script writer through script variables; for example, the CBTApplication object is accessed through a theCBTApp global variable, the CBTLesson object through a theCBTLesson global variable. To complete the initialization of step 410, the target application is registered with the Message Engine 350. In particular, hooks are installed by a corresponding ATU 340 so that events within the target application of interest are trapped. As set forth below, these events will, in turn, be reported to the Message Engine 350 as CBT messages. At step 420, script-specified links are established to individual resources of interest. Within the target application itself, various resources (e.g., buttons, menus, and the like) may be of interest to the script writer. For example, if one were interested in a particular button of the target application, such as a "help" button, that button may be registered with the Message Engine 350. Events associated with that button (e.g., "mouse enter" the button) are then trapped for processing by an ATU. The links are specified within the CBT script 320 as follows. In a preferred embodiment, a link is established to an individual resource or control by indicating a selected one of its Windows class name, Window title, or Resource ID, all of which are readily accessible Windows data structures. Commonly, a link will be established by using the Resource ID. Particular links may be created or removed during a session, as desired. At step 430, the system traps various events which are relevant to the established links. This operation, shown in further detail in FIG. 4B, occurs as follows. Every time that a message arrives at the message queue of a target application, a message filter hook function (WH.sub.-- MsgFilter) 431 is called. First, the hook function determines if the message represents a task which has been "hooked, " that is a specific link for this event of the target application has been created. If not, the event is passed down the hook chain for processing by one of the other hooks (i.e., hooks 433, 435, 437). The Windows hook 437, for example, traps all window messages (WM.sub.--). In this fashion, which hook function is invoked depends on what type of message comes into the target application. By way of illustration, hooks may be installed as follows:
__________________________________________________________________________
BOOL installHooks(CbtEntry *pEntry)
if( ! pEntry
return FALSE;
// Note that the fourth parameter below may receive a task handle of
// a target application, whereupon the hook is installed in that
// application. When receiving a NULL parameter, the hook installs
// to applications.
// CBT hook -- allow CBT system to stop events from progressing
hCBTHook =
SetWindowsHookEx(WH.sub.-- CBT, (HOOKPROC)cbtFilter, hInstance, NULL);
// Msg filter hook -- dialog boxes and menus
hMsgHook =
SetWindowsHookEx(WH.sub.-- MSGFILTER, (HOOKPROC)msgFilter,
hInstance, NULL);
// Get msg hook
hGetMsgHook =
SetWindowsHookEx(WH.sub.-- GETMESSAGE, (HOOKPROC)getmsgFilter,
hInstance, NULL);
// Windows hook
hCallWndProcHook =
SetWindowsHookEx(WH.sub.-- CALLWNDPROC, (HOOKPROC)callWndProcFilter,
hInstance,NULL);
return( hCBTHook
&& hMsgHook &&
hCallWndProcHook
&& hGetMsgHook );
}
__________________________________________________________________________
As shown, a callback function is installed for each hook; each callback function, in turn, serves as an entry point into an ATU. Additional information on the installation and use of hooks in Microsoft Windows can be found in the Microsoft's Window Software Development Kit referenced above. In addition to installing hooks to trap system messages, one or more application-specific hooks (callback functions) 439 are installed as well. For instance, a target application may be a spreadsheet which includes its own internal set of messages, for example, SS.sub.-- CELLSELECT, SS.sub.-- CELLEDIT, SS.sub.-- BLOCKDEFINE, and the like. To monitor these messages, an ATU may register an application-specific callback function with the target application, in effect dynamically binding the ATU to its target application. At runtime, the application invokes the callback function for dispatching internal or application-specific messages. Thus, the CBT system of the present invention is not limited to Windows events and their messages; instead, the CBT system may receive and translate any messages of interest, whether system wide or strictly internal. At step 440, events which are trapped by the Application Translation Units 340 are "dispatched" to the Message Engine 350 as CBT message/event information objects. As shown in particular detail in FIG. 4B, the dispatch module of each ATU includes a function corresponding to each Windows event. Thus, for the WM.sub.-- COMMAND, WM.sub.-- MENUSELECT, WM.sub.-- BUTTONDOWN, and WM.sub.-- SETCURSOR messages, the following translate functions may be defined:
______________________________________
int doWM.sub.-- Command
(CbtEntry *pEntry, MSG *msg);
int doWM.sub.-- MenuSelect
(CbtEntry *pEntry, MSG *msg);
int doWM.sub.-- ButtonDown
(CbtEntry *pEntry, MSG *msg);
int doWM.sub.-- SetCursor
(CbtEntry *pEntry, MSG *msg);
______________________________________
each designed for processing its particular event. The operation of an ATU dispatcher will be demonstrated by the processing of Windows messages for determining if the cursor has traversed a window boundary (i.e., entered a new window); this example illustrates how a multitude of Windows WM.sub.-- SETCURSOR messages can be converted into MOUSELEAVE and MOUSEENTER meta-messages. The dispatching of other events as CBT messages is set forth hereinbelow as Appendix A. As shown in FIG. 5A, a doWM.sub.-- SetCursor dispatch method 500 is invoked whenever a SetCursor message is trapped by the ATU (i.e., captured by a hook function before the event has been received by the application). Here, the script writer is not interested in the screen cursor simply entering an already active window; thus, the method simply "allows" the Windows message to be passed to the target application at step 501 and returns. Specifically, since the screen cursor is entering a window which is already active, no particular CBT-generated messages or other intervention are desired by the script writer at this point; hence, the WM.sub.-- SETCURSOR message is allowed to pass through. Continuing the example, the script writer may specify that the event of a cursor leaving an active window is of interest and should be trapped. Since the cursor is not simply re-entering the active window (no at step 501), the window which the cursor is leaving should be notified of the event. The CBT system notifies the Message Engine of this action as follows. First, at step 502, the information pertaining to the window where the event occurred is encapsulated into a C++ object (which is derived from an EventInfo class hierarchy, described in further detail hereinbelow). At step 503, the information object and a "MouseLeave" message are dispatched to the previous (departing from) window, with the message being denoted as a "NOTIFY" message. In a preferred embodiment, two different classes of messages are provided: CBT.sub.-- NOTIFY and CBT.sub.-- CONFIRM. Those messages which are purely informational, such as mouse movements, are CBT.sub.-- NOTIFY messages. Those which can be stopped before they reach the target application, on the other hand, are called CBT.sub.-- CONFIRM messages. Each is registered with Windows as an application-specific Windows event. Using two methods defined within EventInfo objects, the script 320 can allow or prevent a CBT.sub.-- CONFIRM type message from reaching the target application. Specifically, a stopMessage method is invoked which determines (based on script instructions) whether to allow the message to pass through to the target application. After step 503, the method proceeds to alert the Message Engine that the cursor is entering a new window. In a manner similar to sending the "MouseLeave" message, the method first builds an EventInfo object at step 504. Next, a "MouseEnter" message of type CBT.sub.-- NOTIFY is dispatched to the application, along with the information for the event (EventInfo object), at step 505. At step 506, an active window flag is set; this is the flag that is read in step 501 to determine if the mouse cursor is entering the active window. Finally, the method concludes by passing the message on to the application (i.e., "allow" message) at step 507. At the conclusion of the method, memory for the EventInfo objects may be recovered (e.g., using manual or automatic garbage collection techniques). For purposes of illustration, one may implement such a method in the C++ programming language as follows:
__________________________________________________________________________
int doWN.sub.-- SetCursor(CbtEntry *pEntry, MSG *msg)
EventInfo *pObject = (EventInfo *)NULL; // init EventInfo
if( pEntry->hActiveWnd == (HWND)(msg->wParam) )
// steps 510/507
return MSG.sub.-- ALLOW;
pObject = new WindowInfo( pEntry->hActiveWnd );
// step 502
DispatchToCbt (pEntry, CBT.sub.-- NOTIFY,
TM.sub.-- MOUSELEAVE, (LPARAM)pObject);
// step 503
pObject = new WindowInfo( (HWND)(msg->wParam) );
// step 504
DispatchToCbt(pEntry, CBT.sub.-- NOTIFY,
TM.sub.-- MOUSEENTER, (LPARAM)pObject);
// step 505
pEntry->hActiveWnd = (HWND)(msg->wParam);
// step 506
return MSG.sub.-- ALLOW; // step 507
// garbage collection performed by the system
}
__________________________________________________________________________
Here, pEntry is a pointer to a record, CbtEntry, which is updated. The record includes handles to the hooked task (application that has been hooked) and the currently active window:
______________________________________
typedef struct .sub.-- CbtEntry {
HTASK hHookedTask;
HWND hActiveWnd;
} CbtEntry; // pEntry points to this
______________________________________
As shown, a meta-message may maintain its own data structures for tracking events at a higher level (e.g., the status of the active window). The DispatchToCbt function, on the other hand, is conveniently viewed as two halves of a process. Specifically, the Message Engine registers a callback function with the ATU. The operation proceeds as follows. On the ATU side, the ATU passes to the DispatchCBTMessage method a task handle for identifying a particular application; since the system processes multiple applications, this mechanism serves to distinguish between different applications (and their instances):
__________________________________________________________________________
void DispatchToCbt(HTASK hHookedTask, UINT Msg, WPARAM wParam, LPARAM
lParam)
if( pCbtDispatchFunc )
(pCbtDispatchFunc)(hHookedTask, Msg, wParam, lParam);
}
__________________________________________________________________________
In this manner, an ATU filters or groups events by target application and communicates its events as meta-messages to other CBT components. At the completion of step 440 of FIG. 4A, the ATU has dispatched the CBT message, its type, and the EventInfo object to the Message Engine 350, thereby fully communicating an event which it has trapped. Not all events are of interest, however. Thus, the events should be filtered so that only those of interest are acted upon. At step 450, the Message Engine performs this task by comparing the CBT message against known event handlers. In other words, the engine attempts to dispatch CBT messages of interest--ones having a handler define for the event. Thus on the Message Engine side, the Message Engine determines which entry in its table corresponds to that task:
__________________________________________________________________________
void CALLBACK MessageEngine::DispatchCBTMessage(HTASK hTarget,
UINT cbtmsg, WPARAM wParam, LPARAM lParam)
CbtSession *pSession = GetSessionFromTask(hTarget);
if( pSession )
SendMessage(pSession->hMsgPane, CbtMessages[cbtmsg],
wParam, lParam);
// Notify application handler
// where pSession is the current application session
// (determined from hTarget);
// CbtMessages[cbtmsg] is the table lookup for the
// CBT message ("confirm" or "notify";
// wParam is the CBT message type (TM.sub.-- msg); and
// lParam is a pointer to the EventInfo object.
}
__________________________________________________________________________
With particular reference to FIG. 4B, this process is illustrated. Message Engine filters CBT messages through a plurality of message handlers, including, for example, a TargetApplication handler 451, a TargetWindow handler 453, a Custom handler 455, and a Default handler 457; other exemplary handlers are set forth hereinbelow as Appendix B. CBT messages of interest will be passed to a particular handler. As shown in Appendix B, each message belongs to a particular Message Handler Class and is either informational (CBT.sub.-- NOTIFY) or preventable (CBT.sub.-- CONFIRM). A "mouseEnter" message, for example, belongs to a TargetWindow Handler Class; the message is therefore processed by the TargetWindow handler 453. An application specific event, such as an SS.sub.-- EDITCELL message from a spreadsheet target application, on the other hand, would typically be passed to the TargetApplication handler 451. Finally, messages without a handler, that is, those which the script writer has no particular interest, may be passed to a default handler (e.g., for ignoring, discarding, or otherwise invoking a desired default action); thus, the script writer need only enumerate handler methods for messages of interest. If matched with a handler, the message is then dispatched. Specifically, the handler extracts properties for the message and the accompanying EventInfo object. For a message of TargetWindow handler class, for instance, available object properties include: 1) Name: Title string of the control; 2) Class: Windows class of the control; 3) ID: Resource ID of the control; 4) Style: Style flags of the control; 5) Enable: Whether the control is enabled; 6) Position: Coordinates of the control; and 7) EventInfo: Current EventInfo object, if any. Additional exemplary properties which are available for various messages handler classes are set forth hereinbelow as Appendix C. As an alternative to defining several event handlers, a more preferred embodiment provides only two basic event handlers: an Application Link handler and a Window Link handler. Each is an object having various handler methods for appropriately responding to each message passed. Based on the lookup performed by the Message Engine (i.e., NOTIFY or CONFIRM), an Application Link handler may, for example, effect the dispatching as follows:
__________________________________________________________________________
RESULT CALLBACK ApplicationLink::wndProc(HWND hwnd, UINT Message,
WPARAM wParam, LPARAM lParam)
// First, get handler (from link registered)
ApplicationLink *pWindow = (ApplicationLink *)GetWindowLong(hWnd, 0);
if( pWindow )
{
if( Message == CBT.sub.-- notify // Msg is a NOTIFY msg
{
EventInfo *pInfo = (EventInfo *)lParam;
// Recall that Event info includes one or more of a win class,
// name, and resource ID. If exact information is not provided
// (e.g., just "OK" button), do "fuzzy" match (i.e., match as
// much as possible:
pWindow->doDispatchNotify(wParam, pInfo);
pInfo->Finished( );
return TRUE;
}
else if( Message == CBT.sub.-- confirm ) // Mag is a CONFIRM msg
{
EventInfo *pInfo = (EventInfo *)lParam; // Event info
pWindow->doDispatchConfirm(wParam, pInfo);
pInfo->Finished( );
return TRUE;
}
}
// on return, call WinProc instantiated w/ applic. link
return DefWindowProc(hWnd, Message, wParam, lParam);
}
__________________________________________________________________________
Here, the doDispatch- methods communicate directly with the Script Engine. In turn, the Script Engine responds according to script objects defined within the active script. By invoking the stopMessage method for specifying whether an event is allowed, for example, events may be stopped from reaching a target application; in most instances, however, the script writer will simply specify the default--that the event should simply pass on through to the target application. The scriptwriter may provide methods for handling the various events of interest, or he or she may rely on default methods which are defined by the CBT system. In operation, a CBT message is passed to the objects. Each object, in turn, is responsible (through its method definitions) for knowing which messages are of interest, and how each one of interest should be processed. In a target application, for example, if the script writer hooks a window link up to a list box of the application, he or she should provide methods for handling the event (as communicated by CBT messages) of that list box. Referring now to FIG. 5B, the overall method of dispatching messages is summarized. In a doDISPATCH method 520 of the present invention, a CBT message arrives at the message engine and is processed as follows. First, in step 521, an attempt is made to match the message to an application link handler. If the attempt is unsuccessful (no at step 522), then the message is simply allowed to "fall through" (i.e., left unprocessed, or processed by a default handler). Otherwise (yes at step 522), at step 523 the message engine forwards the CBT message (with EventInfo object) to the identified application link handler. At step 524, the application link handler examines the EventInfo object and attempts to match it with a registered window link. If this step is unsuccessful (no at step 525), then a default handler will be assigned for processing the event at step 526. At step 527, the message is forwarded to the window link handler. The window link handler, in turn, dispatches the message to the script engine at step 528. At this point, the script engine identifies the event by mapping the message into its set of known reserved words. At step 529, the script engine processes the message according to the instructions of the script (i.e., effects the action desired by the script writer, as indicated by the use of the matching reserve word). Upon completion of this step, the method has successfully dispatched the meta-message, with appropriate actions being effected in response to that message. 2. Building CBT Lessons As a tutorial is designed, the CBT script writer creates a "storyboard" showing the visual appearance as well as the flow of the tutorial. The storyboard becomes the basis for the CBT lesson script. CBT scripts are written in a simple language which contains both message handling and object-oriented features. Each lesson script is organized as a collection of scenes, with each scene describing the actions that take place at a particular point in the lesson. For example, a scene might instruct the CBT system to display a window containing some text when a particular menu item is chosen in the target application. As the lesson script proceeds, new scenes can be performed. This process continues until the user chooses to exit the CBT or the lesson is finished. To control the target application, the CBT system intercepts all Windows events for the application and translates them into CBT messages. These messages will trigger any corresponding message handlers which are defined within a scene. When a message handler is triggered, its script is executed. Within each scene, message handlers are defined for each UI control in the application which is of interest. For example, to respond to a button click within the script the following handler is defined:
______________________________________
script for Scene1
TargetButton theButton(120)
on theButton.buttonClick
theCBTLesson.perform("Scene2")
end
end
______________________________________
This hypothetical scene creates a TargetButton object which is linked to the UI control in the target application; the UI control Resource ID is 120. Next, a Message Handler is defined for the buttonClick message from the TargetButton object. When this message is received, the Script Engine performs a new scene, Scene2. Thus, the statement:
______________________________________
theCBTLesson.perform("Scene2")
______________________________________
calls the perform method of the global object "theCBTLesson" (the CBT Lesson object). In addition to controlling user actions, the CBT lesson also drives the target application autonomously by sending appropriate messages. Alternatively a sequence of events can be recorded (e.g., using a tool similar to MS-Recorder) for later replay. The script may also query the target application for its current properties. If a window link is established to a button, for instance, the script may query the button for its properties, such as its size, its title, and the like. One should note that the ability to query for properties operates independently of the processing of events and their messages. As another example, a target application could be asked to enumerate all the buttons of a dialog box. The script may, in turn, act on the queried information, including modifying selected resources. In this fashion, the resources of a target application may be dynamically varied, thereby providing the target application with an alternative user interface--one having UI components which may be altered on the fly. Appended herewith as Appendix D is a source listing illustrating an exemplary script syntax and methodology for operating the CBT system of the present invention. Additional reference materials illustrating a preferred script syntax are appended herewith as Appendix E. 3. Multiple-application Lessons As shown by FIG. 3, the system of the present invention is operative with one or more applications 360. More particularly, according to the present invention, a single script 320 may be employed to not only control multiple applications concurrently, but also control interaction between multiple applications. A script may be provided for tutoring the user in the operation of cutting and pasting between applications, for instance, cutting text from a word processor and pasting it into a database application. Thus, the CBT system 130 is not application bound; instead, it is a complete subsystem--one which may control multiple applications, including interactions between applications and/or the operating system, even launching additional applications as needed. 4. Event Information (EventInfo) Objects An EventInfo object, which stores information about a particular event, is instantiated from an EventInfo class 550. FIG. 5C illustrates the EventInfo inheritance tree and lists the properties for each class. As shown, the EventInfo class hierarchy 550 includes nine derived EventInfo classes which contain the state information about the various standard CBT messages. At the root of the hierarchy is the EventInfo base class 551. In a preferred embodiment, this class may be constructed with the following C++ class definition:
______________________________________
class SHARED.sub.-- CLASS EventInfo :
public CbtObject,
public pEventInfo {
public:
ATOMTABLES(Keyword, 7)
protected:
HWND hwndTarget;
BOOL bAllowMsg;
BOOL bIsProcessing;
public:
EventInfo(HWND hwnd);
virtual .about.EventInfo( );
virtual
int Supports(hProtocol &Hdl) const;
inline
HWND WindowHandle( )
const;
virtual
const char *
WindowName( )
const = 0;
virtual
const char *
WindowClass( )
const = 0;
virtual
int WindowId( ) const = 0;
virtual
LONG WindowStyle( )
const = 0;
virtual
BOOL AllowMessage(BOOL bFlag, BOOL
bState);
virtual
BOOL ProcessingMsg( ) const;
virtual
void Finished( );
inline
void * operator new(unsigned size);
inline
void operator delete(void *p);
ATOMMETHODS(Keyword)
CLASSMETHODS(EventInfo, "EVENTINFO")
};
______________________________________
As shown, the EventInfo class 551 provides access to the Windows name and its class, its resource ID, its Windows style, and whether the message is allowed (according to the script 320). Derived from EventInfo class 551 is WindowInfo class 552, a pure virtual base class for other EventInfo classes. The subclass affords the same four pieces of information which were provided by the base class 551. In addition, for a given window handle, the object will extract a window name, class, ID, and style. The class may be constructed with the following C++ class definition:
______________________________________
class SHARED.sub.-- CLASS WindowInfo : public EventInfo {
protected:
int iWindowId;
LONG lWindowStyle;
char * strWindowName;
char * strWindowClass;
public:
WindowInfo(HWND hWnd);
virtual .about.WindowInfo( );
virtual int Supports(hProtocol &Hd1) const;
virtual const char *
WindowName( )
const;
virtual const char *
WindowClass( )
const;
virtual int WindowId( ) const;
virtual LONG WindowStyle( )
const;
CLASSMETHODS(WindowInfo, "WINDOWINFO")
};
______________________________________
In addition to the windowing information, other events are also of interest, particularly mouse and keyboard events. These other events are accessible through subclasses of WindowInfo class 552. Specifically, the WindowInfo class spawns five subclasses: WinHelpInfo class 561, WinPositionInfo class 563, WinShowInfo class 565, WinSelectInfo class 567, and KeyboardInfo class 569. As shown, objects may be instantiated from these subclasses for accessing help text, window position, menu information, keyboard events, and the like. WinHelpInfo, for instance, contains the text which was sent by the WinHelp engine to the CBT. This text can be a sequence of script statements which are executed or simply a string of text. WinPosition provides the coordinates of the window. WinShowInfo contains the SWP.sub.-- flags corresponding to the Windows ShowWindow() function. WinSelectInfo contains the name of the selected menu or control window item. KeyboardInfo contains the key that was pressed as well as any flags indicating if the <ALT>, <SHIFT>, or <CTRL> keys were also pressed. Two classes, WinPositionInfo class 563 and WinSelectInfo class 567, spawn additional subclasses. As shown, MouseInfo class 571, which is derived from WinPositionInfo class 563, provides direct access to mouse events; it contains the mouse button that was clicked and whether it was a single or double click as well as the position of the mouse. WinSelectInfo class 567, on the other hand, spawns MenuInfo class 573 and ListInfo class 575. The former provides access to menu IDs and menu flags, the flags indicating whether the menu item is grayed, highlighted, or the like; the latter provides the index of the selected item, which is important if the list does not contain text. 5. Information Continuum Referring now to FIGS. 6A-B, an improved interface and method of the present invention for providing help and tutorials are illustrated. As shown in FIG. 6A, the monitor device 106 displays the GUI window 165; contained within window 165 are various screen objects, many of which the user may know nothing about. For instance, window 165 includes a "toolbar" 618 which, in turn, includes a plurality of screen buttons. As described above in FIG. 3, CBT system 300 includes one or more CBT window objects (e.g., window object 370 of FIG. 3), which are CBT UI components that may be simultaneously displayed with a target application's interface. Thus, while the CBT system preserves the interface of the target application(s), the script writer may also extend the interface with his or her own UI components. Moreover, these components are fully extensible as one may dynamically link one's own libraries to the system using known DLL technique (for additional description of DLL techniques, see the above-referenced Microsoft Windows SDK). In a preferred embodiment, an information continuum window object or interface 600 is provided when the screen cursor 185 is in proximity to a screen object of interest in a target application. This action may be triggered automatically, such as when the cursor approaches a minimum distance from the screen object of interest. Alternatively, interface 600 may appear in response to a user event; in a preferred embodiment, the information continuum interface is triggered in response to a <Shift> right mouse button click action. Upon invocation, interface 600 provides help information inspection for the object of interest (i.e., the screen object closest to the cursor 185). Interface 600 itself is a window object including various help components. Specifically, interface 600 includes a title 601, multimedia objects 603, description field 605, tutorial object 607, and help object 609. Each of these will be explained in turn. Title 601 is a short text string describing what help information is currently being inspected (e.g., "footnote help"). Description field 605 provides textual and/or graphic help information for assisting the user in understanding the current screen object whose help information is desired. Multimedia object 603, on the other hand, includes any multimedia data desired for the screen object. Multimedia object 603, for example, may play a short film clip illustrating how the current screen object is used. Interface 600 also includes links to tutorial and help modules. Specifically, tutorial component 607 may be triggered by the user (e.g., by a mouse click) for launching a full tutorial on the current screen object of interest. Upon invocation of the help component 609, on the other hand, the interface 600 displays help links which are relevant to the current object being inspected. In this manner, the user may rapidly traverse an information hierarchy which is relevant to the current object. All told, the interface 600 provides an information continuum for immediate and automatic access to all help and tutorial information which is of current interest to the user. Referring now to FIG. 6B, an information inspection method 620 in accordance with the present invention will be described. In step 621, an event loop is established to await a trigger for help. In a preferred embodiment of the method, a user event serves as a trigger. Alternatively, the step may be triggered automatically, for example, in response to movements of the cursor towards an object of interest. At step 622, the screen object of interest (typically, that which is closest to the cursor 185 of FIG. 6A) is identified using known technique (e.g., within preset hit radius of cursor 185). At step 623, the method displays an information continuum box, which may either be modal or non-modal (as desired by the system designer). At step 624 the user may traverse other components of the help continuum or hierarchy. Using a pointing device (device 105 of FIG. 1A), for example, the user may invoke the multimedia object at step 625, a tutorial at step 626, and/or additional help information at step 627. Upon exiting the information continuum dialog, the method may conclude or reenter the event loop of step 621. While the invention is described in some detail with specific reference to a single preferred embodiment and certain alternatives, there is no intent to limit the invention to that particular embodiment or those specific alternatives. For example, the foregoing description of the EventInfo class hierarchy 550 has focused on the Microsoft Windows environment; those skilled in the art will appreciate, however, that the individual classes may be adapted for other platforms, including, for example, OS/2, NeXTStep, X-Windows, and the like. Moreover, the class hierarchy, through the use of virtually-defined methods, includes extensibility for accommodating specific application environments. Classes may be defined for a spreadsheet which handle, for example, specific spreadsheet events. From the broad class of spreadsheet events, subtypes may be derived for processing specific types of user activities. For example, a class may be defined for processing spreadsheet "cell" events which would include such activities as editing a cell, formatting a cell, deleting a cell, and the like. Thus, the true scope of the present invention is not limited to any one of the foregoing exemplary embodiments but is instead defined by the following claims. ##SPC1##
|
Same subclass Same class Consider this |
||||||||||