Re: Window border display attributes mess up overlaid display

[Booth Martin <booth@xxxxxxxxxxxx>]

Just as a test to narrow the issue involved, what happens if you comment 
the current WDWBORDER row and replace it with ****

**WDWBORDER((*COLOR BLU)) ? Does behavior change? **

****



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