Back to EveryPatent.com
United States Patent |
5,179,657
|
Dykstal
,   et al.
|
January 12, 1993
|
Panel definition language for computer display
Abstract
Each panel or display screen of data, is defined by a title and the tagged
description of the objects, such as instruction lines, data entry lines,
menu areas and command lines. Each of these objects may include other
objects, described in the same syntax. Panel definitions are joined in a
source file to form a panel group. Objects can be shared by all panels.
Inventors:
|
Dykstal; David W. (Rochester, MN);
Fishel; Edward A. (Rochester, MN);
Temple; Michael A. (Rochester, MN);
Snyder; Devon D. (Rochester, MN);
Timms, Jr.; George D. (Rochester, MN);
Shi; Samuel R. (Cary, NC)
|
Assignee:
|
International Business Machines Corporation (Armonk, NY)
|
Appl. No.:
|
866964 |
Filed:
|
April 10, 1992 |
Current U.S. Class: |
715/762; 715/708; 715/765; 715/853; 715/866 |
Intern'l Class: |
G06F 003/14 |
Field of Search: |
364/518,521,522,221.9,225.6,226.4,513,948.2,948.21,948.22
340/706,750
395/155,156,157,159,161
|
References Cited
U.S. Patent Documents
4785296 | Nov., 1988 | Tabata et al. | 340/731.
|
4794382 | Dec., 1988 | Lai et al. | 340/703.
|
4802162 | Jan., 1989 | Kakuda et al. | 371/15.
|
4803642 | Feb., 1988 | Muranaga | 364/513.
|
Primary Examiner: Harkcom; Gary V.
Assistant Examiner: Nguyen; Phu K.
Attorney, Agent or Firm: Forrest; Bradley A., Bruzzone; Lauren C., Flynn; John D.
Claims
We claim:
1. A method for generating display panels using a program interface which
provides for defining display panels where the resulting definitions a)
may be used by one or more applications, b) provide consistency of said
defined display panels between said application programs, and c) provide
for independence of panel format from the device on which the display
panel are displayed,
said method used on a data processing system having display devices and
storage means and a processor, said method comprising the steps of:
a. providing a panel definition by means of said program interface by:
identifying one or more display objects, said display objects to be
displayed as part of said display panels, said display objects comprising
instruction lines, data entry areas, menu areas command lines, and
messages;
associating with each of said display objects a display object tag;
specifying for each display panel, a variable title;
associating with said variable title a panel tag; and
associating with said panel tag at least one of said display object tags;
b. storing said panel tag, said display object tags, and said definitions
of said display objects in said storage means;
c. providing to said processor said panel tag by a first application
program, said first application program being stored in said storage
means;
d. accessing said storage means for said processor and locating within said
storage means said variable title associated with said panel tag, said
display object tags associated with said panel tag, and said display
objects associated with said display object tags; and
e. displaying said display panel, comprised of said associated variable
title and said associated display objects, on at least one of said display
devices.
2. A method for generating display panels as in claim 1 in which, in said
program interface, one of said display object tags associated with said
panel tag is associated with a display object which is a message.
3. A method for generating display panels as in claim 1 in which, in said
program interface, one or more of said panel tags comprise a panel group.
Description
TECHNICAL FIELD
This invention relates to describing, retrieving, modifying, handling and
presenting information for plurality of programs to a display device, and
specifically to a screen management system which frees the individual
application programmers from the routine programming associated with
screens and help messages related thereto.
In the development of a new computing system, many programming tasks,
particularly those associated with application programs, must proceed in
parallel. At the time of announcement of a new computing system, it is
essential that sufficient application programs be available to satisfy
customer needs. Potential customers would be unwilling to purchase a new
system that, in effect, they are unable to use because of the lack of
application programs. It is therefore necessary to develop a variety of
application programs at the same time the computing system is under
development. Traditionally, application programs for a new system are
written by the same programming groups who wrote the previous programs of
the same type. This means that each of the application programs for a
given system are written by different groups. In the past, this has led to
each of the application programs having a different "look" in that the
screens have different formats, use different colors for particular
classes of information, place the command lines and messages in different
locations and generally present a different appearance to the operator.
Furthermore, the traditional approach of duplicating display functions in
each application program has led to inefficiencies and complexities
outside of the display itself. For example, data used by more than one
program may be stored by each of the using programs. This occupies
additional storage space and requires that each location be updated when a
change is made.
The lack of screen uniformity among application software programs developed
for a new computing system presents problems in testing the programs.
Since each application program has its own code for presenting the
information to the display device, this code must be tested for each
program, even though its purpose and function is largely redundant.
Further, the help messages generated in response to an operator request
for assistance with respect to specific fields, etc., must be individually
written and tested for each application program.
The difficulties with development and testing are but a part of the
problem. The problem is well known even to those who use personal
computers for nothing more than hobby or home use. Such systems typically
use a variety of application programs from different software sources.
When a switch is made from one program to another, the screen format also
changes. But the problem may also exist with programs supplied by the same
vendor because of the difficulties in simultaneously developing the
application programs.
The lack of uniformity in screens is more than just an inconvenience. The
situation leads to lower operator productivity, higher error rates,
discontented computer operators, and ultimately, to a dissatisfied
computer customer.
BACKGROUND ART
The prior art has been more concerned with the problems relating to
accommodation of different display devices on the same system than the
lack of uniformity of screens between application programs. The prior art
has also addressed the problems which arise when new displays are added to
an old system.
Exemplary of the prior art is U.S. Pat. No. 4,586,158 which describes a
mapping service which effects the interface between the application
program and the physical presentation of the information on the display
screen. Simply stated, the program logic of the mapping service transforms
the data represented in the format of the application program into another
format based on a specified set of rules. There is no suggestion as to how
displayed data common to more than one application program could be
shared. This system operates to change the stored data in accordance with
a set of predetermined rules, and there is no suggestion as to how the
data can be specified so as to be uniformly usable by all the display
devices and screens without the need for reformatting.
DISCLOSURE OF THE INVENTION
A primary object of this invention is to provide a common interface between
data shared by a plurality of application programs and a system display.
Another object of the invention is to provide a display-application program
interface in which the elements which make up a display, i.e., objects,
are specified in generic fashion to allow their use by a plurality of
displays and application programs.
It is another object of this invention to provide a display-application
program interface which accommodates the use of operator help messages
common to more than one application program and display.
Still another object of this invention is to provide a display-application
program interface in which the specification of the objects in a given
panel provides the basis for the selection of appropriate operator help
messages.
These and other objects, features and advantages are realized by an
application program-display interface which utilizes tags to reference all
objects, which, for example, may be a panel, i.e., a panel title, a single
screen of data, instruction lines, data entry areas, menu areas or command
lines. Each tag includes a tag name and one or more attributes.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a block diagram representation of the operation of the invention.
FIG. 2 is an example of a sample list screen developed with this invention.
FIGS. 3a-3d are block diagram representations of the programming aspects of
this invention.
DESCRIPTION OF THE INVENTION
A screen oriented, high level language is used to define and manage a
display screen as shown in FIG. 1. In a data processing system which
utilizes a number of application programs, the system programmer will
define the screens for a given application program using the high level
language as depicted in block This program is then compiled by the
compiler 2 which creates the panel group objects 3. The application
program 4 interacts with the panel group objects by means of the panel
application execution support 5, which accesses the variable pool 6 and
interfaces with the device support 7. The display device 8 is operated
under the control of device support 7.
"Objects", which are the items placed on the display screen, are designated
by means of tags. Each tag may have attributes which further define the
nature of the object. Objects which need to be referenced either in the
source or at run time by an application program, possess a name attribute.
Many objects will also have associated text which immediately follows the
tag.
The syntax of a tag follows the format:
##STR1##
Text associated with the object.
The fundamental object in the language is the "panel" described by the
"panel" tag. Each panel consists of its text, which is a title, followed
by the tagged descriptions of the objects, which make up the particular
panel. Such objects include instruction lines, data entry areas, menu
areas and command lines. These object may, in turn, be made up of other
objects, all described with the same syntax.
Panel definitions are grouped together in the source file to form a "panel
group". All panels in a group are capable of sharing definitions of other
named objects defined in the panel group. All objects which can be shared
among several panels, such as function key lists, are used by specifying
their names on the appropriate attributes of the panel tag as shown in the
following illustration.
##STR2##
In addition to panels, other objects are declared in the panel group. These
facilitate the definition of panels by providing an encapsulation of some
sort of shared characteristic.
"Classes" are used to define a set of common attributes for the data to be
displayed on a panel or used for control purposes. They provide a very
simple means of data abstraction that can be applied to this data.
Characteristics include:
The base type of the values, i.e., packed, binary, etc.
Shift characteristics for input fields for variables of this class.
Number of character positions a value of this class should occupy on a
display.
Translation to/from internal value from/to display value.
Checking of values entered on the display to meet certain criteria, i.e.,
range or specific value checks.
"Variables" define the actual data used by an application in this panel
group. Variables are given a name and reference a class. All variables
declared in this panel group are collected into a data structure called a
"variable pool", manipulated by the application program.
"Conditions" are objects which influence the inclusion of other objects
when that panel is displayed. A condition is specified in a "minilanguage"
attribute of the condition tag. That condition is then evaluated during
application program execution to control the inclusion of panel elements.
"List Objects" provide an object which consists of rows of like columns of
data. An application execution interface allows the contents of a
particular row to be exchanged with a set of variables from the variable
pool. A "List Area" is an object found in the panel which provides the
viewing characteristics of this underlying data object. "Truth Tables" are
objects which control the mutual exclusion of conditional items in a panel
object. Application program developers use truth tables to provide
information to the compile time formatter concerning which of the panel
elements are never coexistent on the same panel.
"Key Lists" can be shared among panel objects to define actions which take
place on that panel when keys, in particular, function keys, are pressed.
"Panels" at the object that maps to the actual display surface. Panels use,
either directly or indirectly, all of the above objects.
The following is an outline for the source describing a set of interactive
panels:
______________________________________
Panel Group (:PNLGRP)
______________________________________
prolog section
class definitions
(:CLASS)
variable definitions
(:VAR)
list definitions
(:LISTDEF)
condition definitions
(:COND)
truth table definitions
(:TT)
key mapping list definitions
(:KEYL)
body section
panel definitions
(:PANEL)
area definitions
(:MENU,:INFO,:DATA.:LIST)
command/option line
(:CMDLINE,:OPTLINE)
definition
help module definitions
(:HELP)
ISIL tagged test
______________________________________
FIG. 2 shows a sample list panel. The first step in implementing this panel
is to define the screen using the tag language. The following tag source
produces the desired screen.
The first step in implementing the panel of FIG. 2 is to define the screen
using the following tag source producing the desired screen.
The following describes skeleton help text necessary to support the panel
of FIG. 2. It would be stored in a panel group names ElHLPGRP. The help
could also be stored in the same panel group object, manufactured supplied
help should normally be stored in separate panel group objects so it can
be loaded onto the system or not at the user's option.
With reference to the programming data flow charge of FIGS. 3a-3d, which
show the sequence of functional operations effected by the program
instructions, operation of the program begins block 500 when the
application program opens the panel group. The application program has to
be told which set of panels is going to be used, in other words, a name is
given to the panel group to be handled. The application then goes into the
main loop via block 501, where it sets the value of the variables in the
variable pool. The variables are a set of values that are identified by
their names and they can hold values which are data that the application
can use. The values are set by referring to data in the application
program and copying this data into the variable pool.
The display panel service of block 503 is that which actually performs the
display of the panel. The following decision block 505 is actually in the
display manager itself. The function of this block is to validate the
request and make certain that the panel requested is the panel group.
In block 503 the application retrieves values that the user has altered on
the display and does this by accessing the variable pool again and pulling
these values out. This process is repeated by the decision made in block
504, which returns the program to block 501, until all variables have been
retrieved.
When the application is complete, the decision in block 504 passes the
program to block 506, where the application closes the panel group.
The display leg of the program begins with block 510, in which the
conditions being used on the panel are checked. This step gathers up the
conditions which are to be evaluated for the panel under consideration.
Each panel has a distinct set of conditions. The panel language has a
separate language inside of it for defining conditions that can be used to
exclude or include elements onto a panel for display. Examples include
function key definitions, which may be excluded from the screen, and
thereby hold the function key in the inoperative state. The help text
relating to the excluded function key is also blocked from display. Thus,
when an object has been excluded, there is no remnant of that object.
In block 511, the conditions are evaluated, referencing the values that are
in the variable field as well as system objects. An example of the latter
category would be an item on the main menu of the system. It might be
desirable to exclude certain menu items if the user does not belong to a
class which, for example, is allowed to write into a particular field.
In block 512 the actual elements to be displayed are examined, and, in
block 513, the decision is made as to whether the object is to be
displayed. Each object may be conditioned or not. If it is not
conditioned, it is displayed. If it is conditioned, the value of the
condition is checked and, if it is true, the object is included for
display.
Objects are assigned their appropriate positions on the display in block
514. The tentative position is assigned at compile time. The final
position is subject to verification in this block.
Appropriate attributes are assigned to each object in the operation of
block 515. Highlights, color and things of that nature are mapped to the
display in accordance with the type of object, such as an instruction
line.
The decision in 516 relates to determination of whether a variable value is
involved for the particular object under consideration. Some objects, such
as menu items, do not have a variable value and therefore do not require
anything to be retrieved. Other objects, for example, data items, have
displayed values which are given through the variable pool, necessitating
an access to the pool, as shown in block 517, to retrieve the object for
display. Any required conversion is also performed in this block. For
example, a value may be stored in binary form and must be converted to
decimal for display.
After this process has been completed for all objects on the display, as
determined by block 518, a data stream is constructed from the developed
list of objects and positions as shown in block 519. If all objects have
not been considered, the program loops back from block 518 to the input of
block 512, considering all objects in turn.
Therefore, at point A there has been established a new data structure which
is essentially a list of all objects to be displayed with their
attributes. The data stream is sent out to the display device in block
520. The data stream is interpreted and presented to the user by the
display device. At block 521, the user views the screen, fills in the
appropriate information and presses a function key to send the entered
data, in the form of a data stream, back to the system, at block 522.
The data stream, as before, consists of locations and values. The operation
at block 523 requires an examination of the function key pressed in block
521. If the function key related to a variable which is to be updated, the
test at block 523 leads to block 524, which correlates the screen location
with a particular object. Having identified the object involved, the
object is examined in block 525 to see which of the variables in the
variable pool is involved. The variable class is then checked to block 526
to see if there is any validity checking involved for the particular
variable under consideration. If checking is involved, block 527 is
entered and the appropriate checks are performed.
Block 528 operates in the result of the check. If the check failed, the
process passes to block 529 where the entered value is tagged as an error.
The data tagged as an error is then reshown on the display, block 530, and
the work station user is given the opportunity, in block 531, to reenter
the data correctly. Since the user may have made another error, the
program returns to block 522 and the checking process is repeated to
ensure that the new data is correct.
When the entered data passes the validity check, the operation of block 532
causes the variable value to be updated and the program loops back to the
test in block 523 to see if all the variables have been updated.
Eventually, the variable updating process is completed and the test in
block 523 indicates that there are no remaining variables to be
considered. The program then proceeds to block 540, where the function
keys are examined to determine what dialog action is to take place. This
is accomplished by mapping the function keys to the appropriate dialog
action.
If the dialog action implies a return to the application, the test in block
541 passes to block 542 which effects the return to the application as
shown. If other dialog action is indicated, the test performed in block
543 is performed to see if the dialog action is help. If the help action
is requested, the block 544 begins the determination of what help was
requested by determining the cursor position and correlating it to a
specific object. Next, the display object identified in block 544 is
tested to see what sort of object it is. The test in block 545 determines
whether or not the object being evaluated was a command line.
If this test indicates that the object under consideration is a command
line, the test in block 546 determines whether or not a command has been
entered. If there is an entered command, block 547 serves to invoke run
time support and display the help message for the specific command. If no
command has been entered, the test of block 548 determines whether the
command line had a menu option. If so, the block 549 selects the menu item
as the object for the purposes of determining which help message should be
displayed.
If the selected object is not a command line, as determined in block 545,
or is not a command line with a menu option, as determined by block 548,
the action in block 550 serves to display help for the selected object.
At block 560, a help list is constructed corresponding to all the objects
on the panel, excluding those objects which were conditioned out. The
first and last items on the list for which help is to be displayed first
are so marked. In the usual case, this will be a single item corresponding
to the selected object.
In block 561, the help application is invoked to display the help panels
which are needed to get the help panel for the particular user panel. If,
at this point, the user presses a function key requesting extended help,
block 562 transfers operation to block 563 which presents extended help to
the user. This will generally be all the help messages relating to all the
objects identified. The user than takes appropriate action, for example,
indicates that the use of the help message has been completed, as depicted
in block 564, and the program returns to point A.
Returning now to block 543, if the test indicates that the dialog action is
not help, block 570 tests to see if the dialog action was something which
can be handled directly by the display manager, such as rollup, rolldown,
or change view. If it is, runtime support performs the function and the
program returns to point B as shown in block 571.
If the test in block 570 indicates that it is not a dialog action which can
be handled directly by the display manager, block 580 looks to see if it
is a command request. If it is, the request is submitted to the system in
block 581 and the program returns to point A. If it is not, block 582 is
entered and either a return to the application occurs or the panel is
reshown, depending on how the user coded the panel to handle a null
situation.
Top