HELP: Time-Out on screen with Subfile
Matt Sargent
>I have an RPG program running which uses time-out to refresh the
>screen at regular intervals (every five minutes).
>There is an example in the RPG manual on which this program is based,
>and all works well.
>I now need to enhance the program by using a subfile - the program
>will then refresh the subfile on timeout, showing an up-to-date list.
>Sounds too easy!
>As soon as I add a subfile, thought, there are problems...
I have an example of an RPG program that uses auto-refresh and
subfiles. I'll e-mail it to you.
_____________________________________________________________________
"But there must be something more to death than surfing all the time"
- Dar Williams
Matt Sargent
>Does anyone know how (if?) it can be done? or will I have to resort to
>writing a 'fake' subfile?
Well, I TRIED to send you the source code. Now if you'd drop this
phony AOL e-mail address, and provided a REAL e-mail address...
Geoff Callender
Stripe) wrote:
> I have an RPG program running which uses time-out to refresh the
> screen at regular intervals (every five minutes).
>
> There is an example in the RPG manual on which this program is based,
> and all works well.
>
> I now need to enhance the program by using a subfile - the program
> will then refresh the subfile on timeout, showing an up-to-date list.
>
> Sounds too easy!
>
> As soon as I add a subfile, thought, there are problems...
>
> I get an error when writing the Subfile Control record with SFLCLR on
>
> The INVITE on the screen DDS seems to cause the problem. I restricted
> the INVITE using the same indicator used for SFLCLR, which stopped the
> error, but still doesn't time out.
>
> Does anyone know how (if?) it can be done? or will I have to resort to
> writing a 'fake' subfile?
>
> Thanks
>
> Max
I suggest ditching INVITE and using the much groovier and more modern data
queue method instead...
CRTDSPF allows you to specify an attached data queue. In your program,
between your WRITE and READ, insert a call to QRCVDTAQ with the wait time
you require (in seconds). If the call returns no data (ie. length = 0)
you'll know that the data queue wait has timed out and it's time to
refresh the display file. Otherwise, someone must have pressed a key, so
you should READ the display file and act accordingly.
This technique has the added advantage that other processes on the system
can trigger the refresh. If this is what you want then you'll need to
test the data to see whether it is the result of a key-press or one of
these other processes. The former is easily recognised by its standard
character string, but I don't remember what it is.
Geoff.
Ricky L. Thompson
>I suggest ditching INVITE and using the much groovier and more modern data
>queue method instead...
>CRTDSPF allows you to specify an attached data queue. In your program,
>between your WRITE and READ, insert a call to QRCVDTAQ with the wait time
>you require (in seconds). If the call returns no data (ie. length = 0)
>you'll know that the data queue wait has timed out and it's time to
>refresh the display file. Otherwise, someone must have pressed a key, so
>you should READ the display file and act accordingly.
I have an interesting question for you... I am trying to write a
program similar to what you are talking about. I can make the program
update the screen using a data queue. But I am also trying to allow
the user to enter information on the same screen.
I have a window subfile with a window record display at the bottom of
the screen to allow input. When my data queue times out I check to
see if there are any new records to add to the subfile if there is I
add them. But if the user was in the middle of typing and I update
the screen the user loses the information on the input fields in the
window record because I have to do a write on the window record to
place the cursor back in the window record... To get around this
right now I'm making the user hit a function key to enter information
and then update the screen. If the user doesn't hit a function key
the screen update automatically. I hope I'm making my self clear..
Thanks
Ricky
tho...@hiwaay.net
Zebra Stripe
wrote:
>CRTDSPF allows you to specify an attached data queue. In your program,
>between your WRITE and READ, insert a call to QRCVDTAQ with the wait time
>you require (in seconds). If the call returns no data (ie. length = 0)
>you'll know that the data queue wait has timed out and it's time to
>refresh the display file. Otherwise, someone must have pressed a key, so
>you should READ the display file and act accordingly.
>
>This technique has the added advantage that other processes on the system
>can trigger the refresh. If this is what you want then you'll need to
>test the data to see whether it is the result of a key-press or one of
>these other processes. The former is easily recognised by its standard
>character string, but I don't remember what it is.
>
>Geoff.
Geof,
Tried as you suggest, but the call to QRCVDTAQ _always_ seems to
return a length of 0!
After several hours of despair (mainy becasue the CD ROM version of
the manuals for the /400 are so difficult to use) I have failed to get
the program to work -
Any chance of you being more specific - ie sample code?
Thanks