bodger
asked on
Display Without Keyboard Wait
Can anyone tell me how to display a DDS screen format (DSPF) without waiting for keyboard input? EXFMT always triggers a keyboard input wait state (DSPW) even without a single input field in the format and requires that the Enter key (or equiv.) be pressed before the next statement in the RPG program is executed. WRITE causes everything to behave as though the format had been displayed but it is not visible.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Hi Bodger
I am reading your past two questions as part of the same system design.
I am guessing that you are doing some type of automatic refresh system (like an airport departure screen).
On way to do such a system is via an DATAQ attached to your display file, this give you the flexibility to test on a normal screen and make live on a remote screen.
You can then update your screen with remote data added from the DATAQ.
This will save the need for DLYJOB and the FRCDTA method that you are going to use.
Let me know if you are interested
Dave
I am reading your past two questions as part of the same system design.
I am guessing that you are doing some type of automatic refresh system (like an airport departure screen).
On way to do such a system is via an DATAQ attached to your display file, this give you the flexibility to test on a normal screen and make live on a remote screen.
You can then update your screen with remote data added from the DATAQ.
This will save the need for DLYJOB and the FRCDTA method that you are going to use.
Let me know if you are interested
Dave
ASKER
Tom
DFRWRT(*NO) sorts it. Thankyou.
--------------------------
Dave
You are quite right about the nature of the project, although it's not actually an airport. I will look into DATAQs and thanks for the suggestion. I guess if I have any questions about the subject I can submit them separately.
DFRWRT(*NO) sorts it. Thankyou.
--------------------------
Dave
You are quite right about the nature of the project, although it's not actually an airport. I will look into DATAQs and thanks for the suggestion. I guess if I have any questions about the subject I can submit them separately.
bodger:
An auto-refresh... With or without input from the user?
If it is purely a refresh of a screen such as airport arrival/departure times, you might not use a dtaq. But if the screen indeed expects a user to enter data or any function keys while auto-refresh is also active, then a dtaq is an excellent addition to the project.
I've had projects where multiple displays were used. The user sat at one keyboard/monitor and additional info was displayed on secondary monitors. The secondary monitors were display-only, never accepting input but only displaying secondary info. (9-1-1 emergency dispatch systems where secondary screens would show info about hazardous materials in the area of a fire or where owner info might be displayed from county property databases or whatever)
No dtaq needed, no need to ever care about input from those devices -- just discard everything that could possibly show up.
But an auto-refresh with input -- the dtaq entry acts as an event that triggers the READ in the program. Very handy.
Tom
An auto-refresh... With or without input from the user?
If it is purely a refresh of a screen such as airport arrival/departure times, you might not use a dtaq. But if the screen indeed expects a user to enter data or any function keys while auto-refresh is also active, then a dtaq is an excellent addition to the project.
I've had projects where multiple displays were used. The user sat at one keyboard/monitor and additional info was displayed on secondary monitors. The secondary monitors were display-only, never accepting input but only displaying secondary info. (9-1-1 emergency dispatch systems where secondary screens would show info about hazardous materials in the area of a fire or where owner info might be displayed from county property databases or whatever)
No dtaq needed, no need to ever care about input from those devices -- just discard everything that could possibly show up.
But an auto-refresh with input -- the dtaq entry acts as an event that triggers the READ in the program. Very handy.
Tom
ASKER
Tom
At the display point there will be no keyboard. The display program is run from a jobq and ACQs a signed off terminal whose device id is passed as a pgm parm and then proceeds to cycle around a datafile, periodically rebuilding the subfile with the next datafile segment. This part now works just great.
It will be controlled remotely, at the very least to terminate it, using either a MSGQ or an inter-program comms file.
At the display point there will be no keyboard. The display program is run from a jobq and ACQs a signed off terminal whose device id is passed as a pgm parm and then proceeds to cycle around a datafile, periodically rebuilding the subfile with the next datafile segment. This part now works just great.
It will be controlled remotely, at the very least to terminate it, using either a MSGQ or an inter-program comms file.
You wouldn't happen also to be a COBOL programmer? COBOL has a slick option on its WRITE statement that allows controlling rolling the screen. Pretty cool, not like a subfile at all.
WRITE Scr-Rcd FORMAT 'F1'
AFTER ROLLING Top-of-roll-area
THRU Bottom-of-roll-area
DOWN 1
Assuming the 'F1' format is a single line, then the above statement would roll lines downward starting at the line number in Top-of-roll-area through the line number in Bottom-of-roll-area; after those rolled down one line, the new line would be written. Kind of like inserting a line on the screen. A line at the bottom of the defined roll area would be dropped. Rolled lines are output only.
If Top-of-roll-area is set at the line number that 'F1' is defined, then a handy blank line is created and you get a very rolling list going down the screen.
Haven't seen how to make RPG do the same, though maybe DSM could be used.
Tom
WRITE Scr-Rcd FORMAT 'F1'
AFTER ROLLING Top-of-roll-area
THRU Bottom-of-roll-area
DOWN 1
Assuming the 'F1' format is a single line, then the above statement would roll lines downward starting at the line number in Top-of-roll-area through the line number in Bottom-of-roll-area; after those rolled down one line, the new line would be written. Kind of like inserting a line on the screen. A line at the bottom of the defined roll area would be dropped. Rolled lines are output only.
If Top-of-roll-area is set at the line number that 'F1' is defined, then a handy blank line is created and you get a very rolling list going down the screen.
Haven't seen how to make RPG do the same, though maybe DSM could be used.
Tom
ASKER
It could be done quite easily, assigning F1 and F2 to scroll a line at a time. You just make the subfile size the same as the display size (i.e. number of datarows) and reload it each time F1 or F2 is pressed.
ASKER
Actually I'd include a 'scroll factor', which could be reduced to 1 or maxed at display/subfile size, in a popup window and stick to the Roll/Page keys.
Note that COBOL 'WRITE... AFTER ROLLING...' scrolls the data *on the screen* not in a subfile; no subfile necessary. COBOL also handles subfiles of course, but subfiles are a very specific beast. Also, COBOL ROLL needs no input from the user such as any F-key. It's totally program controlled, although the action could certainly be requested by F-key.
Also, ROLL can be up or down and it can dynamically roll any lines by any roll count as long as the roll count doesn't exceed the count of lines to be rolled. (Rolling three lines down by ten wouldn't make sense since the roll-area only includes three lines.)
Without reloading and redisplaying, I'm not sure a subfile _can_ be rolled except a page at a time or by using SFLROLVAL. But that still requires someone to press PgUp/PgDn. If there's no user control, AFAIK, reload/redisplay is all there is.
Tom
Also, ROLL can be up or down and it can dynamically roll any lines by any roll count as long as the roll count doesn't exceed the count of lines to be rolled. (Rolling three lines down by ten wouldn't make sense since the roll-area only includes three lines.)
Without reloading and redisplaying, I'm not sure a subfile _can_ be rolled except a page at a time or by using SFLROLVAL. But that still requires someone to press PgUp/PgDn. If there's no user control, AFAIK, reload/redisplay is all there is.
Tom
code the FRCDTA keyword into the DDS
then simply use the Write and NOT EXFMT in the RPG
Dave