The W$FLUSH routine causes the screen and/or cursor to be refreshed. It can be used to ensure that the user sees the most current display (see the explanation under Description, below).
CALL "W$FLUSH"
USING PARAM-NUM
| PARAM-NUM numeric data item (optional) | Specifies what part of the display (screen or cursor) is refreshed. |
Calling this routine refreshes the display so that the user sees everything that is current, even if an ACCEPT has not been performed. Normally, the runtime ensures that the information the user sees is correct only when input is required from the user. This means that if you DISPLAY some text or control, and then perform extensive processing without also performing an ACCEPT, the text or control may not be immediately visible to the user. Possible values are:
| 0 | (default) the screen is made current, but the cursor may appear in an arbitrary location. (This is due to output optimization.) |
| 1 | the screen and cursor are made current |
| 2 | on UNIX machines using the BUFFERED-SCREEN configuration option, the screen is made current at the next clock tick
on all other machines this has the same behavior as setting the value to 1. |
| 3 | on UNIX machines using the BUFFERED-SCREEN configuration option, the screen and cursor are made current at the next clock tick on all other machines this has the same behavior as setting the value to 1. |
If you are experiencing a performance penalty for these runtime calls, especially during file processing where the screen is updated after each record, you can choose to inhibit calls to W$FLUSH. This can be useful if you want to simulate "mass update" functionality for ActiveX controls that do not have this capability built in. Use one of the following parameters:
| 256 | inhibits any future calls to W$FLUSH, including those made internally by the runtime system. Only a call with parameter 257 will be honored. This parameter must be turned off to restore user interaction. |
| 257 | cancels the inhibited state caused by parameter 256. This parameter does not cause a flush itself; it just allows future calls to W$FLUSH to function. You must call this parameter before interacting with the user. |
For example:
78 INHIBIT-FLUSH VALUE 256. 78 ALLOW-FLUSH VALUE 257. CALL "W$FLUSH" USING INHIBIT-FLUSH PERFORM LARGE-ACTIVEX-UPDATE CALL "W$FLUSH" USING ALLOW-FLUSH