JPS6258017B2 - - Google Patents

Description

DETAILED DESCRIPTION OF THE INVENTION Technical Field of the Invention The present invention relates to a hard copy method for a display screen in a data processing system, and in particular, when a hard copy of the display screen is being output to a printer, it is possible to simultaneously perform input/output operations to the display screen. Concerning an asynchronous hardcopy method that enables

Background of the Technology Conventionally, when a display terminal device or the like uses a local print key or a COPY command to instruct a printer to output a hard copy of the displayed screen, the display screen is not printed until the printer's copy operation is completed. Input/output was prohibited, and data entry operations to the screen had to be suspended during that time. Furthermore, it was not allowed to create a hard copy of a partial screen before one display screen was completed, and then add input data to the hard copy.

OBJECTS AND CONFIGURATION OF THE INVENTION An object of the present invention is to be able to continue data input operations at will even when a hard copy of a display screen is being output, and to input data added after a hard copy has been made for one display screen. The object of the present invention is to provide a means for making it possible to output additional information to a hard copy.

The present invention stores hard-copied data on a screen buffer corresponding to one display screen,
An attribute means is provided to distinguish additional input data that has not yet been hard-copied, and when a hard-copy instruction is received, this attribute means is referenced to extract only the additional input data and the hard-copy output processing queue is executed. It was designed to connect to. As a result, data input from the terminal that is performed after once instructing hard copy and before instructing hard copy again,
Alternatively, the data area (hereinafter referred to as field) that updates the screen, such as the screen output of processing results, is constantly identified and managed, and the screen input/output operation is completely independent from the hard copy processing operation, that is, it is asynchronous. This makes it possible to handle the data in a specific manner.

The present invention provides a data processing system that includes a display terminal device, a printer for making a hard copy of the display screen of the display terminal device, and a screen buffer for storing screen data. A means for displaying processed and unprocessed fields of the hard copy output is provided for the data, and when a hard copy output request is made, the display means is identified, only the hard copy output unprocessed field is retrieved, and this is displayed. In addition to connecting to the hard copy output processing queue, the above display means is changed to display the hard copy output processed field, and when a screen data update request is received, the above display means is set to display the hard copy output unprocessed field. This feature is characterized in that by storing the data in the screen buffer, the screen buffer update process and the hard copy output process can be executed independently.

Embodiments of the Invention The present invention will be described below with reference to Examples.

FIG. 1 is a basic configuration diagram of an embodiment of the present invention.
In the figure, 1 and 2 are functional units in the host, where 1 is an application program processing unit, 2 is an input/output processing unit, 3 is an input/output editing unit, 4 is a screen data update processing unit, 4a is a screen buffer, Reference numeral 5 indicates a hard copy output processing unit, 6 indicates a queue for a hard copy request field, 7 indicates a display terminal device, and 8 indicates a hard copy printer.

The application section program processing section 1 executes interactive processing with the terminal user of the display terminal device 7 . The input/output processing unit 3 performs data transfer, input/output editing, and other controls between the application program processing unit 1 and the display terminal device 7 and printer 8.

The screen data update processing unit 4 creates screen image data on an internal control screen buffer 4a, and when a hard copy output request is received, it updates the fields on the screen buffer 4a for which the hard copy output processing has not been completed. data, reads that field, and connects it to the end of queue 6 of the hardcopy request field. The hard copy output processing section 5 sequentially removes the queues 6 from the beginning, converts them into a print output format, and causes the printer 8 to print them out.

FIG. 2 shows a concrete example of the operational functions from the screen data update processing section 4 to the hard copy output processing section 5.

It is assumed that the terminal user makes a hard copy request each time he finishes inputting the data for field A on the screen, and also when he finishes inputting the data for fields B and C on the screen.
At this time, at the time of each copy request, fields A,
B and C are read out to the queue 6 to create the illustrated A-B-C queue, that is, a queue. This process proceeds regardless of the output state of the printer 8. Note that the data of each field connected to the queue is copied to the queuing buffer area 6a of the memory.

The hard copy output processing unit 5 removes A of the cue 6, performs hard copy output processing, and then outputs the cue B.
The process proceeds by simply checking the status of the queue 6, regardless of the time when the terminal user requests a hard copy, such as removing the queue and performing hard copy output processing. The illustrated example shows the state at the time when the output processing of field A is completed.

Next, the internal representation of attributes will be explained.

Required for hard copy processing using the method described above,
Information that is problematic when creating screen image data is
It concerns the display field and protection field of the screen. To represent these fields, set the following internal representation.

(1) Visible/protected attributes (2) Visible/unprotected attributes (3) Hidden/protected attributes (4) Hidden/unprotected attributes (5) Cursor However, the internal representation of the cursor depends on the screen image data creation. This is necessary only during printing, and is unnecessary during editing during print processing.

The screen buffer needs to be updated when there is an instruction to output data on the screen from the application program processing section 1 and an instruction to input data on the screen from the terminal.

First, the screen buffer update processing in the screen data update processing section 4 regarding the output data from the application program processing section 1 will be explained.

FIG. 3a shows an output message from the application program processing section 1. Further, FIG. 5B shows a screen showing the output screen position, and FIG. 1C shows the corresponding screen buffer. During the message, WCC indicates the start of data, SBA is the set buffer address, and the following 2-byte address indicates the data start address on the internal memory (buffer). SF is the start field, ATR is the attribute, the text continues below, and the last
The 2-byte address after SBA represents the start address of the next blank area, that is, the internal memory address corresponding to the cursor position. Note that the internal memory address SBA represents a position on the screen as a serial number, and is not represented as a row or column coordinate.

The update processing unit 4 receives the information from the above two SBAs.
Calculate the matrix position on the screen and insert the ATR internal representation code there. It also converts the text position into a screen image and stores it at the specified position on the screen buffer.

Next, a screen buffer update process regarding input data from a user terminal will be described.

The user data input position is assumed to be input from the cursor position (cursor address) on the screen buffer. This is because the system can only recognize the input position of user data using the field address, and cannot accurately know from which position the user inputs the data.

The following will explain using specific examples shown in FIGS. 4 and 5. In the figure, a and b show the screen display before and after input, respectively, and c and d show the contents of the corresponding screen buffer before and after the update process.
Further, e represents an input message transferred by operating the enter key. Note that AID indicates an attention ID. When inputting from the cursor position shown in figure a, this position can be changed by the update processing unit by inserting the cursor internal representation code as shown in figure c when editing the output of field [0010]. Since it is recognizable, it is possible to create a screen image as shown in figure d in response to data input as shown in figure b.

FIG. 5 shows yet another example. In this example, a
As shown in the figure, the cursor position is at the beginning of a new line, and the screen buffer maintains this position using the cursor internal representation code. Here, when an input is made as shown in b, screen image data d is stored on the screen buffer via message e.

In this case, even if the user moves the cursor and inputs after □R, for example, the message will be the same as e, so the update screen will be the same as d.

Regarding the kanji data, a kanji position display table corresponding to the screen buffer is provided in parallel with the screen buffer, and the table position corresponding to the kanji data position on the screen is displayed.

In this way, screen update data is formed as a screen image on the screen buffer, but these data are also accompanied by internal representation codes for each of the write, read, and cursor attributes. Therefore, in response to an occasional hard copy request from a terminal user, it is sufficient to detect the field after the internal representation code of the read attribute, read it out, and connect it to the queue 6. At this time, the internal representation code of the read attribute is inserted at the end of the field, as shown in FIGS. 4c and 5c.

Effects of the Invention As described above, according to the present invention, data can be input and output freely on the display screen in parallel even during hard copy processing, and even during screen creation. Only completed data can be output to hard copy at any time without interrupting operations, reducing overall processing time.
Efficiency can be improved.

[Brief explanation of the drawing]

FIG. 1 is a basic configuration diagram of an embodiment of the present invention. FIG. 2 is a functional explanatory diagram of the embodiment shown in FIG. 1.
3 to 5 are explanatory diagrams of the display screen and screen buffer updating operation in this embodiment. In the figure, 1 is an application program processing section, 2 is an input/output processing section, 3 is an input/output editing section, 4 is a screen data update processing section, 4a is a screen buffer, 5 is a hard copy output processing section, and 6 is a hard copy output In the request field, 7 indicates a display terminal, and 8 indicates a hard copy printer.

Claims (1)

[Claims] 1. In a data processing system equipped with a display terminal device, a printer for making a hard copy of the display screen of the display terminal device, and a screen buffer for storing screen data,
For data in the screen buffer, means is provided to display processed and unprocessed fields of hard copy output, and when a hard copy output request is made, the display means is identified and only the unprocessed fields of hard copy output are retrieved. , connect this to the hardcopy output processing queue, and
By changing the above display means to display the hard copy output processed field and when a screen data update request is received, the above display means is set to display the hard copy output unprocessed field and the field is stored in the screen buffer. An asynchronous hard copy method for display screens that enables buffer update processing and hard copy output processing to be executed independently.