Overlaying Screen From Calling Program with Window

[Guest.Visitor]

I have used this forum recently to solve a problem with background screens disapearing when putting up a window by calling an RPG program from an RPG program, by using the Assume keyword on a dummy DDS record format. However, I still have one unresolved issue. Here's the situation: I have a base program that puts up a subfile for the user to select a record from (screen 1). When the user selects a record, I want to display another screen (screen 2) that will become the background screen for a pop-up window. The program then calls a second program to display the pop-up window. What is happening is, when the user selects a subfile record from screen 1 I issue a WRITE command to screen 2 in the base program then call the window program. When the window displays, the background screen is still screen 1 from the base program. Even though I issued a WRITE to screen 2, it does not show as the window background. In experimenting, I found that if I issued an EXFMT to screen 2 instead of a write and then called the window program, everything looked fine. I don't want to issue an EXFMT because the user then has to get involved to advance the screen. Seems like I need an option to issue an EXFMT that does not require the user to press a key to advance the screen (and thus the program). I haven't found that option if it exists. Any advice, suggestions, options? John

[David Abramowitz]

Make your background screen appear when calling program 2. Do not use the OVERLAY keyword when defining this screen. Then display your window (with the OVERLAY keyword). In order to display your original screen when returning to program 1, it may be necessary to condition any OVERLAY keywords in this DDS, so that the window displayed in program 2 completely disappears. Another method to accomplishing this, is to write the DUMMY format prior to exiting program 2. Dave

[Guest.Visitor]

I guess this is due to the DFRWRT parameter on the CRTDSPF command. It defaults to *YES. Its effect ist, that after a WRITE the screen will not become visible until you hit a statement that waits for user reaction (ie. READ). EXFMT - to my understanding (i'm into cobol) is both a write and a read, so you won't notice a difference there. Try to compile your 'screen2' dds-source with DFRWRT(*NO). hth, Martin

[B.Myrick]

John, I have encountered this before. Besides the normal DDS keywords, try compiling the DDS sourcemember with RSTDSP(*YES). I never really looked into why it works, but it does. Issue a WRITE to the format you want to display and then EXFMT the window. Be sure the rstdsp(*yes) is on the dds you do the write to. Hope this helps, Bret

[Guest.Visitor]

John, Look into using the FRCDTA keyword on the second screen in the subfile program, the screen you will only do the WRITE to.

[Guest.Visitor]

Thanks for all your great suggestions! Not only did I learn how to correct this problem but learned other things about some of the keywords you suggested to try also. Here is what worked. Compile program 1 (base program) with DFRWRT(*NO). That's it! Thanks to Martin for that one. I tried using RSTDSP and ASSUME and some others but none worked. Doesn't seem like you should have to worry about remembering to change a compile time keyword forever to get this done but that's where I'm at with it. John