|
Booth Martin (boothm@earth.goddard.edu) wrote:
>Should this answer *always* be *YES? I know that *NO messes up windows
>real bad, but I have not dared do it everywhere everytime because it's
>purpose for existing must be real.
Booth,
No, I think it's a mistake to use RSTDSP(*YES) everywhere, although it
does guarantee that you won't lose data from the screen in certain
situations. IBM obviously think so or they wouldn't have made *NO the
default. Using RSTDSP(*YES) causes the system to save an image of the
screen whenever the display file is suspended, and restore it when the
display file is re-activated. This save/restore is a significant
overhead so you will want to avoid it if you can.
The display file is suspended when a record from another display file is
written to the same device, and restored when a record from the original
display file is written again. Generally you should use RSTPDSP(*YES)
when you call a program that uses displays from a different display
file and on returning you write a format containing one of the following
keywords.
ERRMSG
ERRMSGID
OVERLAY
PUTOVR
PUTRETAIN
CLRL
If your application always recreates the whole screen after calling a
function that displays another screen it's best to use RSTDSP(*NO), both
to improve performance and to avoid a flash that can occur when the
screen is restored.
>Additionally, is there a way to change the default from *NO to *YES?
The default for any command can be changed. Whenever you do this it's
good practice to make a copy of the command in a non-IBM library (use
CRTDUPOBJ). This library should be above QSYS in your system library
list and public access to it should be *USE. You can then use the
command CHGCMDDFT CMD(CRTDSPF) NEWDFT('rstdsp(*yes)') to change the
default for the copy.
Personally I usually just compile everything with RSTDSP(*NO) and then
use program testing to discover the places where I need RSTDSP(*YES). If
you test properly it'll soon become apparent. You can change the RSTDSP
value of a display file without recreating it, incidentally; use the
CHGDSPF command.
>
>In <970725235128_582609484@emout03.mail.aol.com>, on 07/25/97
> at 11:51 PM, DAsmussen@aol.com said:
>
># and the compile-time keyword RSTDSPLY (should be *YES) --
>#or maybe I reversed those...
Dave Kahn - TCO, Tengiz, Kazakstan
=========
e-mail: kahn@tengizchevroil.com (until August 5th)
dkahn@cix.compulink.co.uk (from August 6th)
Note new e-mail address in Kazakstan
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* This is the Midrange System Mailing List! To submit a new message, *
* send your mail to "MIDRANGE-L@midrange.com". To unsubscribe from *
* this list send email to MAJORDOMO@midrange.com and specify *
* 'unsubscribe MIDRANGE-L' in the body of your message. Questions *
* should be directed to the list owner / operator: david@midrange.com *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.