“fl“MM“m“MHMHNHHNWHHHNHWHHWHHMHM
`USODS414309A
`
`United States Patent
`
`[19]
`
`[11] Patent Number:
`
`5,414,809
`
`Hogan et al.
`
`
`
`[45] Date of Patent: May 9, 1995
`
`[5 4] GRAPHICAL DISPLAY OF DATA
`
`[75]
`
`Inventors: Patrick M. Hogan; Rhonda L.
`Alexander; Lars Greninger; Lloyd J.
`Arrow, all of Austin, Tex.
`
`[73] Assignee: Texas Instruments Incorporated,
`Dallas, Tex.
`
`[21] Appl. N0.: 56,703
`
`[22] Filed:
`
`Apr. 3|), 1993
`
`Int. (31.5 .............................................. GOSF 15/62
`[51]
`
`............................. 395/155
`[52] US. Cl.
`[58] Field of Search ............... 395/155, 161, 140, 141,
`395/ I42; 345/ I 13, 125
`
`[56]
`
`References Cited
`U.S. PATENT DOCUMENTS
`
`5,257,349 10/1993 Alexander
`5,289,568
`2/1994 Hosoya et a1.
`5,307,036 4/1994 Grifl‘in et a].
`
`395/159
`
`..... 395/135
`395/146
`
`Primary Examiner—Pm K. Nguyen
`Artemey, Agent, or Finn—Robert L. Troike; Richard L.
`Donaldson
`
`ABSTRACI‘
`[57]
`A method of using a computer system 20 to implement
`a graphical interface 10. The method displays a graph
`160 of data from a database system 11, and permits a
`user to change the data by changing the appearance of
`the graph 16!). The graph 160 is generated from a stored
`graphics engine 12, which contains rules for generating
`graphical objects comprising the graph and the objects‘
`attributes. The graphical objects and attributes are
`matched to data delivered from the database system 11.
`If the user manipulates a graphical object, the graphical
`interface 10 associates the change to a new data value,
`and updates both the graph 160 l and the data in the
`database system 1].
`
`2|] Claims, 11 Drawing Sheets
`
`
`
`USER SPECS
` DATABASE
`SYSTEM
`1
`I
`DATA
`
`
`l
`I
`
`
`
`I
`I
`l
`I
`:
`Reagent
`i
`l
`
`l
`l
`14 I
`EDIT I
`12
`I
`i
`
`
`
`
`
`GRAPHICS
`GRAPHICS
`
`ENGINE
`ENGINE
`
`
`
`(GANTT)
`(TREE) '
`
`
`
`
`
`I
`
`I I
`
`:
`I
`I
`.
`
`COMMAND
`
`I
`
`I
`:
`I
`I
`.2
`
`TDA 1011
`TDA 1011
`CBM of U.S. Pat. No. 7,533,056
`CBM of US. Pat. No. 7,533,056
`
`0001
`0001
`
`

`

`US. Patent
`
`May 9, 1995
`
`Sheet 1 of 11
`
`5,414,809
`
`
`
`‘5
`
`FIG.
`
`1
`
`H
`
`
`
`17
`
`USER SPECS
`DATA
`
`
`
`
`
`
`'
`RECORD EDITI
`
`r———— l
`14 }
`COMMAND'
`
`
`
`ENI
`
`
`
`GRAPHICS
`GRAPHICS
`ENGINE
`ENGINE
`
`
`
`Ufifl
`(GANTT)
`
`
`
`
`———--—¢——u-————————-flu—-——
`
`ROOT LIBRARY
`DATA HANDLING
`
`PRIMIHVES
`
`0002
`0002
`
`

`

`US. Patent
`
`May 9, 1995
`
`Sheet 2 of 11
`
`5,414,809
`
`5‘
`
`FIG. 5
`
`file
`
`Edit
`
`Linking
`
`flaws
`
`window
`
`Qammands
`
`Salary
`
`Organizafion
`
`FIG. 5A
`
`
`E—
`gdit
`Linking
`Ejews
`Vjindow
`gammands
`Help
`
`
`
`HE]
`
`
`
`
`
`
`
`_
`Organization
`
`m [1
`H
`Salary
`
`
`
`
`
`Qpen...
`Merge...
`Save
`Save As...
`
`Export...
`impart...
`
`Siafisfics
`
`Exit GrA'r'
`
`0003
`0003
`
`

`

`U.S. Patent
`
`May 9, 1995
`
`Sheet 3 of 11
`
`5,414,809
`
`FIG. 5B
`
`
`
`
`flindow
`Yjews
`inking
`
`
`Configuration...
`Tes’r Application Menus
`I>
`
`Record Types...
`
`Enumeration Types...
`
`flaia Hams...
`
`Eiiiers...
`
`gods...
`
`
`
`
`Links...
`IEF Ania Link...
`
`Commands...
`
`Edit Conirol...
`
`Quick Command...
`
`
`
`golors...
`Eons...
`
`Associations...
`
`_ L
`
`Qammands
`
`Help
`
`
`
`file
`
`Edit
`
`mews
`
`flindow
`
`Qommands
`
`Help
`
`
`
`Location
`
`0004
`
`FIG. SC
`
`
`
`_=Ei
`
`
`
`Ium Linking 0n
`
`Turn Linking flfi
`
`
`
`
`Vacafion Refresh links
`
`
`fll—‘I
`
`E='
`
`
`
`

`

`US. Patent
`
`May 9, 1995
`
`Sheet 4 of 11
`
`5,414,809
`
`FIG. 5D
`
`
`
`|—-_MasterProcess
`
`file
`gait
`Linking
`flindow
`gammands
`Help
`
`grea’re...
`
`Ins
`
`
`
`Vacafion
`
`Space
`Cfl+lns
`Del
`
`gopy...
`flelefa...
`
`fihow
`Clgse
`
`
`
`
`
`
`HE
`
`
`
`
` froperfies...
`
`
`
`
`
`
`
`Efl- ':
`
`Locofion
`
`Shag All
`yinimize A1!
`5 Close All
`
`
`
`
`
`
`EIiIEN—fiil
`
`
`
`
`Field Type
`
`
`—m
`—-
`
`
`
`
`
`
`
`lM—IIEI
`
`0005
`0005
`
`

`

`US. Patent
`
`May 9, 1995
`
`Sheet 5 of 11
`
`5,414,809
`
`FIG. 7
`
`Enumeraiion Type Edifor
`
`En umerufion Type
`
`
`
`Elf—‘1
`
`—|IEI
`
`Consfcm’rs
`
`
`
`
`
`
`
`
`
`
`
`m |—_1-m-III
`
`U
`
`_l§!
`
`E
`
`Table
`
`Enumerafion Type
`BadgeCoior
`
`Graphic Aflribu’re
`
`.
`
`0006
`0006
`
`

`

`US. Patent
`
`May 9, 1995
`
`Sheet 6 of 11
`
`5,414,809
`
`FIG. 9
`
`lLink 1: 0?? Gel Excel.
`
`{2: GRA
`
`DEMO EMPDEHDXLS, momsacw
`
`|:
`
`External
`
`GrAF
`
`[I Enabled
`
`Application
`Topic C:\GRAF\DEMO\EHPDE
`[tern R1C1:R6001U
`
`|_|
`Record Type Employee
`Key Value :I
`Field CE
`
`DKay Generation
`I Paste from Clipboard I
`m Type: _I °°m°°s'*° “m D
`
`[:lTranspose
`
`EIDynarnic
`
`FIG. 70
`
`100
`/
`
`Command Editor
`
`_ename..._elete...
`
`Show Praieo’r Employee Couni
`
`
`
`Appncofion: I::I Topic: :3I____:resrcommunal
`
`Command String:
`
`
`
`
`
`
`
`View Salary display slack Proie—cl:display sari Badge <;disla couE—
`
`
`
`
`
`DRequires Selectable
`
`Hem of Type:
`
`E Include an Menus
`
`
`
`l_rAFCommandl
`
`0007
`0007
`
`

`

`US. Patent
`
`May 9, 1995
`
`Sheet 7 of 11
`
`5,414,809
`
`\
`
`FIG.
`
`1 1
`
`
`
`
`
`
`
`
`
`
`Creole
`
`0 N01 Allowed
`
`0 Local
`
`0 Remote Command
`
`Update
`
`0 Hal Allowed
`
`
`
`0 Local
`O Remole Command(s)
`DRernoie Editor
`
`DUpdale Nolifiaalion
`
`Record Tum—191 _
`
`
`
`| Command Editor...
`I
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Delolo
`0 Not Allowod
`
`
`
`
`0 Local
`O Remolo Command
`
`
`
`
`
`
`FIG. 12
`
`STORE GRAPHICS ENGINE
`
`100
`
`SET UP LOCAL DATA STORE
`
`101
`
`USER SELECTS VIEW STYLE
`
`102
`
`USER CONFIGURES VIEW STYLE
`
`103
`
`DATA MATCHED T0
`OBJECTS AND ATTRIBUTES
`
`DISPLAY GRAPH
`
`USER SELECTS
`OBJECT T0 EDIT
`
`104
`
`”35
`
`106
`
`YES
`
` 9
`
`N0
`
`USER MANIPULATES
`OBJECT
`
`
`
`1070
`
`USER ENTERS TEXT
`
`107b
`
`UPDATE GRAPH
`
`1090
`
`UPDATE LOCAL DATABASE
`
`1 09b
`
`UPDATE EXTERNAL
`DATABASE
`
`0008
`0008
`
`

`

`US. Patent
`
`May 9, 1995
`
`Sheet 8 of 11
`
`5,414,809
`
`_...
`
`i._
`
`150
`\.
`
`FIG.
`
`7 5
`
`
`
`
`
`Record Type
`—EI
`Stud Time Field
`VocStor’t
`510]) Time new
`VooSfop
`
`
`
`
`My
`
`
`
`Source
`
`
`Gonfi Bars
`
`
`
`
`Row Height E
`
`Time Granulori’ry
`
`
`
`© seconds
`
`El
`0 minufes
`
`
`
`0 days
`
`
`[El
`
`
`
`
`
`Options
`Notch Size
`
`mm
`IZDoio Direc’r Manipulation
`
`
`
`
`| Background Color...
`I
`
`
`0009
`0009
`
`

`

`US. Patent
`
`May 9, 1995
`
`Sheet 9 of 11
`
`5,414,809
`
`W
`
`FIG. 16
`
`
`
`
`32
`
`291
`
`291
`
`3 |i_|
`
`
`
`
`
`
`IE—IEI
`
`Configure
`Edit
`Kiev:
`Qammands
`flindow
`Heip
`December
`Januarya
`February|lJ|
`
`
`'5-un,Jack
`
`
`
`Hannesberg.
`Turkmenis, St
`
`
`
`Hilts, Travis
`
`SoInt Lauren
`
`Falls, Victoria
`
`
`160
`
`
`
`_m we!»
`
`Qommands
`
`window
`
`Help
`
`a
`15
`22
`
`
`lns
`Create...
`_rugon.Franv Edit...
`Enter
`
`
`
`Delete... Del
`
`
`
`E
`
`IE—a
`
`
`
`—___Undo CtrI+U
`January
`
`
`
`Turkmenis, St
`
`Hills, Travis
`
`
`Saint, Lawren-
` Folls, Victoria
`
`
` LEE
`
`
`0010
`0010
`
`

`

`US. Patent
`
`I May 9, 1995
`
`Sheet 10 of 11
`
`5,414,809
`
`F10.
`
`7613
`
`I’_aEl
`Cogfigure
`E_dl’r
`Qommonds
`window
`Help
`
`
`
`
`
`
`L": Ear Sfyles...
`
`Bur Legend
`Cer-L
`
`
`
`'3 Label Styles...
`
`Label Legeng Shiff+Cfrl+
`
`
`
`
`
`
`
`
`
`
`Arogon, Fran
`
`Sun. Jock
`
`Honnesberg,
`
`Turkmenis, Sf
`
`Hills, Travis
`
`Soin’r, Lowran-
`
`Folls. Viciorio
`
`ElEl
`
`FIG. 76C
`
`FE—EEl
`Configure
`Edit
`yjew
`window
`Help
`
`February
`Show Projec‘l Employee Counl
`
`
`291
`22
`Show Proiecl Solory Totals
`
`Show Solonr Bors
`
`
` 1 H
`
`IE]
`_
`
`
`
`0011
`0011
`
`

`

`US. Patent
`
`May 9, 1995
`
`Sheet 11 of 11
`
`5,414,809
`
`FIG
`160‘1
`
`
`
`E—afil
`window
`IE[
`February
`January
`
`291
`a1'|!l
`22
`15
`291
`a
`22
`15
`
`
`
`Configura
`
`Commands
`
`Help
`
`Kiev
`Edi!
`December
`I
`a
`
`
`
`
`
`E“—
`
`Aragan. Fran-
`
`Sun, Jack
`
`Turkmenis, Si
`
`
`
`
`FIG.
`
`7 8
`
`§alary...
`
`EacS’rarf...
`
`§fa+us
`
`Eraieal
`
`Ehane...
`
`Name Hills. Travis
`Salary £700
`
`Vacharf 1%?9291
`
`VacSiop 1?
`Badge YELLOW
`Sia’rus ACTIVE
`
`Office SC
`
`_
`
`§lLVER
`
`90m
`
`Proiecf Nianagemen’r
`Phone 555-4552
`
`Manager Straih, Cycle
`
`FIG. 79
`
`E—afil
`
`
`
`
`
`
`Name
`
`Vac Siar}
`Salary
`Badge Colar-
`
`Vac Sfap-
`EmpLstaius MEI.
`
`Profiecf
`
`Phone Number
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Name —|21
`
`
`l
`_dit
`l—l
`
`
`
`
`0012
`0012
`
`

`

`1
`
`GRAPHICAL 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- ‘5
`tween a set of data values taken at difi'erent 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
`
`4S
`
`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 receiver. 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 Inca] 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 innplementing the method of the invention.
`FIG. 2 is a computer system for executing the method
`of the inventiou.
`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. SA—SD 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 assoeia-
`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 engine 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 fbr
`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 employee’s vacation.
`Thus, in FIG. 3, two graphical objects represent each
`employee. If Employee B’s vacation time data is the
`value “weel: 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
`
`IO
`
`15
`
`2t}
`
`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
`1’? is accessed by master prooess 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 37 are dynamically linked librar-
`ies. In a whidows environment, master process 15 and
`executive 35 each control their own window. Altema—
`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 diaplay screen 50, which presents
`to the user a selection of tasks performed by master
`process 15. FIGS. 5A—5D illustrate the pulldown
`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. SB,
`are explained below in connection with FIGS. 6—11.
`“Linking” tasks, listed in FIG. 5C, set up links among
`subscribing applications. “Views" tasks, listed in FIG.
`51), are explained below in connection with FIGS.
`12—20. “Commands” tasks are explained below in cou-
`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 slayer 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
`
`SO
`
`55
`
`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 rte-Spouse,
`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 exertiple, each employee’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 eu-
`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. SB.
`Using dialog box 80, 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
`“badgecolor” 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 “commands"
`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 BBB
`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
`
`55
`
`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 boar
`110 also permits the user to Specify a remote command,
`such that if data is modified via graphics interface 10,
`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 1'? is stored in
`memory 23 for use by graphics interface 10 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 F