IBG 1011
`CBM of U.S. Pat. No. 7,533,056
`
`0001
`
`

`
`U.S. Patent
`
`May 9, 1995
`
`Sheet 1 of 11
`
`5,414,809
`
` H
`
`DATA
`
`USER SPECS
`
`REILZORD EDIL’
`
`
`
`MI
`I
`
`
`GRAPHICS
`ENGINE
`(TREE)
`
`111--n-xu-nu-sauna:-—-1111:-1-1:-In-c-n—u—.::
`
`
`
`ENGINE
`(awn)
`
`ROOT LIBRARY
`DATA HANDLING
`
`PRIMITNES
`
`0002
`0002
`
`

`
`U.S. Patent
`
`May 9, 1995
`
`Sheet 2 of 11
`
`5,414,809
`
`50
`V
`
`F]G. 5
`
`
`
`
`EEI
`
`E E
`
`fleip
`
`Qommands
`Eihdow
`Eiews
`Linking
`Edit
`ile
`
`
`FIG. 5A
`
`
`
`
`E E
`
`dii
`
`Linking
`
`Eiews
`
`Vjindow
`
`Qornmunds
`
`flelp
`
`
`
`EEI
`
`
`_
`
`Organization
`
`Salary
`
`
`
`Qpen...
`
`Merge...
`
`Save
`Save As...
`
`_£xporl...
`!_mpori...
`
`Siafisiics
`
`Exit GrA'r'
`
`0003
`0003
`
`
`
`

`
`U.S. Patent
`
`May 9, 1995
`
`Sheet 3 of 11
`
`5,414,809
`
`FIG. 5B
`
`
`
`
`IE5
`Linking
`yjews
`flindow
`Qomrnunds
`Help
`Configuration...
`
`E7
`
`
`
`Tesi Application Menus
`
`|>
`
`
`
`
`
`FIG. 5C
`
`
`
`EH5!
`yjews
`flindow
`Qommands
`flalp
`
`
`
`0004
`
`

`
`US. Patent
`
`May 9, 1995
`
`Sheet 4 of 11
`
`5,414,809
`
`FIG. 51)
`
`
`
`
`IEEE
`_Ei|e
`gait
`Linking
`flindow
`Qornmands
`Help
`
`
`
`Space
`Cfl+lns
`
`
`Del
`
`Enter
`
`
`
`
`fropeflies...
`_§opy...
`Llelafa...
`
`_Show
`Clgse
`
`
`
`Shag All
`_MImrmze A1!
`Close All
`
`
`
`
`
`jimfiijw
`
`
`
`
`
`Fw””#—“‘HE
`
`Field Type
`IE!
`wgu
`
`in
`
`~%——-——
`
`
`
`
`
`55
`
`
`0005
`0005
`
`
`
`
`
`
`

`
`U.S. Patent
`
`May 9, 1995
`
`Sheet 5 of 11
`
`5,414,809
`
`FIG. 7
`
`
`
`:MEI
`
`
`Consfclnfs
`
`
`
`F‘.‘.‘IF’I“_"
`D
`
`
`
`Table
`
`Enumerafion Type
`Badgecoior
`
`E
`
`Graphic Afiribufe
`El
`
`0006
`0006
`
`
`
`En umerufion Type
`
`Enurneralion Type Edifor
`
`
`
`

`
`U.S. Patent
`
`May 9, 1995
`
`Sheet 6 of 11
`
`5,414,809
`
`External
`
`Avviicaiion
`
`Topic C:\GRAF\DEiHi0\Ei«iPDE
`
`Hem R1C1:R60C1D
`
`| Posts from Clipboard
`
`Record Type Employee
`
`ll
`
`Kev We i::i
`“aid |::iE]
`
`I:IKay Generofion
`Composite Fields: |:
`
`[:]Trons ose
`P
`
`FIG.
`
`70
`
`Command Editor
`
`/
`
`ljifl
`El g.
`
`
`AnPIi=o+ion= [:1 Topic [:3 _L°°mm="=d
`
`Command String:
`
`
`
`
`
`
`
`
`
`
`View Soiory display shack Proieci; display sorl Badge <; dislu cou
`E:|Requires Selectable
`
`Hem of Type:
`
`E Inciude on Menus
`
`0007
`0007
`
`I commdnd |
`
`
`
`

`
`U.S. Patent
`
`May 9, 1995
`
`Sheet 7 of 11
`
`5,414,809
`
`no
`
`FIG.
`
`11
`
`
`Record Tv==e= TE! -
`
`
`
`
`
`
`
`
`
`| Command Editor...
`I
`
`
`
`
`Creofe
`O No’r Allowed
`0 Local
`O Remote Command
`
`C]Updo1e Noiificaiion
`
`‘°°
`
`‘°‘
`
`W “
`
`’3
`
`104
`
`‘O5
`
`106
`
`FIG. 12
`
`DATA MATCHED T0
`OBJECTS AND ATTRIBUTES
`
`USER SELECTS
`OBJECT TO EDIT
`
`YES®
`
`N0
`
`
`
`USER MANIPULATES
`OBJECT
`
`1070
`
`USER ENTERS TEXT
`
`1%
`
`UPDATE GRAPH
`
`1390
`
`UPDATE LOCAL DATABASE
`
`1091)
`
`UPDATE EXTERNAL
`DATABASE
`
`0008
`0008
`
`
`
`
`
`
`Deleio
`O No? Allowod
`O Local
`O Remoie Command
`
`
`
`
`Updofe
`
`O No! Allowed
`O Local
`O Remoie Commund(s)
`l:lRerno1e Editor
`
`
`
`

`
`U.S. Patent
`
`May 9, 1995
`
`Sheet 8 of 11
`
`5,414,809
`
`
`—
`
`
`
`130\
`
`FIG. 73
`
`Time Granuluriiy
`©sacmds
`
`Employee
`Stud Time Field
`lgl
`
`E-|
`
`Shp Time Field
`
`Vacsfop
`
`Opfions
`IZDu1a Dirac? Manipulafion
`| Background Color...
`I
`
`0009
`0009
`
`

`
`U.S. Patent
`
`May 9, 1995
`
`Sheet 9 of 11
`
`5,414,809
`
`160
`W
`
`FIG. 16
`
`
` 151
`
`
`
`EE1
`Configure
`fidif
`new
`Qommands
`flindow
`tleip
`December
`January
`1
`3
`291
`a
`
`15
`
`22
`
`15
`
`22
`
`February
`291
`|!|
`
`
`
`160
`
`
`
`WE
`
`
`
`H3
`
`m flew
`Qommunds
`flindow
`Help
`- yndo
`Cfr|+U
`
`lns
`Qreafe...
`fidil...
`Enier
`flelefe... Del
`
`
`
`
`
`
`Turkmenis, S1
`
`Hiils, Travis
`
`0010
`0010
`
`

`
`U.S. Patent
`
`I May 9, 1995
`
`Sheet 10 of 11
`
`5,414,809
`
`F10.
`
`7613
`
`
`
`Vail
`
`Cogfigure
`_E_di’r
`Qommunds
`window
`flelp
`
`
`
`’
`
`Merge
`Eilier
`
`_Z_oom
`
`
`
` Aragon, Fran
`
`Sun, Jack
`
`Turkrnenis, Sf
`
`Hills, Travis
`
` Hannesberg,
`
`
`
`L": Ear Styles...
`Bur Legend
`Lube! Siyles...
`Label Legeng Shiff+Cfrl+
`
`CM-I-L
`
`Saint, Luwren
`
`Fails. Vicioria
`I
`
`DJ
`
`El
`
`
`
`0011
`0011
`
`

`
`U.S. Patent
`
`May 9, 1995
`
`Sheet 11 of 11
`
`5,414,809
`
`FIG. 17
`Vacaiion
`
`Qamrnands
`
`Help
`
`[Few
`Edi!
`December
`1
`3
`
`15
`
`22
`
`window
`January
`291
`3
`
`15
`
`22
`
`February
`291
`3
`
`IQ!
`"III
`
`‘BK
`E
`
`Configure
`
`Sun, Jack
`
`Turkrnenis, Si
`
`
`
`
`
`
`
`
`Aragon. Frdn
`
`
`
` '“_
`
`FIG. 78
`
`§aIary...
`
`!acS’rarf...
`
`§fa’rus
`
`Eraiecl
`
`Ehane...
`
`_
`
`Office SC
`
`Name Hills, Travis
`Salary BYOB
`VacS1arf 12 7 91
`Vacslop 1
`‘I 92
`Badge YELLOW
`Sfafus ACTIVE
`
`Project Nianagemeni
`Phone 555-4552
`
`Manager Sfraih, Cycle
`
`EH3
`Name
`Vac Sfap
`Vac Siari
`Saiary
`EmpLsta1us .
`Badge Color
`Phone Number
`Proiecf
`Name
`I
`ll
`
`
`
`
`
`
`
`
`
`
`
`0012
`0012
`
`
`
`FIG. 19
`
`
`
`
`
`
`
`
`
`

`
`1
`
`GRAPI-IICAL DISPLAY OF DATA
`
`5,414,809
`
`TECHNICAL FIELD OF THE INVENTION
`
`This invention relates to computer processes, and 5
`more particularly to a method of using a computer to
`provide a graphics interface, which displays a graph of
`data and permits the user to modify the data by directly
`manipulating the graph.
`BACKGROUND OF THE INVENTION
`
`10
`
`The use of computers to generate graphical displays,
`which illustrate the relationships of underlying data is
`well known. For example, a computer might be used to
`generate a bar graph to illustrate the relationship be- 15
`tween a set of data values taken at different points in
`time.
`A fairly recent development in computer applications
`is the integration of database management capabilities
`and graphical displays. Both types of applications deal
`with the same database. Various software tools have
`been developed to provide dynamic linkages between
`these different applications.
`However, a common characteristic of these inte-
`grated systems is that data is entered in text form, via
`conventional data entry means. Even when a graphical
`user interface is available for permitting the user to
`directly manipulate objects on a display screen, these
`user interfaces are limited to invoking operating system
`tasks, such as file management, rather than for changing 30
`application data.
`SUMMARY OF THE INVENTION
`
`20
`
`25
`
`45
`
`A simplified aspect of the invention is a method of
`using a computer to implement a graphical interface 35
`having a single view style for a single type of graph.
`More specifically, the invention is a method of using a
`computer to display a graph illustrating data and to
`permit a user to edit the data by directly manipulating
`the graph. The computer stores a graphics engine, com-
`prised of a set of rules for displaying graphical objects
`and graphical attributes that comprise the graph. The
`computer also stores a local database comprised of user-
`specified records and fields of data, accessible by the
`graphics engine. The computer receives specification
`data from the user, in which data fields are matched to
`graphical attributes. The computer receives configura-
`tion data from said user specifying at least one record
`type of records in said local database and at least one
`field of said record, which are to be illustrated with the
`graph. The computer matches each data value of the
`record type with a graphical object. It also matches
`each data value of the fields with a graphical attribute of
`said graphical object. It displays a graph comprised of
`the graphical objects, with corresponding attributes, on 55
`a display screen. It then receives editing input from an
`end user, representing a change to a value of a selected
`field within one of the records. It matches the selected
`field to an attribute of a target graphical object. It
`changes the target graphical object in response to said
`editing input, and updates the local database, such that
`the value of said selected field is reflects said change.
`One enhancement of the invention involve storing
`more than one view style, each having its own graphics
`engine. For each view style there could be multiple 65
`objects and attributes, requiring the user to specify what
`data values are to be matched with those objects and
`attributes. A message passing protocol can be set up
`
`2
`between the graphical interface and a separate database
`system, which supplies data for the local database, and
`is updated with new data values resulting from editing
`of the graph. Commands may be specified so that tasks
`may be performed by other applications during presen-
`tation of a graph.
`One technical advantage of the invention is that its
`graphics engines provide a degree of generality to the
`process of using a computer to display graphic illustra-
`tions of data. For example, for a gantt chart, the graph-
`ics engine may include certain routines that are com-
`mon to all gantt charts, so that for a specific illustration
`of data, the user need only specify what data is to be
`presented.
`Another technical advantage of the invention is that
`it permits direct manipulation of a graph to edit the
`underlying data represented by the graph.
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`FIG. 1 illustrates the basic components of program-
`ming for implementing the method of the invention.
`FIG. 2 is a computer system for executing the method
`of the invention.
`FIG. 3 illustrates the objects comprising a view style,
`FIG. 4 illustrates components of a graphics engine of
`FIG. 1.
`FIG. 5 illustrates a display screen with a menu line,
`representing menus of tasks performed by the master
`process of FIG. 1.
`FIGS. 5A—5D illustrate menus of tasks represented
`by the menu line of FIG. 5.
`FIG. 6 is a dialog box for specifying data to be illus-
`trated by any one or more view styles.
`FIG. 7 is a dialog box for specifying the values of an
`enumeration field type.
`FIG. 8 is a dialog box for specifying associations
`between potential data values and graphical attributes.
`FIG. 9 is a dialog box for specifying linking instruc-
`tions for the link manager of FIG. 1.
`FIG. 10 is a dialog box for specifying commands that
`may be executed during presentation of a graph.
`FIG. 11 is a dialog box for specifying controls that
`may be imposed during presentation of a graph.
`FIG. 12 lists the steps of using a computer to present
`a graph and to accept user manipulations in accordance
`with the invention.
`FIG. 13 is a dialog box for receiving a user's choice of
`view styles.
`FIG. 14 illustrates a blank graph.
`FIG. 15 illustrates a dialog box for specifying associa-
`tions between data fields and view-specific graphical
`objects and attributes.
`FIG. 16 illustrates a graph generated by one of the
`graphics engine of FIG. 1.
`FIG. 16A illustrates the “edit" tasks performable by a
`graphics engine during presentation of a graph.
`FIG. 16B illustrates the “view” tasks performable by
`a graphics engine during presentation of a graph.
`FIG. 16C illustrates the “commands” tasks perform-
`able by a graphics gine during presentation of a
`graph.
`FIG. 17 illustrates a graph with a graphical object
`having been selected for editing.
`FIG. 18 is a dialog box for receiving the user’s editing
`input.
`FIG. 19 is a second type of dialog box for receiving
`the user’s editing input.
`
`0013
`0013
`
`

`
`3
`
`DETAILED DESCRIPTION OF THE
`INVENTION
`
`System Components
`
`FIG. 1 illustrates the basic software components of a
`computer-based graphics interface 10 for graphically
`illustrating data retrieved from a database system 11.
`This software resides in the memory of a computer
`system, and when executed, implements the method of
`the invention.
`FIG. 2 is a block diagram of a computer system 20 for
`executing the process of the invention. In general, the
`components of the system are conventional computer
`components, and include a general purpose processing
`unit 21, such as one based on the Intel 386 microproces-
`sor. A program memory 22 stores program code. A data
`memory 23 stores data, and may include a mass memory
`for storing a database. The system 20 also has a bit»
`mapped graphics display 24 and input devices, such as a
`keyboard 25 and a pointing means 26.
`One example of a pointing device 26 suitable for use
`with the invention is a trackball-type "mouse”. A user
`moves the mouse to position a cursor on the display
`screen. By depressing or releasing a switch on the
`mouse, the user indicates to the computer when the
`cursor has a position that corresponds to, i.e., “points
`to”, the user’s, selection of an object on the screen.
`Other pointing means 26 could be used, such as a track-
`ball with separate selection keys, or a touch screen
`display. By “selection” of an object or attribute as used
`herein,
`is meant to user’s activity of pointing to the
`object or attribute and indicated his selection.
`The computer system 20 operates under a “windows”
`type operating system 16, such as the Windows system
`manufactured by Microsoft Corporation. Another ex-
`ample of a windows operating system 16 is the UNIX
`operating system.
`A significant feature of the operating system 16 is that
`it permits computer system 20 to generate multiple
`windows on display 24, each of which corresponds to
`an independent application program. Thus, it permits
`the graphics interface 10 and database system 11 to be in
`execution at the same time.
`The present invention relates to the use of a computer
`system, such as that of FIG. 2, which stores and exe-
`cutes programming for the graphics interface 10 of
`FIG. 1. As an overview of the method of the invention,
`a graphics engine 12 generates a display that illustrates
`a set of data delivered from database system 11. A link
`manager 13 handles message passing between database
`system 11 and graphics interface 10. A local data store
`14 stores data that is the subject of the current display
`being generated by graphics engine 12. The display is
`comprised of distinct graphical objects, each represent-
`ing an item of data. The graphical objects have attri-
`butes, such as color and size, which also represent data.
`If the user desires to change the data, he may either
`enter new data in text form or use a pointing device to
`directly manipulate the appropriate graphical object.
`Either type of input causes local data store 14 to update
`its copy of the data, and causes link manager 13 to send
`a message to the database system 11 so that its data is
`updated. A master process 15 handles interactions with
`the user, and also permits the user to defme how data
`will be organized in local data store 14 and to specify
`associations between graphical objects and data.
`Database system 11 can be any type of database sys-
`tem, such as one in which data is organized as files,
`
`0014
`0014
`
`5,414,809
`
`4
`records, and fields. It is assumed that database system 11
`has mass memory for storing data and some sort of data
`management programming. Database system 11 may be
`any one of a number of commercially available database
`application programs. However, database system 11
`could be as simple as any collection of data with some
`means for handling data exchanges via a message proto-
`col.
`For purposes of this description, an example of a
`database system 11 for storing and processing employee
`data is used. Each employee record is organized into
`fields of data, each field containing an item of data rele-
`vant to that employee. Some examples of employee data
`fields are salary, vacation time, and length of employ-
`ment.
`
`Graphics interface 10 has at least one graphic engine
`12. Each graphics engine 12 contains a description of a
`unique view style. Examples of view styles are gantt
`charts, tree charts, or bar charts. A typical graphics
`interface II] will have a number of graphics engines 12.
`one for each view style.
`In general, a view style provides for an interactive
`presentation of data, in which instances of user data are
`presented as graphical objects. Each graphical object is
`a rectangular area on a logical display. The primary
`concern of a view style is determining the size and
`position of these graphical objects. Typically, this de-
`termination is on the basis of a data field of a data record
`associated: with the graphical object. Because of this
`relationship between position and size and user data, a
`view style may constrain the kinds of data it can pres-
`ent. Another view style constraint is that the relation-
`ship between objects and the data should lead to some
`sort of intuitive means for manipulating the objects to
`affect the data.
`
`FIG. 3 illustrates an example of the objects of a gantt
`chart view style. An example of a graphic object in the
`gantt chart 30 is each bar 31, which represents an inter-
`val of time. Another object is each label 32, one each of
`which is associated with a bar 31.
`Using the example of employee data, the gantt chart
`of FIG. 3 is a chart of vacation times. Each object of the
`graph, in this case a bar 31, represents a vacation time of
`an employee, whose name is indicated by the label 32 of
`that bar 31. The position and length of the bar 31 indi-
`cate start and stop times of the employees vacation.
`Thus, in FIG. 3, two graphical objects represent each
`employee. If Employee B’s vacation time data is the
`value “weei: 2-week 4”, the associated object, i.e., bar
`31, would have a position and length representing that
`data. As an another example, a tree view style might
`have objects in the form of nodes in a tree hierarchy.
`Each graphical object, such as a bar 31 or label 32,
`has one or more attributes. For example, a bar 31 of
`gantt chart 30 may have start position, stop position,
`and color attributes. Labels 32 might have attributes,
`such as its data string, font, or color. Each attribute is
`associated in some manner with data. For example, an
`employee who is currently on vacation might have his
`bar 31 displayed in a red color.
`Thus, the graphics engine 12 for a view style includes
`a description of the view style, in terms of rules for
`displaying objects comprising that view style. In gen-
`eral, the rules for a view style determine layout, i.e.,
`where objects go and how big they are. Appendix A
`sets out a number of rules for a graphics engine 12 for a
`gantt chart view style. Rules for other view styles may
`
`5
`
`I0
`
`15
`
`2{}
`
`25
`
`30
`
`35
`
`45
`
`Si}
`
`55
`
`65
`
`

`
`5,414,809
`
`6
`routing messages by link manger 13. The specification
`process is explained below in connection with FIGS.
`5-11, as a result of which, the stored specification data
`17 is accessed by master process 15. The distinction
`between what is user-specified, as opposed to being
`generated by stored programming, reflects the extent to
`which the programming of graphics interface 10 is re-
`useable. Master process 15 also handles, with the coop-
`eration of a graphics engine 12, the presentation of any
`instance of a view style. The presentation and editing of
`graphs is explained below in connection with FIGS.
`12-19.
`
`FIG. 4 illustrates one architecture for implementing a
`graphics engine 12. Each graphics engine 12 has its own
`executive 35, which opens a window when the corre-
`sponding view style is selected by the user. It calls for
`routines stored in root library 36 and in rule set 37. Root
`library 36 is shared by all graphics engines 12, and con-
`tains routines that are common to them, such as data
`sorting routines. Rule set 37 contains the rules for the
`view style presented by that graphics engine 12.
`Consistent with the architecture of FIG. 4, master
`process 15 calls for services by a graphics engine 12.
`Master process 15 and the graphics engines’ executives
`35 are separate but dependent processes. The root li-
`brary 36 and rule sets 3'.-' are dynamically linked librar-
`ies. In a windows environment, master process 15 and
`executive 35 each control their own window. Alterna-
`tively, “custom controls” features of the windows pro-
`gramming may be used, so that instead of a window
`being created by executive 35, graphs are created in a
`window of database system 11, which calls routines
`from graphics engine 12.
`FIG. 5 illustrates a display screen 50, which presents
`to the user a selection of tasks performed by master
`process 15. FIGS. 5A—5D illustrate the pulldcwn
`menus, with selections that represent those tasks. “File”
`tasks, listed in FIG. 5A, are like those of conventional
`applications programs. “Edit" tasks, listed in FIG. 5B,
`are explained below in connection with FIGS. 6-11.
`“Li.nking" tasks, listed in FIG. 5C, set up links among
`subscribing applications. “Views" tasks, listed in FIG.
`SD, are explained below in connection with FIGS.
`12-20. “Commands” tasks are explained below in con-
`nection with FIG. 21. Each of these tasks is interactive,
`in the sense that master process 15 acts in response to
`user specifications. It then forwards these specifications
`to link manager 13, local data store 14, or graphics
`engine 12. In FIG. 5, display screen 50 also displays a
`palette of graphs already created, which may be manip-
`ulated to display those graphs.
`Referring again to FIG. 1, specifications 1? represent
`stored input from the user, entered via the interactive
`“edit” tasks of master process 15. In practical use, the
`“user” who provides these specifications might be a
`software developer, who adds alayer of functionality to
`the graphical
`interface 10. This developer might be
`different
`from the “end user" who actually views
`graphs via the “views” tasks and makes practical use of
`user data from database system 11. However, for pur-
`poses of this description, the word “user" may mean
`either of such persons.
`
`10
`
`i5
`
`20
`
`25
`
`30
`
`35
`
`45
`
`S0
`
`S5
`
`5
`be similarly developed to create other graphics engines
`12.
`Creation of an instance of a view style (herein re-
`ferred to as a “graph”) is interactive. As explained be-
`low, the user specifies what data will be mapped to the
`objects and attributes, and in response,
`the graphics
`engine 12 handles the layout in the display screen.
`Referring again to FIG. 1, link manager 13 enforces a
`message exchange protocol, which ensures the that data
`in local data store 14 and in database system 11 are
`consistent. In other words, if an item of data in one
`location is updated, the copy of that data in the other
`location is also update. If the user changes a graph,
`whether by means of textual input or by direct manipu-
`lation of a graphical object, link manager 13 sends a
`message to database system 11. This message contains
`the updated data so that database system 11 can update
`its copy of that data. Likewise, if, during presentation of
`a graph, the user changes data using input means of
`database system 1]., link manager 13 sends a message
`containing the new data to local data store 14.
`An example of a message passing protocol suitable for
`use with the present invention is the DDE (dynamic
`data exchange) protocol, developed by Microsoft Cor-
`poration, for windows operating systems. Another ex-
`ample is the "pipes" means for interprocess communica-
`tions, as implemented on the windows interface for
`UNIX operating systems.
`Messages communicated by link manager 13 are ei-
`ther data messages or executive messages. As an exam-
`ple of a data message, if a user changes a data value with
`input to graphics engine 12, a data message to database
`system 11 would contain the new data and permit the
`data to be "poked” into database system 11. Conversely,
`if a user changes a data value with input to database
`system 11, a data message from database system 11 to
`graphics interface 10 would contain that new data. As
`an example of an executive message, if a user desires to
`a dialog box from database system 11 to appear on a
`graph, this could be accomplished with a command to
`database system 11 and an executive message to graph-
`ics engine 12.
`Local data store 14 stores data in accordance with a
`user-defined schema. This data is a copy of some subset
`of data stored in database system 11. The data in local
`data store are organized as record types, each record
`having one or more fields, and each field being a certain
`type. At least one field ofa record type is a “key” field,
`whose value is unique for each occurrence of a record
`type. For example, each ployee’s key field might
`contain that employee’s unique id number. As explained
`below, this organization of data in local data store 14
`permits the data to be mapped to graphical objects and
`attributes.
`.
`A feature of local data store 14 is that it includes a
`routine‘ for receiving an indication from graphics en-
`gines 12 if the user changes data of the graph, whether
`by textual input or by manipulating an object. If such an
`indication is received, local data store 14 updates its
`copy of the data represented by that object. Also, a
`particular data value might be the subject of more than
`one view style. For this case, local data store 14 pro-
`vides notification tasks, such that when an object is
`changed via one graphics engine 12, other graphics
`engines 12 are notified.
`Master process 15 handles interaction with the user.
`It receives user specification data, such as the organiza-
`tion of data in local data store 14 and directions for
`
`65
`
`Specification Tasks
`FIG. 6 illustrates a dialog box presented by master
`process 15 when the user selects the “Record Types"
`task from the “edit” menu of FIG. 5B. The user’s tex-
`tual input to dialog box 60 permits the user to specify
`
`0015
`0015
`
`

`
`7
`the schema of data in local data store 14. More specifi-
`cally, the user specifies a record type, the fields within
`each record, and the data type of each field.
`In the example of FIG. 6, the user has specified an
`“employee” record type, with a “manager” field, of
`type REF. This means that an employee's record has a
`field that points to the record of that employee's man-
`ager, who is also an employee. This type of data would
`be useful for illustrating organization with a “tree” view
`style.
`If the field type is “enumeration”, the user may spec-
`ify a closed set of values that the field may have. For
`example, FIG. 7 illustrates a dialog box 70 that is pres-
`ented by master process 15 if the user selects the field
`type “enumeration”. The field type "badgecolor” is
`specified so that the field may have a value that repre-
`sents one of a set of colors. These values will be con-
`stant for all instances of a view style presented by that
`graphics engine 12.
`FIG. 8 illustrates a dialog box 80 that permits the user
`to associate the potential data values of a field type
`“enumeration” to graphical attributes. Dialog box 80 is
`presented in response to selection of the “associations"
`task from the “edit” menu of FIG. 5B.
`Using dialog box 8|], the user first matches the enu-
`meration type to an attribute type. Then, for each possi-
`ble data value of an enumeration type, the user specifies
`a different instance of an attribute. This mapping is used
`by graphics engines 12 when presenting a graph. An
`object having the specified attribute will display that
`attribute according to the data values. For example, in a
`gantt chart, the bar 31 of an employee might have a
`color attribute that corresponds to that employee’s
`“badge-color” field value.
`FIG. 9 illustrates a dialog box 90, presented by master
`process 15, if the user selects the “links” tasks from the
`“edit” menu of FIG. 5A. This dialog box 90 permits the
`user to specify the location of data, which is currently
`stored in database system 11, so that it may be delivered
`to local data store 14.
`FIG. 10 illustrates a dialog box 100 presented by
`master process 15 if the user selects the “comrnands"
`task of the “edit” menu of FIG. 513. Using dialog box
`100, the user gives the command an identifier, and speci-
`fies the application to which the command is directed.
`The user also enters a command string, such as a DDE
`executive message, to be performed by that application.
`Once a command has been defined, its identifier will
`appear on the “commands” menus of either master
`process 15 and of all graphics engines 12, or only on the
`“commands” menus of certain graphics engines 12. This
`depends on whether the user specifies that the com-
`mand is related to a specific data type. If not, the com-
`mand identifier appears on all “commands” menus. If
`the command is related to a certain data type, the com-
`mand identifier appears as a menu choice only during
`presentation of graphs that use the specified data type,
`as explained below in connection with FIG. 17. This is
`implemented by means of the association, during pre-
`sentation of a graph, of record types and fields to ob-
`jects and attributes, which in turns are associated with
`particular view styles. Further details of commands
`tasks are explained below in the section entitled “Link
`Manager Subscribers".
`FIG. 11 illustrates a dialog box 110, generated by
`master process 15 when the user selects the “update
`control” task of the “edit" menu of FIG. 5B. This task
`permits a user to specify controls over editing of the
`
`5
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`45
`
`50
`
`S5
`
`65
`
`5,414,809
`
`8
`data of database system 1!. For example, in FIG. 11 the
`user has indicated that certain update controls are to be
`imposed for the record type “employee”. During pre-
`sentation of a graph, these controls will prevent an end
`user from performing the specified updates. Dialog box
`110 also permits the user to specify a remote command,
`such that if data is modified via graphics interface ll},
`database system 11 will automatically respond with
`some process rather than simply updating its data.
`As a result of the various editing tasks described
`below, a user, typically a developer user, has created a
`file of specifications data 17. This data 17 is stored in
`memory 23 for use by graphics interface 1!] during pre-
`sentation of a graph for an end user.
`Views Tasks
`
`FIG. 12 illustrates the process of displaying a graph.
`For purposes of FIG. 12, it is assumed that the graphics
`interface 10 and the database system 11 of FIG. 1 are
`currently in execute mode on a computer system and
`that a message passing protocol has been established
`between them. In general, this protocol includes a re-
`ciprocal notification requirement, such that when a data
`value is changed, link manager 13 ensures that local
`data store 14 and database system 11 are updated. Speci-
`fications for this message passing are supplied by a user,
`as discussed above in connection with FIG. 9.
`For purposes of example, to illustrate the steps of
`FIG. 12, the user specification process of FIGS. 6-11 is
`assumed. The process of presented a graph is initiated
`by master process 15 when the user selects the “create”
`tasks from the “views” menu of FIG. SD. However, it
`should be understood that simpler version of the inven-
`tion might have view styles with single objects and/or
`single attributes, or predefined mappings from objects
`and attributes to records and fields, such that less user
`specification is required.
`As indicated by step 100, it is assumed that at least
`one graphics engine 12 has been provided with the rules
`for a view style.
`In step 101, local data store 14 is set up with user-
`specified record types and fields. This may be accom-
`plished by user specification as discussed above in con-
`nection with FIG. 6. If the local data is to be supplied
`from database system 11, step 101 includes a data ex-
`change from database system 11 to local data store 14.
`In step 102, the user initiates a graphics engine 12 for
`the desired view style. This causes executive 35 of the
`corresponding graphics engine 12 to open a “window".
`FIG. 13 illustrates a dialog box 130, generated by
`master process 15 in response to the user’s selection of
`the “create” task of the menu of FIG. 5D. This dialog
`box permits the user to select a view style from a menu
`of available view styles, as stored in various graphics
`engines 12. The user may select any view style, such as
`by means of pointing device 26.
`As a result of step 102, executive 35 takes over pro-
`cessing tasks from master process 15. The graphics
`engine 12 corresponding to the selected view style gen-
`erates a “blank” graph. FIG. 14 illustrates a blank graph
`140, which was generated after the user selected a gantt
`chart view style. The blank graph 140 has a time line
`141, but the user-data area 142 is blank. A menu line 143
`has a menu heading for “configure” tasks.
`In step 103, the user configures the view style by
`specifying at least one record type and at least one field
`ofthe specified record types. Data values for this record
`type and field are the data to be illustrated by a graph
`
`0016
`0016
`
`

`
`9
`having the selected view style. It is assumed that the
`specified record type and field are already part of local
`data store 14. However, means could be provided for
`dynamically passing data to local data store 14 during
`graphing.
`FIG. 15 illustrates a dialog box 150, by means of
`which the computer accepts the user’s configuration
`data in step 103. This dialog box has been generated by
`graphics engine 12, in response to the user’s selection of
`the "configure” task from the menu represented in FIG.
`14. Using the example of employee vacation times, the
`user has entered a record type, "employee”. Each in-
`stance of a. record type, i.e., each record, represenls a
`different employee. As explained above in connection
`with FIG. 3, graphics engine 12 has stored associations
`between the instances of each record type and one or
`more objects. For a gantt chart view style, each in-
`stance of a record type is associated with a bar and a
`label. Vacation stop and start times are fields within
`each record. Graphics engine 12 also has stored associa-
`tions between field data and