CA2021823C - Window display system and method - Google Patents
Window display system and methodInfo
- Publication number
- CA2021823C CA2021823C CA002021823A CA2021823A CA2021823C CA 2021823 C CA2021823 C CA 2021823C CA 002021823 A CA002021823 A CA 002021823A CA 2021823 A CA2021823 A CA 2021823A CA 2021823 C CA2021823 C CA 2021823C
- Authority
- CA
- Canada
- Prior art keywords
- scrollable
- partition
- window
- display
- data
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Classifications
-
- G—PHYSICS
- G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
- G09G—ARRANGEMENTS OR CIRCUITS FOR CONTROL OF INDICATING DEVICES USING STATIC MEANS TO PRESENT VARIABLE INFORMATION
- G09G5/00—Control arrangements or circuits for visual indicators common to cathode-ray tube indicators and other visual indicators
- G09G5/14—Display of multiple viewports
-
- G—PHYSICS
- G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
- G09G—ARRANGEMENTS OR CIRCUITS FOR CONTROL OF INDICATING DEVICES USING STATIC MEANS TO PRESENT VARIABLE INFORMATION
- G09G5/00—Control arrangements or circuits for visual indicators common to cathode-ray tube indicators and other visual indicators
- G09G5/34—Control arrangements or circuits for visual indicators common to cathode-ray tube indicators and other visual indicators for rolling or scrolling
- G09G5/346—Control arrangements or circuits for visual indicators common to cathode-ray tube indicators and other visual indicators for rolling or scrolling for systems having a bit-mapped display memory
Landscapes
- Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- Computer Hardware Design (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Digital Computer Display Output (AREA)
- Controls And Circuits For Display Device (AREA)
- Image Generation (AREA)
- User Interface Of Digital Computer (AREA)
Abstract
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 9 the windowing system manipulates these separate parts so that they are displayed on the screen as a single window.
Description
2 ~
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~
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 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 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 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.~
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 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 ~
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 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 ~
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 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~
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.
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~
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 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 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 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.~
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 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 ~
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 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 ~
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 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~
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.
Claims (13)
1. In a data processing system including a non-programmable display terminal capable of displaying a plurality of independent scrollable partitions and a plurality of independent non-scrollable partitions and a processing unit, a method for displaying overlapping logical windows on the non-programmable display terminal, comprising the steps executed by the data processing system of:
responsive to creation of a logical window by an application program, allocating one of a plurality of window control blocks to the logical window, wherein the window control block includes pointers to a plurality of preexisting data clusters;
filling a plurality of partition identifiers in the window control block, including at least a first partition identifier corresponding to a non-scrollable partition to provide a boundary for the logical window and a second identifier corresponding to a scrollable partition for the logical window;
for each non-scrollable and scrollable partition, setting a pointer in the window control block to a data cluster for the partition defining its attributes for overlapping the scrollable partition on the non-scrollable partition;
generating the non-scrollable partition corresponding to the first partition identifier for the logical window on he non-programmable display terminal; and generating the scrollable partition corresponding to the second partition identifier for the logical window on the non-programmable display terminal, overlapping the non-scrollable partition to present the logical window on the non-programmable display terminal to a user.
responsive to creation of a logical window by an application program, allocating one of a plurality of window control blocks to the logical window, wherein the window control block includes pointers to a plurality of preexisting data clusters;
filling a plurality of partition identifiers in the window control block, including at least a first partition identifier corresponding to a non-scrollable partition to provide a boundary for the logical window and a second identifier corresponding to a scrollable partition for the logical window;
for each non-scrollable and scrollable partition, setting a pointer in the window control block to a data cluster for the partition defining its attributes for overlapping the scrollable partition on the non-scrollable partition;
generating the non-scrollable partition corresponding to the first partition identifier for the logical window on he non-programmable display terminal; and generating the scrollable partition corresponding to the second partition identifier for the logical window on the non-programmable display terminal, overlapping the non-scrollable partition to present the logical window on the non-programmable display terminal to a user.
2. The method of claim 1, further comprising:
generating an additional partition corresponding to an additional scrollable partition identifier for the logical window on the non-programmable display terminal wherein the additional partition overlaps the non-scrollable partition to present the logical window on the non-programmable display terminal to the user.
generating an additional partition corresponding to an additional scrollable partition identifier for the logical window on the non-programmable display terminal wherein the additional partition overlaps the non-scrollable partition to present the logical window on the non-programmable display terminal to the user.
3. The method of claim 1, wherein the non-scrollable partition includes a window border, and wherein the scrollable partition is displayed at a location positioned wholly within boundaries of the non-scrollable partition, whereby the window border surrounds the scrollable partition.
4. The method of claim 3, wherein the non-scrollable partition further includes top-non-scrollable text and bottom non-scrollable text, and wherein the scrollable partition is displayed at a location between the top text and the bottom text.
5. The method of claim 1, wherein said non-scrollable partition comprises a plurality of subregions, wherein text for displaying each subregion is stored in a separate data element.
6. A display system for use in a data processing system, comprising:
a non-programmable display terminal supporting partitions of a display screen as active and as non-active for scrolling;
a plurality of data structures for supporting display of a logical window;
means responsive to an application program executing on the data processing system creating a logical window for allocating an unallocated one of the data structures to the logical window;
means responsive to allocation of a data structure corresponding to a logical window for display on the non-programmable display terminal, for assigning to said data structure data identifying scrollable and non-scrollable partitions, and including pointers into data clusters specifying attributes and contents of the scrollable and non-scrollable partitions;
means for writing a first non-scrollable partition to a location on the display screen and for writing at least a first scrollable partition to the display screen where it overlaps the first non-scrollable partition; and a window manager having procedures callable by an application program, wherein the procedures communicate with said means for writing to display data on the non-programmable terminal nd wherein the scrollable and non-scrollable partitions are filed upon allocation of a data structure o a logical window.
a non-programmable display terminal supporting partitions of a display screen as active and as non-active for scrolling;
a plurality of data structures for supporting display of a logical window;
means responsive to an application program executing on the data processing system creating a logical window for allocating an unallocated one of the data structures to the logical window;
means responsive to allocation of a data structure corresponding to a logical window for display on the non-programmable display terminal, for assigning to said data structure data identifying scrollable and non-scrollable partitions, and including pointers into data clusters specifying attributes and contents of the scrollable and non-scrollable partitions;
means for writing a first non-scrollable partition to a location on the display screen and for writing at least a first scrollable partition to the display screen where it overlaps the first non-scrollable partition; and a window manager having procedures callable by an application program, wherein the procedures communicate with said means for writing to display data on the non-programmable terminal nd wherein the scrollable and non-scrollable partitions are filed upon allocation of a data structure o a logical window.
7. he system of claim 6, wherein any scrollable partition of data is displayed in a defined region which is wholly contained within a defined region used to display the first non-scrollable partition.
8. The system of claim 6, wherein the first non-scrollable partition includes a border to be displayed around the periphery of the defined region used to display non-scrollable partitions.
9. The system of claim 8, wherein the non-scrollable partition further includes text to be displayed adjacent to top and bottom borders of its defined region, and further wherein the defined region used to display scrollable partitions is wholly contained within an area between the text displayed adjacent to the top and bottom borders.
10. The system of claim 6, further comprising:
an additional scrollable partition contained within said data structure, wherein said additional scrollable partition is displayed in a defined region different form that used to display the first scrollable partition.
an additional scrollable partition contained within said data structure, wherein said additional scrollable partition is displayed in a defined region different form that used to display the first scrollable partition.
11. The system of claim 10, wherein the defined regions used to display the scrollable partition and the additional scrollable partition are both wholly contained within a defined region used to display the non-scrollable partition.
12. The system of claim 11, wherein the defined region used to display the scrollable partition and the additional scrollable partition are positioned adjacent to each other with no overlap.
13. The system of claim 6, wherein the non-scrollable partition is subdivided into sub-portions, each sub-portion being stored separately within said data structure.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US39359989A | 1989-08-14 | 1989-08-14 | |
| US07/393,599 | 1989-08-14 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CA2021823A1 CA2021823A1 (en) | 1991-02-15 |
| CA2021823C true CA2021823C (en) | 1999-01-26 |
Family
ID=23555418
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002021823A Expired - Fee Related CA2021823C (en) | 1989-08-14 | 1990-07-24 | Window display system and method |
Country Status (4)
| Country | Link |
|---|---|
| EP (1) | EP0413484B1 (en) |
| JP (1) | JPH0377997A (en) |
| CA (1) | CA2021823C (en) |
| DE (1) | DE69018731T2 (en) |
Families Citing this family (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| AU631749B2 (en) * | 1990-09-14 | 1992-12-03 | Digital Equipment Corporation | System and method for communication between windowing environments |
| US5345552A (en) * | 1992-11-12 | 1994-09-06 | Marquette Electronics, Inc. | Control for computer windowing display |
| US5615326A (en) * | 1993-12-30 | 1997-03-25 | Taligent, Inc. | Object-oriented viewing framework having view grouping |
| US5524199A (en) * | 1993-12-30 | 1996-06-04 | Taligent | Object-oriented view system with background processing of update request |
| US5544301A (en) * | 1993-12-30 | 1996-08-06 | Taligent, Inc. | Object-oriented view layout system |
| WO1995018437A1 (en) * | 1993-12-30 | 1995-07-06 | Taligent, Inc. | Object-oriented view coordinate space system |
| US5566287A (en) * | 1994-06-28 | 1996-10-15 | Thomson Consumer Electronics, Inc. | Method for asynchronously maintaining an image on a display device |
| US6078306A (en) * | 1997-10-21 | 2000-06-20 | Phoenix Technologies Ltd. | Basic input-output system (BIOS) read-only memory (ROM) with capability for vertical scrolling of bitmapped graphic text by columns |
| EP1785923A1 (en) * | 2005-11-04 | 2007-05-16 | Research In Motion Limited | Method and system for updating message threads |
| US20070106729A1 (en) | 2005-11-04 | 2007-05-10 | Research In Motion Limited | Method and system for updating message threads |
Family Cites Families (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPS61109137A (en) * | 1984-10-31 | 1986-05-27 | インタ−ナショナル ビジネス マシ−ンズ コ−ポレ−ション | Determination of assistant information display position |
| CA1233257A (en) * | 1984-12-26 | 1988-02-23 | Irene H. Hernandez | Tailored document building |
| JPS6215591A (en) * | 1985-07-15 | 1987-01-23 | 株式会社日立製作所 | Multiscreen display control system |
| JPH07117825B2 (en) * | 1985-09-02 | 1995-12-18 | 株式会社日立製作所 | Multi-window display terminal control method |
| JPS62222288A (en) * | 1986-03-25 | 1987-09-30 | 株式会社リコー | Display unit with multiwindow display function |
| JPS62223786A (en) * | 1986-03-26 | 1987-10-01 | 株式会社リコー | Display unit with multiwindow display function |
| JP2583850B2 (en) * | 1986-04-02 | 1997-02-19 | カシオ計算機株式会社 | Window display control device |
| JP2586452B2 (en) * | 1986-05-13 | 1997-02-26 | カシオ計算機株式会社 | Multi-window display device |
| JPS63287993A (en) * | 1987-05-21 | 1988-11-25 | 株式会社リコー | Display device with multi-window display function |
| JPS63304315A (en) * | 1987-06-05 | 1988-12-12 | Ricoh Co Ltd | Multi-window processor |
| JP2578736B2 (en) * | 1987-09-22 | 1997-02-05 | 株式会社リコー | Multi-window display device for data processing system having a plurality of terminals |
-
1990
- 1990-07-24 CA CA002021823A patent/CA2021823C/en not_active Expired - Fee Related
- 1990-08-03 DE DE69018731T patent/DE69018731T2/en not_active Expired - Fee Related
- 1990-08-03 JP JP2205272A patent/JPH0377997A/en active Pending
- 1990-08-03 EP EP90308594A patent/EP0413484B1/en not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| CA2021823A1 (en) | 1991-02-15 |
| EP0413484B1 (en) | 1995-04-19 |
| EP0413484A3 (en) | 1991-10-23 |
| DE69018731T2 (en) | 1995-11-16 |
| EP0413484A2 (en) | 1991-02-20 |
| DE69018731D1 (en) | 1995-05-24 |
| JPH0377997A (en) | 1991-04-03 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US5175813A (en) | Window display system and method for creating multiple scrollable and non-scrollable display regions on a non-programmable computer terminal | |
| US6377285B1 (en) | Zooming space-grid for graphical user interface | |
| US5905496A (en) | Workflow product navigation system | |
| EP0121015B1 (en) | Presentation space management and viewporting on a multifunction virtual terminal | |
| US5341466A (en) | Fractal computer user centerface with zooming capability | |
| JPS62298882A (en) | Multiwindow display system | |
| US5062060A (en) | Computer human interface comprising user-adjustable window for displaying or printing information | |
| US5363483A (en) | Updating objects displayed in a computer system | |
| US6512529B1 (en) | User interface and method for maximizing the information presented on a screen | |
| US5502839A (en) | Object-oriented software architecture supporting input/output device independence | |
| US5335323A (en) | Computer human interface with multiapplication display | |
| US5577187A (en) | Method and system for tiling windows based on previous position and size | |
| US5046001A (en) | Method for accessing selected windows in a multi-tasking system | |
| US6252597B1 (en) | Scalable user interface for graphically representing hierarchical data | |
| US5642490A (en) | Providing icon placement alternatives for dynamically added container records | |
| US5155806A (en) | Method and apparatus for displaying context sensitive help information on a display | |
| US5604861A (en) | Method and apparatus for improved notebook control in a data procesing system | |
| JPH05210722A (en) | Graphics-display-tool | |
| US6404443B1 (en) | Three-dimensional graphical user interface for managing screen objects | |
| US6335737B1 (en) | Video display and selection on a graphical interface | |
| US8756528B2 (en) | System and method of customizing video display layouts having dynamic icons | |
| EP0428261A2 (en) | Computer user interface | |
| JPS6088996A (en) | Multiple data window display system | |
| JPH0721754B2 (en) | Graphical user interface | |
| EP0121551A1 (en) | Dynamic generation and overlaying of graphic windows for multiple active program storage areas. |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| MKLA | Lapsed |