Re: Window border display attributes mess up overlaid display

Pressed send too soon. Sorry.

Also add the PROTECT & PUTOVR keywords. That has worked for me.

Consider adding a line SFLCSRRRN(&RRNA) so you can do away with the x Opt field and a user can use either the arrow keys or the mouse and not have to navigate, key X, and then press Enter. Getting the field value is a simple chain to the subfile with the RRNA number.


On 8/8/2017 5:46 PM, Dan wrote:

If you've been following on the RPG list, you may remember that I recently
began a foray into the service program world. So far, pretty good. This
particular issue has me baffled, and google has not been my friend. The
link http://imgur.com/a/paR17 has three screenshots that show what I'm
dealing with. (I used a "paintbrush" to obfuscate some information in the
window not needed for this discussion.)

Program CA8554R displays the screen shown in the first screenshot. When
the cursor is in the "sub-org ID" field and the user presses F4, the
program calls service program CA9801R, which opens its own display file and
displays a window, as shown in the second screenshot or the third
screenshot, depending on unknown circumstances. It appears to be random.
I thought I found a pattern to replicate when the window appears as it
should and when it doesn't, but apparently not.

I'm not really sure what I can share that is applicable. When I first
tested, the windows would completely clear the main screen. That was
resolved by defining the OVERLAY keyword in each of the window control
records and adding a dummy record to the service program's display file:
A R ZZZDUMMY KEEP ASSUME
A 2 1' '

According to
https://as400tips.wordpress.com/2015/10/14/external-pop-up-window-overlay-solution/,
where I got that information from, the program does not need to write the
"dummy" record, it just needs to be in the display file.

Any ideas on what I'm missing here?

- Dan