Note: Descriptions are shown in the official language in which they were submitted.
2 ~
SA9-89-047
WINDOW DISPLAY SYSTEM AND METHOD
BACKGROUND OF T~E INVENTION
l Technical Field:
The present invention relates generally to
computer system displays, and more specifically to a
technigue for displaying windows on a computer display
having a minimal amount of support for displaying
windows.
,:
2. Bac~y~ Art:
The display of information generated by an
application program running on a computer system is often ~-
important to the perceived use~ulness of the application.
Poor displays can render an otherwise good application
nearly useless, and good displays can help a user make
more efficient use of an appIication. ;~
Windows are often used to display several items
of information on a screen at the same time. Windows are ~ ~;
separate regions, often separated by borders, which are
treated somewhat indepsndently. Different windows may
receive output from different applications running
concurrently9 and a single application may generate
output to several windows.
In general, windows may be displayed as tiled
or overlapped. Tiled windows are displayed side-by-side ;
horizontally or vertically, or both, with no overlap of
their displayed regions. Overlapped windows appear to be
stacked bne on top of another, much as individual sheets
of paper piled on a desktop, with the covered portions of
lower windows not being displayed. This type of display
is sometimes referred to as the desktop metaphor for
displays, or messy desk windowing. Work stations coming
s~
SA9-89-047 2
into increasingly common use typically have powerful
window display systems to support messy desk windowing.
Many mainframe based applications, typically
descendants of applications written before work stations
started becoming common, are often written for character
based, non-programmable terminals. Some terminals
designed for tying into larger, central computer systems
support rudimentary graphics or character graphics
capabilities, or provide for designating portions of the
display screen as active for scrolling purposes. The
combination of many available terminals and their
software drivers often provides the ability to do an
extremely limited form of windowing. This form of
windowing, referred to as split screen windowing,
typically has full width tiled windows stacked vertically
on the screen. These windows often have no borders, and
only scrolling of the entire window is allowed.
It would be desirable to provide a windowing
system for non-programmable terminals which supports
messy desk windowing. It would also be desirable to
provide a high level interface for application programs
which hides the details of the window system and provides
callable services similar to those available on work
stations. It would further be desirable for such a
windowing system ~o be efficient on non-programmable
terminals.
~UMMA~Y OF 1~ INVENTI~N
It is therefore an object of the present
invention to provide a window system which supports
multiple, independent windows on non-programmable display
terminals
.
It is a further object of the present invention
for such a windowing system to provide operations on
individual windows which manipulate these windows while
hiding the operating details from an applications
programmer.
2~2~ ~3
SA9-89-047 3
It is another object of the present invention
to provide such a windowing system which operates
efficiently on non-programmable terminals.
Therefore, according to the present invention,
a windowing system is provided as an interface between
application programs and non-programmable terminal
drivers The system presents logical windows to the
applications program, each of which are represented
internally by at least two separate parts. The first
part includes the border and non-scrollable text for a
logical window, while the second part includes scrollable
text for the window. Through calls to the display
driver, the windowing system manipulates these separate
parts so that they are displayed on the screen as a
single window.
BRIEF DESCRIPTION OF ~E DRAWINGS
The novel features believed characteristic of
the invention are set forth in the appended claims. The
invention itself however, as well as a preferred mode of
use, and further objects and advantages thereof, will
best be understood by reference to the following detailed
description of an illustrative embodiment when read in
conjunction with the accompanying drawings, wherein:
FIGURE 1 shows a simplified display
illustrating messy desk windowing;
FIGURE 2 illustrates several different portions
of a single logical-window;
FIGURE 3 illustrates the use of two separate
regions displayed together to represent a single logical
window;
FIGURE 4 is a block diagram illustrating a
system for displaying windows on non-programmable
terminals;
2 ~
SA9-8g-047 4
FIGI ~ 5 is a block diagram of a window manager
system;
FIGURE 6 illustrates details of a window
control block; and
FIGU~E 7 illustrates details of a data cluster.
DESCRIPTION OE T~ L~K~ED EMBODIMENT
Figure 1 shows a samp]e computer display screen
illustrating the use of overlapping windows. The display
10 can be nearly any CRT display terminal such as known
in the art. The border 12 outlines that region of the
display on which visual information is presented to the
user. Other portions of a typical computer terminal,
such as keyboard, housing, and brightness/contrast
controls are not shown.
On the display 10 tex-t 14, 16 can be shown, as
well as character graphics 18 used to form lines. Within
the display area, 4 windows 20, 22, 24, 26 are shown in
overlapping fashion. Each window is a rectangular region
outlined by a border, and portions of a window which are
overlapped by other windows are not displayed. For
simplicity of illustration, the windows shown in Figure 1
do not contain text, although text is generally present
in windows during actual use.
As shown in Figure 1, window 26 is -the
uppermost window, followed in decreasing order by windows
24, 22 and 20. Thus, window 20 is on the bottom of the
stack, and any portion thereof which is overlaid by any
other window is not displayed on the screen 10.
The size and location of the windows 2C, 22,
24, 26, as well as their order in the stack, is
determined by the user or the applications programs.
Preferably, the size and location of the windows can be
changed by the user more or less at will, so that any
~'' 2~Y,?J3
SA9-89-047 5
given window s location in the future is indeterminate.
The applications programs which write to these windows
must be able to do so independently oE a windows si~e or
location.
Many windows to be displayed have the property
that some of the information therein, including the
border, remains relatively static. Fig~re 2 illustrates
a typical window 30 having a border 32 surrounding it and
a window title 3~ located in the border 32. Header text
36, typically providing informational instructions for
the user, is positioned near the top of the window 32.
In some window systems, a dividing line 38 may be drawn
between the header text 36 and the remainder of the text
in the window 30. At the bottom edge of the window 30,
bottom text 40 is sometimes used to display further
information and instructions to the user. The remainder
of the window 30 is a scrollable region ~2, consisting of
the entire region between the bordexs 32, below the
dividing line 38 and above the bottom text 40. This
region 4~ is written to by the applications programs, and
typically scrolls when it becomes filled with text.
Those portions of the window 30 not in the
scrolling region 42, including the border 32, title 3~,
header text 36, dividing line 38, and bottom text 40, are
relatively static. The scrollable region 42 is
relatively dynamic, with updated information being
written thereto on a fairly regular basis.
The windows described in connection with
Figures 1 and 2 can be implemented by an applications
programmer in a fairly s-traightforward manner on most
personal work stations and some desktop computers. This
is so because many of these machines are designed with
built-in support for comple~ windowing functions.
However, non-programmable, character based terminals
typically used with mainframe computer systems are not
able to support such windowing functions. Figure 3
illustrates a concept according to the present invention
2~2~323
SA9-89-047
which allows an efficient implementation of messy desk
windowing with such non-programmable terminals.
Referring to Figure 3, a window 46 is divided
into an outer region 48 and an inner region 50. The
regions 48, 50 are considered as independent regions for
display purposes, but are displayed overlapping as shown
in order to present a single logical window to a user.
The outer region 48 contains non-scrollable information
which changes relatively infrequently, while the inner
region 50 contains relatively dynamic text. For exampl0,
the outer region 48 will include the window border,
title, and header and bo-ttom text. The inner region 50
does not contain a border, and consists primarily of
scrollable text information.
The character based, non-programmable terminals
typically utilized with the present invention, together
with their software drivers, typically provide scrollable
placement of text within a defined region. However, they
do not provide for scrolling of a part of a region while
retaining the remainder of the region intact. Thus,
defining a logical window to be two independent regions
allows the scrollable portions of the display to be
driven independently from the non-scrollable portions.
This allows ~or greatly increased efficiency when writing
scrollable text to a window. The terminals and drivers
also handle the extended data stream at the region
boundaries, so that fonts, color, blinXing, and other
display attributes are correctly handled within each
region. Some terminals are capable of supporting
graphics and animation to various degrees.
~ s will be described in more detail below, a
window may have more than two independent regions. For
example, a single logical window could have an outer
region containing relatively static, non-scrollable text,
and two or -three separate scrollable regions within its
boundaries. The separate scrollable regions are
pre~erably placed adjacent to each other with no overlap.
Some logical windows may not include both scrollable and
~2~2.~
SA9-89-047 7
non-scrollable regions. For example, a window could
contain only fixed information which is not changeable by
the user, and such a window would not need an inner,
scrollable region 50.
Figure 4 is a high level bloc~ diagram
illustrating a preferred system for performing windowing.
An application program 60 performs output relative to a
terminal by making procedure calls to a window manager
subsystem 62. The window manager 62 is a collection o~
procedures and data structures, described below in more
detail, which manages the function of the logical windows
which the application program 60 expects to see. The
window manager is in communication with a display manager
64 which in turn communicatas with a display terminal 66
over a data link 68. The display terminal 66 is often
located at a site remote from the central computer
system, so the data link ~8 is typically a serial
communications lin~ which may include one or more
telephone or satellite links.
The display manager 64 is a software subsystem
which resides in the main computer, and drives the
display terminal 66. The display manager 6~ sends
characters to the terminal 66 to be d:Lsplayed, and also
sends control sequences to the terminal ~6 to position
the cursor, highlight text, and perform other display
functions. Information entered into the terminal 66 by a
user is received by the display manager 64 and
transferred to the application program 60 through the
window manager 62. An ex.ample of a typical display
manager 64 subsyste~ ~uitable for use with the present
invention is a product known as GRAPHICAL DATA DISPLA~
MANAGE~ (GDDM), a product which is available from IBM
Corporation and currently in wide use.
Figure 5 illustrates more details of the ~indow
manager 62. Communication with the application program
60 and the display manager 64 are made through window
services ~0. Window services 80 is a collection of
procedures, callable by the application program, which in
2~2~2~
SA9-89-0~7 8
turn make procedure calls to the display mana~er
subsystem. Pseudocode descriptions of the operation of
some of the more important procedures wi-thin the window
services 88 are set forth in the ~ppendix, and are
described in more detail below.
The window services procedures 80 access a
plurality of data structures referred to as window
control blocks 82, 84, ~6. Each window control block
corresponds to one logical window, and contains all of
the information necessary to generate and control both
the scrollable and non-scrollable portions of a logical
window. Whenever a new logical window is created by the
applica-tion program, a new window control block is
allocated and made available to the window services ~0.
When a window is deleted, the corresponding window
control block is deallocated.
In addition to header information, each-window
control block 82, 84, 86 contains pointers to one or more
data objects 8~. These data objects 88, also referred to
as clusters, contain the text which is sent to the
display manager for display on the terminal. In one
embodiment, the application can place data into the data
objects 88, from which it is extracted by the window
service 80 for transmission to the display mana~er. As
an alternative, using a somewhat more object-oriented
approach, the application writes data to a logical window
by calling a window service ~0, so that the application
has no direct access to the data objects 88. Different
data objects 88 are used for different portions of a
logical window as ~own in mora detail in Eigure 6.
Referring to Figure 6, a preferred internal
structure for one window control block 82 is shown. One
portion 90 of the window control block 82 contains
general in~ormation relevant to the logical window. This
information 90 includes a window type, such as primary
window, pulldown window, or pop-up window. The location
of the window is included, which informa-tion generally
comprises X and Y coordinates for one corner of the
~2~23
SA9-89-047 9
window. The size of the window, in terms of number of
rows and number of columns is also included, as is
various window status information. Miscellaneous
information pertaining to the logical window, such as a
window title if there is one, and the identity of the
application program associated with this window, can also
be included here.
A next portion 92 of -the window control block
82 includes identifiers for the partitions used to make
up the logical window. A partition is a logical region
used by the GDDM display manager, and corresponds to the
regions ~8, 50 described in co~mection with Figure 3.
Thus, in a preferred embodiment, one partition is
dedicated to the non-scrollable region 48 of a logical
window 46, with the remaining partitions being used for
one or more scrollable regions 50. A typical window will
have one non-scrollable partition and one scrollable
partition. Additional scrollable partitions are normally
needed only for complex scrolling operations, such as may
occur when row or column headers are to remain static
within the scrollable region.
A data portion 94 contains pointers to data
clusters 88 which, as described above, contain the text
to be placed into the logical window. The data may be
organized in any manner convenient for use with the
display manager 64, with the arrangement shown in Eigure
being useful for use with a GDDM display manager 64.
In the data portion 94, several pointers to
data located in the non-scrollable partition are first.
A border cluster pointer 96 points to a cluster 88
containing the field definitions, described below,
containing all information necessary to display the
border of the logica] window. An action area pointer 98
points to a cluster 88 containing header text 36, and a
key legend point 100 points to a cluster 88 containing
bottom text 40. Additional pointers (not shown) can
point to other data clusters ~8 defininy other
non~scrollable text regions. If a particular window does
-- 2 ~ 2 ~
SA9-89-047 10
not have a particular feature such as an action area or
key legend, the corresponding pointers are simply set to
NULL.
Following the pointers 96, 98, 100 to data
contained in the non-scrollable partition, a first body
cluster pointer 102 points to a data cluster 88
containing data to be displayed in the scrollable region.
A type identifier 104 for the first body cluster
indicates whether that region is currently scrollable,
and can be used to indicate other information about the
associated data cluster 88. Additional body cluster
pointers, such as body cluster 2 pointer 106 are used in
conjunction with additional scrollable partitions beyond
the first scrollable partition. Each of these other body
clusters has an associated body cluster type identifier
108 also.
Referring to Figure 7, a preferred organization
for a data cluster 88 is shown. Each clata cluster 88 has
one or more fields, with each field typically
corresponding to one line of text to be displayed. The
information necessary to display each ~ield is arranged
into groups, so that there are formed a flags group 110,
a field identifiers group 111, an attributes group 112,
and a strings group 114. As shown in Figure 7, each
adjacent entry in an attribute group 110, 111, 112, 114
corresponds to one field, so that a first field 116
includes the first entry in each of the groups 110, 111,
112, 11~.
The flags-~ntry for each field cont~ins various
status flags for that field. The field identifier entry
for each field contains a symbolic name for that ~ield,
to simplify reference thereto by the application if
desired. The attributes entry for a field contains
information for the display manager 64 used to display
the text of each field, such as size, color, and
highlighting infor~ation. The strings entry for each
field is preferably a pointer to a string containing the
text for that field.
~ ~ 2 ~ 3
SA9-89-047 11
The window services 80 are able to easily
extract from a window control block the data needed to be
sent to the display manager 64. Using the described
system allows a relatively straightforward implementation
of the functions necessary for high level control of
logical windows. These functions include, but are not
limited to, functions for creating and destroying
windows, writing te~t to windows and reading input te~t
entered by a user, and sizing, moving, and scrolling
windows. Pseudocode for performing these important
functions is set forth in the attached Appendix.
Henceforth follows a brief description of the functioning
of the pseudocode for each of these high level window
functions.
The CreateWindow function creates a window from
the information passed to it in the Window Control Block
(WCB). The contents of the WCB are validity checked
(line 100). The outer partition and the contained page
are created (lines 101-102). The new window information
is recorded in a new MAPREC record at the end of the list
of windows (line 103). A MAPREC record simply maps
partitions to windows, and a linked list of all such
mappings is retained for reference as needed. The window
border characters are set according to the device type in
use and its capabilities (lines 104-108). The window
contents are then créated by looping through the WCB
contents by cluster (lines 109-112). This completes the
craation of the outer partition, and a nearly iden-tical
procedure is now used to create the inner partition,
which has no border (lines 113-119). A flag is set in
the WCB to show that the window has been created and is
currently in the open state.
The DestroyWindow function destroys a window,
freeing the associated storage and display manager
constructs. The validity o~ the WCB is checked (line
100). Then, looping through each cluster, window
contents are deleted, finally freeing the storage for the
cluster~ themselves (lines 101-106). The MAPREC storage
and display manager constructs are deleted (partitions
2 ~
SA9-89-047 12
and pages), (lines 107-108). Finally, the WCB storage i5
freed (line 109).
The WriteText function creates new fields
and/or places text in existing fields. The WCB is
checked for validity (line 100). The outer partition is
made current and its first cluster is pointed to (lines
101-102). Then looping through each of the clus~ers,
each cluster is examined to see if any fields need be
created or replaced (lines 103-114). One of the
optimizations used in this design is the placement of WCB
clusters in order, so that the ~riteText and related
functions can simply fall through the list of clusters,
and by doing so, easily handle the switch ~rom outer
partition clusters to inner partition clusters (line
105). This is done by looping through each of the fields
in each cluster (lines 106-113). A WriteText flag is
searched for (having been set by the calling program in
order to signal this change in field text), and if it's
set (line 107), then the display commands are issued to
change the field text and/or create new fields if
required (lines 108-109). If these operations succeed,
then the WriteText flags are reset in the WCB, else an
error code is returned (lines 110-112).
The ReadWindow function c~uses all of the
display changes to be displayed at the device and allows
the user to interact with the program. It then notifies
the window ownars of the changes and/or interactions.
Programmed function key information is sent ~irst to the
owner of the current window. Windows in which text was
changed are also sent messages that a change occurred in
their window. ~CB fields for which changes occurred are
marked with a Modified flag. A Special Input Field
designation exists as a convenience ~or windows which
onl~ react to an input string in a designated field.
ReadWindow first looks for the current
partition, and if one is not found it returns to the
caller ~lines 100-101). Otherwise, it issues a display
manager command to write any changes to the display and
~2~3
SA9-89-047 13
allow the user to interact (line 102). The cursor
position is then determined and, if it was not in a
defined partition, it is placed in the top partition
(lines 103-105). A temporary list of partitions
currently on the device screen is created, and matched
against the list of all WCBs (lines 106-111). The
current partition is placed at the front of the lisk of
WCBs (line 110~.
The WCBs are then each handled by the following
loop (lines 112-128). Closed or minimized windows are
ignored, since no changes will have to appear in them
(line 113). The body partition is made ~urrenk, and a
loop determines if any of the fields have been modified,
in which case the WCB flag for that field is marked as
modified (lines 11~-119). The same loop is then repeated
for the outer partition (lines 120-125). If the Special
Input Field of the WCB has been set, then the field text
is obtained for that modified field (line 126). The
results of the read operation are passed to the window
owner (line 127).
The SizeWindow function resizes the window on
the display and pops it to the top o~ the viewing order.
The WCB is checked for validit~ (line 100~. The inner
partition is si~ed first (line~ 101-108). This is
accomplished by ~irst checking to see i~ it has a body
partition and, if so, sizing it in relation to the outer
partition. If the new window is too small for the body
to appear at all, the partition is made invisible (lines
10~-105).
. .
The outer partition is then resized and
recreated (lines 108-115). The WCB is updated with the
re~uested position and dimensions (lines 108). A display
manager command i6 issued to resize the outer partition
(line 109). The partition page is recreated (line 110).
The outer partition's contents are recreated according to
the new dimensions (line 111-115). Finally the window is
made current by making all o~ its partitions current, if
~2~
SA9-89-047 14
it is not already on top of the viewing order (lines
116-118).
The MoveWindow function moves the window and
pops it to the top of the viewing order. The WCB is
checked for validity (line 100). The new position of the
inner partition is calculated based on the destination
and offset from the outer partition (lines 101-103). If
the window is not closed, then the display manager
command is issued to move the partitions (lines 104-107).
The window is placed at the top of the viewing order if
it is not already there (lines 109-110).
The ScrollWindow function scrolls the contents
of the window and pops it to the top of the viewing
order. The WCB is checked for validity (line 100). If
there is no body partition for this windo~, then the
function returns9 since only window bodies are scrolled
(lines 101-102). The inner partition is made current
(line 103). Calculations are performed to determine
which data will be displayed after the scrolling
operation ~line 104). The operation then continues by
performing the required display manager commands that
achieve the scrolling result (lines 105-117). The WCB is
updated with the new positional information9 and the
window is placed at the top of the viewing order (lines
118-121).
Other window control functions can be
implemented in a straightforward manner using the
functions described above or techni~ues similar to those
used in such functions.
As will be appreciated by those skilled in the
art, a window manager system has been described which
provides high level, ~ully functional support for messy
desk windowing on a non-programmable, character based
terminal. Such a system can be used with mainframe
computer based applications for which windowing has not
heretofore generally been available. The windowing
system as described can easily be provided as a package
SA9-89-047 15 ~ 3
whlch can be used by numerous application programs.
Using the techniques of the present invention, windows
may be manipulated efficiently on a terminal which is not
normally designed to support their use. Various types of
windows, such as pop-up and pulldown windows, can be
implemented using the described techniques.
While the invention has been particularly shown
and described with reference to a preferred embodiment,
it will be understood by those skilled in the art that
various changes in form and detail may be made therein
without departing from ths spirit and scope of the
invention.
