|
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-2024 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.