JP2564803B2 - Window controller - Google Patents

Description

Description: BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a window control device, and at the same time, when processing a plurality of jobs in parallel, a plurality of windows corresponding to the jobs are simultaneously overlapped on the screen of a display. The present invention relates to a window control device that can be displayed by displaying the status of each job.

[Conventional technology]

When launching multiple jobs by the processor and processing them in parallel, assign a window to each of these jobs so that the status of these multiple jobs can be displayed on the CRT display and the operator can check them.
There is known a so-called multi-window control device that simultaneously displays a plurality of these windows on a CRT display by superimposing them on each other. In such a multi-window control device, one of the jobs executed in parallel is
When an input request is issued, the input request display data is displayed in the window corresponding to the job that issued the input request, and the operator is prompted to input the predetermined input data. At this time, if the operator does not input the input data, the program of the job that has issued the input request is waiting for the input and cannot execute the subsequent processes.

[Problems to be Solved by the Invention]

By the way, in such a multi-window control device, the window corresponding to the job that issued the input request is CR.
When it is not displayed in the foreground on the T display,
That is, when the window is not the active window, the input request display displayed in this window may be overlaid and hidden on the window in front of this window, and the operator may not be able to know the input request. In order to avoid such a state, conventionally, the operator had to shift the position of the hidden window using a mouse or the like, and had to operate each time so that this window and the window in the front did not overlap. Since the operation is difficult and the operator cannot immediately know the input request, the job that issued the input request has to wait for the next processing until the input data is input, which reduces the processing efficiency of the processor. There was a problem of letting it.

An object of the present invention is to promptly inform an operator that an input request has been generated even when a window corresponding to a job that has issued an input request is not displayed in the foreground, and input predetermined input data. To improve the processing efficiency of the job.

[Means for Solving the Problem] A means of the first invention is a means for storing each display data to be displayed in a plurality of windows, a means for displaying a plurality of windows based on the display data, and a specific means. When an input request for a window occurs, this specific window is displayed in the foreground, and after displaying the specific window in the foreground, when predetermined data for the input request is input, the window And a control unit for returning the display state to the display state before the input request is generated.

According to a second aspect of the invention, means for storing respective display data to be displayed in a plurality of windows, means for displaying a plurality of windows based on the display data, and an input request for a specific window are generated. And an edit means for editing the display data so that the input request is displayed in the frontmost window.

[Operation] The operation of the means of the first invention is as follows.

When an input request for a specific window occurs,
Since the control means displays the specific window on the foreground, the operator can immediately know that there is an input request and can input predetermined data. Then, after displaying the specific window in the foreground, when the operator inputs the predetermined data for the input request, the control means returns the display state of the window to the display state before the input request is made. There is no need to switch windows.

 The operation of the means of the second invention is as follows.

When an input request for a specific window occurs,
The editing means edits the display data so that this input request is displayed in the frontmost window, so that the operator can immediately know that there is an input request and can input predetermined data. .

〔Example〕

 Embodiments of the present invention will be described below with reference to the drawings.

FIG. 1 is a system configuration diagram of a window control device of the present invention. In FIG. 1, the window control device 10
Is a so-called multi-window control device that operates under the control of the microprocessor 11 and can display a plurality of windows on the screen of the display 24 at the same time. Although not shown, the microprocessor 11 operates according to a program stored in a read only memory (ROM). The processor 11 processes a plurality of jobs in parallel and simultaneously displays the processing states of the plurality of jobs on the screen of the display 24. In order to display the processing states of the plurality of jobs on the screen of the display 24 at the same time, a window corresponding to each job is generated and these windows are generated. Are displayed on the screen in an overlapping manner, or the windows are changed or deleted when the job is changed or deleted. In addition, the microprocessor 11
Mouse 12 for inputting control information to the window, information of display data, etc. by operator's operation in addition to the program
And a keyboard 13 are connected via a mouse controller 14 and a keyboard controller 15.

The processor 11 further includes a window management table 16,
It controls peripheral devices such as the window memory 17 and the overlap control device 18.

The window management table 16 has a window size,
It is a table for managing attributes such as position and link relationship between windows. A management table is formed for each window, and this management table is created, changed or deleted by the processor 11. The window memory 17 is a memory for storing display data of windows, and as a buffer for inputting / outputting the window display data corresponding to each job when the number of submitted jobs is n, for example. The logical buffers LBF1, LBF2, ... LBFn of are formed by the processor 11. The window is a display area for displaying the display data in the logical buffer on the display 24.

Under the control of the processor 11, the overlap control device 18 extracts the display control information of each window from the window management table 16 and stores the control data to be displayed on the screen in the display control memory 19. Further, the window display device 20 takes out the control data stored in the display control memory 19 and transfers it to the bit mover 21 after the overlap control device 18 stores the control data in the display control memory 19. The bit mover 21 takes out the display data of the window from the window memory 17 and displays the display data and the control data from the window display device 20 in the display memory.
It is stored in 22. The display control device 23 controls the display on the display 24 and displays the display data for each window stored in the display memory 22 on the display 24 based on the control data. Under the control of the display control device 23, the display 24 is capable of displaying a plurality of windows in an overlapping state at the same time.

FIG. 2 shows the storage information of the management table generated in the window management table 16. In the management table, the width LBW of the logical buffer LBF for storing the display data of the window managed by this management table, the logical buffer LB
F height LBH, window width WIW, window height WI
Information such as H, the screen X-coordinate WIX of the window, the screen Y-coordinate WIY of the window, the pointer FP to the next window, and the pointer BP to the previous window is stored.

FIGS. 3A, 3B and 3C show the states of the window memory 17 and the window management table 16 when the processor 15 generates two windows WINA and WINB. A window memory as shown in FIG.
A logical buffer LBFA for the window WINA and a logical buffer LBFB for the window WIB are formed in 17 by the program of the processor 11, that is, by the storage means 2, and the windows WINA and WINB are displayed in the respective logical buffers LBFA and LBFB. The data is stored. A window WINA is displayed on the display 24 as shown in FIG. 3 (c).
Is displayed in the foreground and the window WINB is displayed in the last screen, the link structure of the window management table 16 is shown in FIG. 3 (b).
Must be as shown in. That is, since the base pointer BSP of the base table BTBL of the window management table 16 points to the start address of the frontmost window management table, the base pointer BSP in this case is the management table MTBA of the window WINA.
Points to the start address of. Also window WI
In the pointer BPA of the management table MTBA of the NA, the window WINA is at the forefront in this case, and since there is no window before this window WINA, the termination code NILL is stored. On the other hand, the pointer FPA of the management table MTBA
In this case, since the window WINB is displayed in the window next to the window WINA, it points to the start address of the management table MTBB of the window WINB. The pointer BPB of the management table MTBB is the management table MTB of the window WINA which is the window before the window WIB.
It points to the start address of A. Further, the pointer FPB of the management table MTBB stores the termination code NILL because there is no window next to the window WINB in this case.

In this way the window on the screen of the display 24
When WINA is displayed over the window WINB, the operator may not be able to know the display data contents of the window WINB. That is, when an input request is made from a job corresponding to the window WINB, the window WINA is in the foreground, so the window WIN
In some cases, the display of the input request displayed in B is hidden by the window WINA and cannot be seen by the operator. In order to enable the operator to know this input request when there is an input request for a job corresponding to the rear window, as the first embodiment, this rear window WINB is the frontmost window, The window WINA, which has been in the foreground until now, can be changed to the rearmost window in the display order. This is because the pointer BSP of the base table BTBL of the window management table 16 points to the start address of the management table MTBB of the window WINB, the end code NILL is stored in the pointer BPB of the management table MTBB of the window WINB, and the pointer of the management table MTBB. The FPB points to the start address of the management table MTBA of the window WINA, the termination code NILL is stored in the pointer FPA of the management table MTBA of the window WINA, and the pointer BPA of the management table MTBA points to the start address of the management table MTBB of the window WINA. The program of the processor 11 changes the pointer BSP of the base table BTBL of the window management table 16 and the pointers FPA, BPA, FPB and BPB of the management tables MTBA and MTBB of each window by the window management means 1. It In the first embodiment, when the operator recognizes a job input request and finishes inputting predetermined input data in response to this input request, the window WWIN
It must be returned to its original state, that is, as the next window of the window WINA to the rearmost surface. This is a pointer to the base table BTBL of the window management table 16.
This is done by returning the pointers FPA, BPA, FPB, BPB of the BSP and the management tables MTBA, MTBB of each window to the state shown in FIG. 3 (b).

The operation of the first embodiment will be described with reference to FIGS. 4 and 5. FIG. 4 (a) shows the display data stored in the logical buffer LBFA assigned to the job JOBA in the window WINA on the forefront of the display 24.
The display data stored in the logical buffer LBFB assigned to B is transferred to the window WIN on the rearmost surface of the display 24.
The state displayed in B is shown. Job in this state
When an input request for JOBB is made, predetermined data for displaying an input request is stored in the input area INARB of the logical buffer LBFB as shown in FIG. 4 (b). However, since the window WINB is now displayed on the rearmost surface, the input area INARB of the logical buffer LBFB is hidden behind the window WINA on the screen of the display 24, and the operator enters the input area INAB.
I cannot see RB and I cannot know that there was an input request for job JOBB. In order to solve this, as shown in FIG. 4 (b), the display order of the windows is changed at the time when the job JOBB makes an input request so that the window WINB is the frontmost and the window WINA is the last.

In FIG. 5, it is determined whether there is an input request for job JOBB (step ST1). If there is no input request, there is no need to change the display order of the windows, so no processing is performed. When there is an input request, step ST to change the display order of windows WINA and WINB.
Proceed to D2. In step ST2, window management table 1
In order for the base pointer BSP of the base table BTBL of 6 to point to the start address of the management table of the window which should be the foreground, the start address of the management table MTBB of the window WINB is stored in the base pointer BSP. Next, in step ST3, the pointer PBF of the management table MTBB of the window WINS to be the foreground is
The start address of the management table MTBA is stored in the pointer FPB so as to point to the start address of the management table MTBA of the window WINA which should be the window next to the window WINA. Furthermore, the pointer BPB of the management table MTBB
Stores the end code NILL in order to display the window WINB in the foreground. Then, in step ST4,
In order to display the window WINA that has been displayed on the forefront as the next window of the window WINB, that is, the window on the last side, the window WINA
Management table MTBA stores the termination code NILL in the pointer FPA and the pointer BPA in the window WINB management table
Stores the start address of MTBB. In steps ST2 to ST4, a link structure of the window management table 16 for displaying the window WINB on the forefront and the window WINA on the forefront is created.

Next, in step ST5, the input request display data is stored in the input area INARB of the logical buffer LBFBB assigned to the job JOBB. As a result, the contents of the window memory 17 are determined, and the window WINB is displayed on the display 24 in the foreground so that the operator can confirm the input request display data (step ST6). When the window WINB is displayed in the foreground on the display 24, the window WINB becomes the active window,
The operator can confirm the input request of job JOBB and perform a predetermined input operation, that is, input of input data. In step ST7, it is determined whether or not the operator's input operation is completed. When the input device is not finished, step ST7 is again executed to wait until the input operation is finished.
Return to When the input operation is finished, in order to return the screen to the original state, that is, the window WINA is brought to the front,
Step ST8 to display the window WINB on the back
Go to.

At step ST8, the base pointer BSP of the base table BTBL of the window management table 17 is set to the window WINB.
In order to point to the start address of the management table MTBA of the window WINA instead of the start address of the management table MTBB, the start address of the management table MTBA is stored in the base pointer BSP. Then step ST
In 9, in order to display the window WINA on the foreground, the start address of the management table MTBB is stored in the pointer FPA so that the MTBA pointer FPA of the management table of the window WINA points to the start address of the management table MTBB of the window WINB. , Further the pointer of the management table MTBA
Store the termination code NILL in BPA. Then step ST10
Then, in order to display the window WINB on the last side, the termination code NILL is stored in the pointer FPB of the management table MTBB of the window WINB, and the pointer BPB is set so that the pointer BPB points to the start address of the management table MTBA.
The start address of the management table MTBB is stored in. By steps ST8 to ST10, the window WINA is brought to the front,
A link structure of the window management table 16 for displaying the window WINB on the last side is created.

Next, based on the window management table 16 created in steps ST8 to ST10, the window WINA is displayed in the foreground on the display 24, and the window WINB is displayed next to the window WINA (step ST1).
1). As a result, the display order of the windows WINA and WINB returns to the state before the input request from the job JOBB as shown in FIG. 4 (c).

Thus, in the first embodiment, the windows WINA, WIN
By changing the display order of B, that is, by changing the link structure of the window management table 16, the operator can know the input request from JOBB and input predetermined input data in response to this input request. It becomes possible.

Next, a second embodiment will be described in which there is an input request in a job corresponding to the window on the rear side and the display of the input request is hidden by the window on the front side and invisible.

In the second embodiment, the operator can confirm that there is an input request for the job corresponding to the window on the rear surface without changing the display order of the windows as in the first embodiment, and the input operation can be performed. You can do that.
This is the job JOBB corresponding to the window WINB on the rear side.
It is possible to display the input request display data of the job JOBB in the front window WINA even when there is an input request in. For this reason, when there is an input request in JOBB, the logical buffer L of the window WINA on the forefront is
The input request display data is stored in the BFA, and the input request is displayed in the window WINA on the screen of the display 2, while the input data input in response to this input request is processed by the job JOBB.
Stored in the logical buffer LBFB assigned to.

The operation of the embodiment shown in FIG. 2 will be described with reference to FIGS. 6 and 7. FIG. 6 (a) shows display data DA, DB, ... Stored in the logical buffer LBFA assigned to job JOBA.
..Displaying DO in the frontmost window WINA of display 24, and logical buffer LBFB assigned to job JOBB
The display data stored in the window is displayed in the window WINB on the rearmost surface of the display 24.
When an input request for job JOBB is made in this state, the logical buffer corresponding to job JOBB is displayed as shown in FIG. 6 (b).
The input area INRA is allocated to the logical buffer LBFA corresponding to the job JOBA, that is, corresponding to the frontmost WINA, not the LBFB, and the display data of the input request of the job JOBB from the keyboard 13 is stored in the input area INARA. It is like this. At this time, the input area INARA of the logical buffer LBFA
The data DA, DB, DC, DD that have been stored up to now must be saved in the save area SVAR before storing the input request display data in order to restore the original state later.

The above operation will be described with reference to the flowchart of FIG. 7. First, in step ST20, it is determined whether or not there is an input request for job JOBB. When there is no input request, there is no need to display the input request, so no processing is performed. When there is an input request, input area INAR of logical buffer LBFA
Prior to storing the input request display data in A, the previously stored data DA, DB, DC, DD are saved, so these data are saved in the save area SVAR (step
ST21). Next, the input request display data is stored in the input area INARA of the logical buffer LBFA in order to display the input request display data in the window WINA on the display 24, that is, in the area DPY of FIG. 6 (b) (step ST22). As a result, the preparation for the input request display on the display 24 is completed, and the display of the input request display data in the area DPY of the window WINA on the display 24 is started (step ST2).
3).

After the input request is displayed in the area DPY of the window WINA on the display 24, the input data D1, D2, D3, D4 corresponding to the input request can be input from the keyboard 13, for example. When the input data D1, D2, D3, D4 are input, these data are assigned to the logical buffer LBFB assigned to the job JOBB which has received the input request as shown in FIG. 6 (c).
Stored in. And the input area INARA of the logical buffer LBFA
The original data D saved in the save area SVAR in
A, DB, DC, DD are stored again. As a result, the window WIN is displayed on the display 24 as shown in FIG. 6 (c).
A is displayed in its original state, and the input data is displayed in the window WINB.

The above operation will be described with reference to the flowchart of FIG.
After the input request is displayed in the area DPY of the window WINA of the display 24 in step ST23, it is determined whether or not all the input data D1, D2, D3, D4 have been input from the keyboard 13 (step ST24). If the input data has not been completed yet, the process returns to step ST24 again to wait until the input is completed, and when the input is completed, the display condition of the window WINA of the display 24 is returned to the original state and at the same time the input data is input to the window WINB. To display step ST25. In step ST25, the window WINB
Keyboard to display input data D1, D2, D3, D4 on 1
Logical buffer of input data D1, D2, D3, D4 input from 3
Store in LBFB. At this time, the input request display displayed in the window WINA is no longer necessary, so the original display data DA, DB, DC, DD is displayed in the area DPY of the window WINA.
The data DA, DB, DC, DD saved in the save area SVAR in order to display is stored in the input area INARA of the logical buffer LBFA (step ST26). By steps ST25 and ST26, the window WINA is ready to be displayed in the state before the input request from the job JOBB, and the window
Input data D1, D2, D3, D4 is ready to be displayed on WINB. In step ST27, the data stored in the logical buffers LBFA and LBFB are transferred to the window WIN of the display 24.
Displayed on A and WINB respectively, and the process ends.

Thus, in the second embodiment, the windows WINA, WINB
The operator can know the input request from the job JOBB by using the logical buffer LBFA of the window WINA displayed in the foreground without changing the display order of the window, that is, without changing the window management table 16. Then, it becomes possible to input predetermined input data in response to this input request.

In the above embodiment, only two jobs are started and only two windows are displayed on the screen of the display. However, when two or more jobs are also started and two or more windows are displayed on the display. The present invention can also be applied to.

[Effect of the Invention] According to the first invention, when an input request for a specific window occurs, this specific window is displayed in the foreground, so that the operator immediately knows that there is an input request. It is possible to input predetermined data and improve the processing efficiency of the job. Also, after displaying a specific window in the foreground, when the operator inputs the predetermined data for the input request, the display state of the window automatically returns to the display state before the input request occurs. The window switching operation is unnecessary, and the job processing efficiency can be further improved.

According to the second invention, when an input request for a specific window occurs, the display data is edited so that the input request is displayed in the frontmost window, so that the operator has made the input request. Can be immediately known, and predetermined data can be input to improve job processing efficiency.

[Brief description of drawings]

FIG. 1 is a system configuration diagram of an embodiment of a window control device of the present invention, FIG. 2 is an explanatory diagram of a window management table of the window control device, and FIGS. 3 (a), (b), and (c) are two. FIG. 4 (a), (b) and (c) are explanatory views showing the states of the window memory and the window management table when the windows are superimposed and displayed on the screen. FIG. 5 is a flow chart of the first embodiment of the present invention, and FIGS. 6 (a), (b) and (c) show the input request display. FIG. 7 is an explanatory view schematically explaining the second embodiment displayed in the front window, and FIG. 7 is a flow chart of the second embodiment of the present invention. 11 …… CPU, 16 …… Window management table, 17 …… Window memory, 18 …… Overlap control device, 24 …… Display.

Claims (3)

(57) [Claims] 1. A means for storing respective display data to be displayed in a plurality of windows, a means for displaying a plurality of windows based on the display data, and a specifying method when an input request for a specific window occurs. After displaying the specified window on the foreground and displaying the specific window on the foreground, when the predetermined data for the input request is input, the display state of the window is changed to the display state before the input request is generated. A window control device comprising: return control means. 2. Means for storing respective display data to be displayed in a plurality of windows, means for displaying a plurality of windows based on the display data, and inputting when an input request for a specific window occurs. A window control device comprising: editing means for editing the display data so that the request is displayed in the frontmost window. 3. The editing means comprises a buffer corresponding to each window, and when an input request for a specific window occurs, the input request display data is stored in the buffer corresponding to the frontmost window, When the predetermined data for the input request was input, this data was stored in the buffer corresponding to the window in which the input request was generated, and was stored in the buffer corresponding to the frontmost window before the input request was generated. The window control device according to claim 2, wherein the display data is stored again.