WO1990009000A1

WO1990009000A1 - Execution sequencing

Info

Publication number: WO1990009000A1
Application number: PCT/US1990/000570
Authority: WO
Inventors: Amit Green
Original assignee: Cybermation, Inc.
Priority date: 1989-01-26
Filing date: 1990-01-26
Publication date: 1990-08-09
Also published as: JPH02271471A

Abstract

A system for managing the sequence of execution of a set of functions (27) which together enable performance of a desired task (10) in response to the appearance of appropriate input values (32), each input value being of a prespecified type; in the system, execution of each function (40) depends on the appearance of an input value of a predetermined type; at least some functions (22) in the set, when executed, generate output values of predetermined types, at least some of the output values being made available to appear as input values; information is stored (20) identifying the functions and their types of input values and output values, and indicating the order in which input values which appear should be applied to functions in the set; and a mechanism (24) is provided for matching the types of input values which appear with types of inputs values needed for execution of the function in accordance with the stored information.

Description

Execution Sequencing Background of the Invention This invention relates to managing the sequence in which functions are executed by a computer.

Such functions may, for example, be used to provide a graphical user interface which enables an engineer to use a computer-aided design system.

Graphical interfaces typically include features such as displayed icons which represent tasks to be performed, a mouse for selecting an icon, and a keyboard for entering data and commands. The system builder who designs and develops such a graphical interface normally writes a computer program in a high-level language. The program handles every combination and sequence of tasks that are permitted to occur within the designed user interface. Each task may require the execution of one or more functions.

For example, the engineer using the CAD program may be permitted to create a line by invoking a line creation icon, and then typing the coordinates of the endpoints of the line. The graphical interface must then be capable of invoking functions which receive each coordinate from the keyboard and cause the line to be displayed. A graphical interface program that permits a large number of different tasks and invokes a large number of functions is necessarily lengthy, complex, and difficult to generate, maintain, and alter.

Summary of the Invention Among other things, the invention provides a powerful data-flow type software approach to enable creation of complex graphical user interfaces. /09000

- 2 -

A general feature of the invention is a system for managing the sequence of execution of a set of functions which together enable performance of a desired task in response to the appearance of appropriate input values, each input value being of a prespecified type; in the system, execution of each function depends on the appearance of an input value of a predetermined type; at least some functions in the set, when executed, generate output values of predetermined types, at least some of the output values being made available to appear as input values; information is stored identifying the functions and their types of input values and output values, and indicating the order in which input values which appear should be applied to functions in the set; and a mechanism is provided for matching the types of input values which appear with the types of input values needed for execution of the functions in accordance with the stored information.

Preferred embodiments of the invention include the following features. The desired task to be performed may be a graphical task. The stored information identifying the functions and their types of input values for a given task is in the form of a directed graph (e.g., a sequential list) of functions and the input values are applied to the functions in an order based on the sequence in which the functions appear on the list. The type matching technique includes accepting a current input value, and finding the next unmatched input type in the sequence of functions. There may be two linked lists of functions, each list being arranged to perform a corresponding desired task, and an output value of a function of one of the lists may be delivered to serve as an input of a function of the other list. At least some functions in the set, when executed, each perform an activity such as deleting one of the functions in the set of functions. The set of functions may include at least two functions which have different input value types and the same output value type and the output values of both functions may serve as input values to trigger the performance of the desired task. Thus the desired task may be invoked in alternative ways by two different input value types generated by a user interacting with a graphical interface (e.g., via a keyboard or via a mouse) . The stored information identifying the functions and their types of input values and output values may comprise a text file. Each function may have two or more input value types having a predetermined order and those input value types are matched only in a predetermined order with the types of current input values. In some cases, the execution list element which contains a function may be modified so that the input value types are matched in an order different from the predetermined order. An input value of a function may become fixed when the input value type has been matched by the type of a current input value. The invention enables easy development and modification of, for example, graphical interfaces. Any function that uses definable input types can be invoked. Functions can be defined easily and incorporated into the system. The sequence of execution can be easily controlled and defined even though the sequence of inputs may be unpredictable. Description of the Preferred Embodiment We first briefly describe the drawings. Fig. 1 is a diagram of a computer workstation. Fig. 2 is a block diagram of the hardware and software elements of the workstation.

Fig. 3. is a flow chart of the execution of an execution list.

Figs. 4A through 4F are execution lists. Fig. 5 is a representative sample of entries in a description file.

Fig. 6A is the data structure of a letter height icon.

Fig. 6B is a listing of a size_it_on macro. Fig. 6C is a listing of a size_it_off macro. Fig. 6D is an execution list in its initial state.

Fig. 6E is the data struture of the letter height icon after it has been invoked.

Fig. 6F is the execution list after size_it_on has been executed.

Fig. 6G is the execution structure after the user has pointed to a letter on the screen.

Figs. 6H and 61 are the execution list after first and second mouse points, respectively. ^* Fig. 6 is the execution list after the user indicates a letter height by entering text. Structure and Operation

Referring to Fig. 1, a simple graphical interface may, for example, enable a user of a workstation 8 to create a line 10 at a desired location on a display device 12; the user may invoke a line creation icon 13 (using a mouse 25), enter (at a keyboard 11) the coordinate pairs, (a,b) and (c,d), for the two end points 14, 16 of line 10, and designate its color.

Referring to Fig. 2, the graphical interface may be implemented in the form of an execution list file 20 stored as a text file in a memory 21 of workstation 8. Workstation 8 also includes a microprocessor 23.

Referring to Fig. 4D, the execution list file includes one or more execution lists 27 each of which is a sequence of entries (execution elements) 22 each describing a function which may need to be performed to effect some feature of the graphical interface. Each entry in -the execution list includes an index identifying its position in the sequence, an option which may be invoked to affect the manner in which the function is executed, a command naming the function, a list of the types of inputs needed by that function, and a recitation of the type of output generated by the function. Every data item occurring in the system is classified by its type. The system builder may define his own input data types as well as using those already available in the system.

The execution list serves as a guide for executing the functions named in the entries of the list. The management of the list and the execution of the functions is handled by a run-time object program 24 (Fig. 2), based on current inputs (user entered or system generated) that appear in the system.

Each input type in each entry of the list may have one of two different states: (a) satisfied or (ii) unsatisfied. Referring to Fig. 3, in a simple case, when an execution list is initially invoked, all input types of all entries of the list are set to the unsatisfied state (30). The run-time object waits for and accepts any current input that appears in the system (32). The run-time object scans through the input types of the successive entries of the execution list to find the next unsatisfied input type which matches the current input type (34) . When a match is found, the current input value is held in the entry where the match occurred (36) and that input type in that entry is designated as satisfied (38). When all input types for a given entry of the list have been satisfied, the run-time object invokes the named function; otherwise it returns to accept the next current^"input (40). When a function named in an entry has been executed, all input types in that entry are redesignated as unsatisfied (42). Referring again to Fig. 4D, for example, the portion of an execution list which would enable a user to display a line would include only four entries as shown. Entry 1 names the function np (new point) which receives as inputs (e.g., user entered values) two double precision floating point values representing the coordinates (i.e., the input types are double and double) and delivers as an output a point with those coordinates. Entry 2 names the function nl (new line) whose inputs are two points (system generated) and whose output is a line. Entry 3 names the function set_col (set color) which receives a user entered color and has no output (when the function executes, it causes the display of the geometric object to change color) . Entry 4 names the function display and has as its only input the type geo, which has been defined to include the display types point, point, line, and color. The function display has no output value.

Accordingly, referring to Fig. 4E, after the execution list is invoked, when the user enters first and second doubles, say 100.0 and 200.0, the values satisfy entry 1 hich generates an output point. That point is held in entry 2 because it satisfies the first input type. Referring to Fig. 4F, the user may then enter a double (300.0) which is captured in entry 1. Then if the user enters another double, it will be captured in the entry 1, causing the function np to be executed, producing an output point. The output point will in turn be captured in entry 2, triggering the execution of function nl and the generation of a line which will be captured by entry 4. Thereafter, entry of a color by the user will trigger entry 2, which will set the color.

Note that the order in which the user enters the inputs is not important. The user may have entered a color value first or at any time relative to the other inputs. That color value would have been captured by entry 3, after dropping through the execution list entries 1 and 2. This capability is accomplished without requiring a complex instruction sequence to take account of every possible order in which the inputs are entered. Furthermore, it is easy to modify the execution list to.provide a variety of other features for the user interface.

The functions named in the execution list entries may include virtually any function which is characterized by having inputs of specified types and, if it has outputs, outputs of specified types. Such - 8 - functions may include available functions that form part of a known programming language (e.g., functions available in the C or C++ language), and functions that are defined and developed by the system builder. Referring to Fig. 5 and again to Fig. 2, the software includes a description file 50 (a text file), which lists every function that may be included, in an execution list . Each entry 52 in the description file includes five parts: a shell reference name 54, which is the name of the function as used in the execution list; an actual function name 56, which is the actual name of the function as used in a program which calls^' the function (e.g., new_point is the name of an available function in C++) ; a list 58 of input parameter types in the order in which they are to be accepted during execution (the input type double for example is a C++ type referring to a double precision floating point number); a list 60 of output parameter types; and the text of a help message 62, which can be retrieved, for example, during the development of an execution list. The C++ compiler is, of course, able to generate object code which implements any of the functions when called in a source code program. For functions which are unconventional, an object code implementation of the function must be provided in order for the function to be executable when it is invoked in an execution list. Any function which can be defined and implemented in object code may be included in the description file and invoked in the execution list file. Referring again to Fig. 2, the software system of the invention is implemented in object code compiled from a C++ source code program. The object code - 9 - includes the run-time object 24, a description object 62, and an application object 64, which are linked together to form a "shell" or software environment 66 within which execution lists may be created, modified, and executed to implement any desired features of, for example, a graphical interface.

The run-time object contains all of the code needed to provide the underlying capabilities of the system, including input/output, variable manipulation, loading of files, and macro facilities.

The run-time object includes an execution list facility which enables a system builder to create, edit, and execute, interactively, an execution list of functions. In creating or editing an execution list, the system builder can (i) give the execution list a name, (ii) specify where the ultimate output of an execution list will be directed as input to another named execution list, (iii) define each entry by naming one of the available functions (the input and output parameter types are automatically inserted in the entry), (iv) clear an entry on an execution list, (v) edit any of his previous work on the list, including changing the order and identity of the various functions, and (vi) delete a list. In the execution mode, the run-time object is arranged to (i) access an execution list when its name is invoked, (ii) reconfigure the entries in the execution list depending on the manner in which it was invoked, (iii) follow the procedure set forth with respect to Fig. 3 for all current inputs, (iv) deliver the output of the list for use by another list if specified, and (v) provide a snap-shot display to the system builder of the state of execution of any the entries in the list by showing when inputs have been satisfied (and the value of a satisfied input).

The application object contains the object code needed to effect all of the functions named in the description file. When the run-time object needs to execute a function on an execution list, the description object serves to call the needed object code in the application object. The description object is itself compiled from the description file by a compiler-compiler 68 which generates a C++ program to call the appropriate object code in the application object. The C++ program is itself compiled to generate the description object. In operation, when the run-time object determines, for example, that the function called np is to be executed, it passes the function name np and the input values to the description object. The description object then calls the portion of the application object in which the object code for the function new_point is located and passes the input values to that code. The resulting output is passed back to the run-time object via the description object. The description object is thus the "glue" that enables the run-time object to execute functions available in the application object. The description object also makes the system highly flexible because it enables the system builder, via the description file, to define and redefine easily any set of functions needed to provide any desired features in, for example, a graphical interface. The description object is in effect a data structure which allows the run-time object to match functions with their parameter - 11 - types. The description file allows the system builder to define successively more complex parameter types such that any data structure used as a parameter may be accommodated. A wide variety of options can be specified for each entry in an execution list. For example, where there are multiple inputs to a function, the normal requirement that the first input type be satisfied before the second input type be considered, may be modified by an option that permits, e.g., the second input type to be satisfied even before the first input type is satisfied. In another option, a particular input or output may be set at a fixed value, either directly when creating the execution element or by assigning the first correct data type permanently as a parameter. Alternatively, a particular input may be specified not to become fixed at the value of the first input of that type which is captured by that function, but to continuously accept parameters of the same type. In another option, a particular input may retain, across multiple executions, a value, even after the entry executes, until a new input of the same type is later captured. In another technique, an entry may be deleted from the execution list after it has been executed a specified number of times (e.g., once). Another option is to set all of the inputs of a given entry to fixed values, but allow the function to execute only when a value of some specified type passes the entry on the execution list. An output generated by a given entry can be fed back to any defined execution element (e.g., to the beginning of the execution list) rather than dropping to the next entry. An entry in an execution /09

- 12 - list may call for adding other entries into the execution list.

Multiple execution lists can be provided and the run-time object may be arranged to execute them effectively at the same time, thus providing expanded capability for a user to interrupt one task and proceed to another without requiring complicated code to implement the interface.

In using a graphical interface, a user may invoke an execution list file via a graphical icon.

Depending on which icon is triggered, the execution list file may be modified. For example, the execution list of Fig. 4D could be invoked by an icon for "specifying a line". Referring to Fig. 4A, the same execution list, with entries 1 and 2 deleted, could be invoked by a different icon, one for "specifying a display color". Referring to Figs. 4B and 4C (in which a double has been captured in entry 1), an icon for "specifying a point", could make use of all entries except entry 2. As another example of how the execution list approach may be used, a user who needs to change the height of a displayed letter could invoke a "letter height" icon and then have the option of three different ways of specifying the change in letter height: (i) pointing to an existing letter of the desired height, (ii) pointing to two screen points whose distance apart is a measure of the desired letter height, or (iii) entering a number representing the desired height on a prompt line via the keyboard. Referring to Fig. 6A, the data structure of the letter height icon includes (a) a link entry indicating the number of references to this data structure from - 13 - elswhere, (b) a name entry, giving the name by which this data structure may be invoked, (c) an off entry, identifying the name of the macro that is to be executed when this icon is off, (d) an on entry, indicating which macro is to be executed when the icon is on, (e) a social spots entry, indicating the group of icons to which this icon belongs, (f) a state entry, indicating the current state of this icon (up or down) , (g) a box entry, giving the coordinates of the box in which the icon is displayed on the screen, (h) a help entry, indicating which help message may be invoked in relation to this icon, (i) a window entry, indicating the display window in which this icon exists, (j) a toggle entry, specifying the nature of the switching mode by which the icon is invoked, (k) a down entry, pointing to the bit-map representation of the icon when down, (1) an off entry, indicating what a blank icon in this position would look like, (m) an up entry pointing to the bit-map representation of the icon when up, and (n) an again entry pointing to the routine to be executed when the icon is invoked twice in succession.

Referring to Fig. 6B, the size_it_on macro, invoked when the icon is pushed down, sets up the execution list needed to execute the letter height task. Each line of the macro which begins with the word "eset" specifies the contents of one entry (execution element) of the execution list. For example, line 10 sets the C.l line of the execution list to di^'sp/text/get-text_size. Line 40 , which begins "eetrigger" sets entry C.4 of the execution list as a command to clear C.l after a double is entered. Line 70 - 14 - sends to the screen a prompt (found at size_it) in the prompt area of the display specifying the size found. Referring to Fig. 6C, the size_it_off macro causes the execution list to be cleared when the icon is popped up, and causes the prompt size_it to be removed from the screen.

Referring to Fig. 6D, in the initial state, the execution list is cleared.

Referring to Fig. 6E, the current state of the letter height icon data structure after it has been invoked is the same as in Fig. 6A, except that the state now shows "down" .

Referring to Fig. 6F, after the macro size_it on has been executed, the execution list includes six entries.

In the first entry, for example, the function is get_text_size, and that function resides within the text subgroup of functions which in turn exists within the disp group of functions. The input is a placement*, i.e., a pointer to a structure that is displayed on a screen. The function get_text_size extracts the height of the structure on the screen. The output double is the letter height.

The second entry (C.2) determines the height as indicated by the distance between two points specified by the mouse (the two inputs are point_mouse) and generates as an output a double specifying the height.

The third entry simply uses the typed in double as the letter height. The fourth entry is a trigger function (note the T next to the C.4) which clears the entry at C.l when a double has passed entry C.4. This enables the - 15 - user, once he has pointed to the letter whose height is the desired height, to point to other structures on the screen without again triggering C.l to calculate a letter height. Otherwise C.l will continue to extract the height of each object pointed to on the screen.

The fifth entry stores the letter height for future reference. Entry C.6 actually resizes the height of the object pointed to in accordance with the value of the previously calculated double. The R next to the C.6 indicates random order of inputs.

Referring to Fig. 6G, after the user has pointed to a structure (letter) on the screen, the state of the execution list is that C.l has been cleared (because C.4 cleared it when the double originally generated by C.l passed C.4 on the list). The desired size (2) has been caught by C.6, which is waiting for the user to indicate which character is to have the height 2.

Referring to Fig. 6H, alternatively, if the user next wishes to specify the desired height by two mouse points, after one mouse point is done the coordinates are captured in C.2, which then waits for the second mouse point.

Referring to Fig. 61, after a second mouse point, the new letter height has been captured as 1.94 in C.6.

Referring to Fig. 6J, if the user then wishes to indicate a letter height by entering text, entry C.3 will process that entry and the resulting double is eventually captured in C.6.

Other embodiments are within the following claims. For example, the order of execution of - 16 - execution elements may be specified in

other than by placing them in a sequential order in an execution list. Also, any tasks (not limited to graphical interfaces) that require the execution of underlying functions may be implemented. The system is especially useful for tasks that involve intense user activity, particularly where the order in which a user will perform the tasks is not predictable in advance, and in real time control applications where data is collected in random order. The system is also potentially useful in organizing execution of functions in parallel programming environments.

The Appendix contains code sufficient to allow a user to create new user interfaces as well as an example of a specific user interface useful in signmaking. It can be run on a complement of hardware and software that includes an IBM AT compatible 386/387 computer with 4 megabytes of memory, an Imagraph arctc 1280x1024 graphics display controller (available from Imagraph, 800 Washington Street, Woburn, Massachusetts), an Hitachi high resolution color monitor, a Logitech bus mouse, SCO Xenix system V version 2.2.1, and SCO C " compiler (both available from Santa Cruz Operation, Santa Cruz, California), and an AT&T C++ compiler (available from AT&T).

A- portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.

Claims

- 17 -

Claims 1. A system for managing the sequence of execution of a set of functions which together enable performance of a desired task in response to the appearance of appropriate input values, each input value being of a prespecified type, in which execution of a function depends on the appearance of an input value of a predetermined type, at least some functions in the set, when executed, generate output values of predetermined types, at least some of the output values being made available to serve as input values, information is stored identifying the functions and their types of input values and output values, and indicating the order in which input values which appear should be applied to functions in the set, and a software technique is provided for matching the types of input values which appear with the types of input values needed for execution of the functions in accordance with the stored information. 2. The system of claim 1 in which the stored information is in the form of a directed graph of functions and the input values are applied to functions in an order based on the sequence in which the functions appear on the list. 3. The system of claim 2 in which the directed graph is a sequential list. 4. The system of claim 1 in which there are two lists of said functions, each list being arranged to perform a corresponding desired task, and an output value of a function of one of said lists is delivered to serve as an input of a function of the other said list. 5. The system of claim 1 in which at least some functions in the set, when executed, perform an activity. 6. The system of claim 5 in which the activity performed by the execution of a function is to alter one of the functions in the set of functions. 7. The system of claim 6 in which the one function is deleted from the set. 8. The system of claim 7 in which the set of functions includes at least two functions which have different input value types and the same output value types and the output values of both functions serve as input values to trigger the performance of the desired task, whereby the desired task may be invoked in alternative ways. 9. The method of claim 1 in which the desired task is a graphical task. 10. The method of claim 8 in which the two different input value types to the two functions are generated by a user interacting with a graphical interface. 11. The method of claim 1 in which the functions in the set have a predetermined sequence and the type matching technique includes accepting a current input value, and finding the next unmatched input type in the sequence of functions. 12. The method of claim 1 in which the stored information identifying the functions and their types of input values and output values comprises a text file. 13. The method of claim 1 in which one said function has two input value types having a predetermined order and said input value types are matched only in the predetermined order with the types of current input values. 14. The method of claim 13 in which the ^* function is modified so that the input value types are matched in an order different from the predetermined order. 15. The method of claim 1 which an input value of a function becomes fixed when the input value type has been matched by the type of a current input value.