A while ago, I wrote down the steps needed to accomplish this on a green
screen:
Here it is:
5250 Auto Refresh
At times you may need to display information to a user and refresh the data
automatically. A user may want to see what is happening every so many
seconds so they can stay on top of things. In the examples below (Figure 5
and 6) screens are being refreshed that display what warehouse workers are
doing throughout the day (counts of scans) and what orders are being scanned
at which location (pick/pack/manifest)
To make this happen, several things need to be addressed in both the RPG
(program) and DDS (display file).
DDS (diplay file):
. You must have the keyword INVITE in the record format or the entire
file. (in the case of a subfile it must be conditioned because it cannot
be on when you clear the subfile)
. Create the display as you normally would through SDA (or any other
method)
. When you compile the display make sure you fill in the Maximum
record wait time (keyword WAITRCD) to the number of seconds to wait before
a redisplay (in the below case, it is set to 30).
RPG (program-may be RPGILE/SQLRPGLE )
. The workstation file must have the keyword MaxDev(*File) on the F
Spec of the display file (Figure 1). (This will make the display timeout as
if a function key was pressed after the specified time set in the DDS
compile.)
. You must code a *PSSR (program status subroutine) in the workstation
file (Figure 1). Use a return point, preferably the beginning of detail
calcs '*DETL' (Figure 3).
. You must NOT use EXFMT to write and read the display file format
that is being refreshed. Instead use a combination of write and read (a
subfile may have a write to subfile header and a write for the function keys
or footer).
. You must not read a specific format. Instead, read the name you
used for the workstation file (the name of the screen file) (Figure 2).
Make sure INVITE is on if it is conditioned with an indicator (Figure 4).
. In order to make something happen you must code for the
interruption. This is done easily in ILE using MONITOR and ON-ERROR (Figure
2).
. In the *PSSR subroutine, you may set a flag so that when it returns
to detail calcs, the program will know what to do (Figure 3) when a user
presses enter or a function at the same time the device times out. A read
of the workstn file accomplishes this.
. At the beginning of the detail calcs, code for the *PSSR exception
(Figure 4).
Figure 1
FInqWhEmp2 CF E WorkStn InfDS(Info) MaxDev(*File)
F SFile(SflRec1:RRN1)
F InfSr(*PSSR)
Figure 2
// write the first screen
Write InqWhemp21;
// read the first screen
Monitor;
Read InqWhemp2;
On-Error;
// if session times out, leave the loop, reload first screen
// (in case totals change)
Leave;
EndMon;
Figure 3
csr *PsSr BegSr
/free
// flag so beginning of detail calcs knows where to go
PssrFlag = *On;
// must read again if user pressed key while being auto
// refreshed
Monitor;
Read InqWhemp2;
// if error other than the auto refresh
On-Error;
PssrFlag = *Off;
Dump;
*InLr = *On;
Return;
EndMon;
/End-free
csr EndSr '*DETL'
Figure 4
// If not coming from pssr
If NOT PssrFlag;
// One time only
ExSr First_Time;
EndIf;
// do 4 ever
DoW 1 = 1;
// If not coming from pssr
If NOT PssrFlag;
// load the first screen
ExSr LoadScrn;
// set the sound
ExSr Set_Sound;
EndIf;
// make sure invite is on so it auto refreshes
Invite = *On;
// do 4ever
DoW 1 = 1;
// If not coming from pssr
If NOT PssrFlag;
// write the first screen
Write InqWhemp21;
// read the first screen
Monitor;
Read InqWhemp2;
On-Error;
// if session times out, leave oop, reload first screen
// (in case totals change)
Leave;
EndMon;
// If coming from pssr
Else;
CFKey = F7;
InvalidFKey = *Off;
PssrFlag = *Off;
EndIf;
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Luke Gerhardt
Sent: Thursday, August 05, 2010 1:39 PM
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: Refreshing a kiosk screen
You have to use the INVITE keyword, true. You also must change your EXFMT
to a write/read combination. If you have subfiles there is a bit of a
hurdle with INVITE, so you have to condition it to turn it off when you want
to read a subfile...confusing, I know. :)
Oh, and you must specify WAITRCD on the display file. It's how many seconds
you want your WRITE to wait before automatically proceeding.
Here's an example (yes, those are really the source comments):
// turn on dds invite keyword and write the control record
*in81 = *on;
write FTR;
write CTL;
// because we are using the dds invite keyword, we must use read with the
format // name of the display file, instead of using exfmt with the record
name
read(e) V000X;
...
// The dds invite keyword is cool, and lets us create a screen that
refreshes itself...
// but, it is mutually exclusive to subfile manipulations such as reading
and clearing.
// So we have to condition the invite keyword so that we are not inviting
when we try // to do subfile work... Turn the indicator off and write the
control record again in // order to cancel the invite.
*in81 = *off;
write CTL;
readc SFL;
On 8/5/2010 1:00 PM, rpg400-l-request@xxxxxxxxxxxx wrote:
date: Thu, 5 Aug 2010 11:49:20 -0500
from: "Bob P. Roche"<BRoche@xxxxxxxxxxxxxxxxx>
subject: Re: Refreshing a kiosk screen
It's been a few years since I've done this, but there is a way in a
green screen application to refresh the screen. It's perfect for Kiosk
usage. I had to abandon it because it removed the keyboard buffer and
stray enter key presses would get inserted in to my code by an
impatient user who presses the key several time "just to be sure"
whenever they would process a certain screen. I remember the INVITE
keyword being used, I can look it up again if you are using a green
screen.
If it's web based I'm sure someone more knowledgeable than me can
answer it form that angle.
--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or
change list options,
visit:
http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/rpg400-l.
midrange.com
