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.

bodgerAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

tliottaCommented:
bodger:

There are various parts at work. For example, a WRITE can output immediately if the display is created as CRTDSPF DFRWRT(*NO); but the attribute is DFRWRT(*YES) by default at most sites. If necessary, I think you can use CHGDSPF DFRWRT(*NO) against a DSPF that's already been compiled.

But keep in mind that keyboard-buffering can cause <Enter> and other AID-byte generating keystrokes to be placed into the keyboard buffer when you don't expect them. You might need to handle a few dozen buffered keystrokes just to get them cleared out if you have a user who will hit <Enter> a few dozen times just because it seemed that the machine wasn't paying attention (or if someone just bumps the keyboard the wrong way). Consider calling the Set Keyboard Buffering (QWSSETWS) API, a Workstation Support API, to help control this.

There are numerous alternatives, but I suspect this is about as far as you want to go today.

Tom

0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
daveslaterCommented:
Hi
code the FRCDTA keyword into the DDS
then simply use the Write and NOT EXFMT in the RPG

Dave
0
daveslaterCommented:
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
0
Cloud Class® Course: Amazon Web Services - Basic

Are you thinking about creating an Amazon Web Services account for your business? Not sure where to start? In this course you’ll get an overview of the history of AWS and take a tour of their user interface.

bodgerAuthor Commented:
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.
0
tliottaCommented:
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
0
bodgerAuthor Commented:
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.
0
tliottaCommented:
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
0
bodgerAuthor Commented:
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.
0
bodgerAuthor Commented:
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.
0
tliottaCommented:
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
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
IBM System i

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.