Re: Window erasing background screen issue with service program

I don't know if this is your issue - but if your display file window can
handle *DS3 and *DS4 and your session is set up for DS4 ( 27 * 132 ) then
it won't be able to show a background that is DS3.

If you want to force it into DS3 because the caller has a visible display
file which is DS3, then you can use the Format Level DSPMOD keyword e.g

A R DETAIL
A 26 DSPMOD(*DS4)
A WINDOW(CRTWDW)
A RTNCSRLOC(&RECNAM &FLDNAM &FLDPOS)
A 70 CSRLOC(LINE POSN)
A OVERLAY
A RECNAM 10A H
A FLDNAM 10A H
A FLDPOS 4S 0H
A LINE 3S 0H
A POSN 3S 0H

In my case I have a window which shows a month using PSHBTNCHC and it is
small enough to fit on DS3 without conditioning any field positions.

I pass a "WideScreen" boolean to the program to tell it whether to set on
Indicator 26 and condition it to use DS4.

That way even though the client access session is set to DS4, I can force
it back to DS3 if it is overlaying a DS3 Display file.

I still find the windows somewhat problematical. I think the main thing
that I occasionally fall foul of is having an out of date background appear
behind my window...

Not sure if this is your issue, but it's a handy thing to know.

best regards,
Craig



On 19 July 2018 at 22:23, Paul Therrien <paultherrien@xxxxxxxxxxxxxxxxxx>
wrote:

My window display file is *DS3 and *DS4.

And the window program displays the QCMD screen in the background when i
call it directly from the command line.

For testing the service program I have an RPG program that only and
simply invokes a procedure in the service program and the service
program then invokes the window program. In this scenario the QCMD
screen is erased when the window is displayed.

Both the Service program and the window RPG program are in activation
group QILE.

I am stumped.

Paul

On 2018-07-19 16:45, Carel wrote:

Well, QCMD is a *DS3 (24*80) screen.

And tour window is also *DS3?

If not, the background turns black and does not show the first screen

the window was displayed on, as a background.

Kind regards,

Carel Teijgeler

Op 19-7-2018 om 21:28 schreef Paul Therrien: I am currently in

development mode so I am calling the test program

directly from a command line.

In one instance I am calling the window program directly from the
command line.

in the other instance I am calling an rpg program from the command line
that executes a procedure in a service program that invokes the window
program.

So in both cases the underlying screen is QCMD.

Paul

On 2018-07-19 15:18, Carel wrote:

Does the previous screen has a different format then the new screen?

*DS3 v. *DS4.

Kind regards,

Carel Teijgeler

Op 19-7-2018 om 15:33 schreef Paul Therrien:

I have a window display program that, when called directly, the window
pops and the screen behind remains on the display. - All good.

When I call this same program from within a service program the window
pops, but the screen behind is erased; so all i see is the window, with
a blank screen behind.

The window operates fine in both circumstances, it is the erasing of the
screen behind the window that is an issue.

Is there a way to retain the screen data behind from within a service
program?

Am I, again, misunderstanding something?

Thanks for any help.

Paul

--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD