RE: *DSPF question.

You've described my favorite strategy.  I know of one case where it's not   
useable, though.  A response indicator is used on the HELP keyword.  The   
panel program process the HELP key by calling another program that   
displays the help text.  The problem is, the HELP key acts like a CA key.   
 No user input data is passed to the panel program when the HELP key is   
pressed.  There's no way the panel program can "repaint" the panel after   
calling the help display program.  Whatever the user entered in input   
fields is gone.

I've not been able to figure a way to avoid RSTDSP(*YES) in this   
situation.  Am I missing something?
 --
Brian Johnson
Help/Systems, Inc.
brian@helpsystems.com


 ----------
From:  Kahn, David
Sent:  Wed, Jul 30, 1997 6:58 AM
To:  brian; MIDRANGE list (conference)
Subject:  Re: *DSPF question.

Dean Asmussen (DAsmussen@aol.com) wrote:

>> 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.
>
>Bravo Dave!  Good strategy...

...In your programs whenever you return from a lower level function that
writes formats from a different display file, set the indicator on.
PUTOVR will now be automatically in effect unless the screen needs
restoring.

This should allow you to use RSTDSP(*NO) with all your display files and
USRRSTDSP with all your windows. Does anyone see any snags with this
approach?...  

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* 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   *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *