Screen display problem on return

[Bob Deskin]

I missed the very start of this, but I did see your last message. I have a 
few things to add:

First off, be very careful calling subscreens from the UPDATE procedure. 
You want to make sure that your transaction and associated commit spans 
the two levels properly. If it can be done as a separate transaction, then 
call the subscreen in the PREUPDATE. However, that is unrelated to the 
screen refresh issue.

It is probable that the problem is because QUICK does not want to display 
screens during the UPDATE procedure because unwanted things can happen. 
Maybe not for relational, but for non-relational files.

Here are some options:

Try the RESTORE=LINES program parameter along with CLEAR ALL on the RUN 
SCREEN. The RESTORE=LINES was introduced when we allowed subscreens to 
overlay other screens in less than a 24x80 area.

And if that doesn't work, you may be able to force things by using 
application lines. QUICK has 240 application lines, basically its internal 
screen memory. Most people don't bother with it any more because it 
started out when using HP terminals which had more than 24 lines of 
memory.

By default, a screen starts ON LINE 1 FOR 23 LINES MESSAGE ON LINE 24. So 
on the subscreen, try ON LINE 25. It will automatically take 23 lines with 
the message line 1 after.

Now when you clear and refresh, QUICK doesn't have to reload the screen 
image. It has both in memory and hopefully will simply redisplay the upper 
level screen.

At least that's the theory.

Bob



From:   Karen Barrett <kbarrett00 at hotmail.com>
To:     PowerhouseList Post <powerh-l at lists.sowder.com>
Date:   2011-02-09 07:40 PM
Subject:        Screen display problem on return
Sent by:        powerh-l-bounces+bob.deskin=ca.ibm.com at lists.sowder.com



 
Hi All,

I tried these tips from Daniel but moving the call of the 2nd screen from 
update to preupdate made no change and I had too much going on to treat it 
as a slave.
Strangely, the choice of U, US, UR, and UN does! If U, all is hunky-dory. 
Last time I checked, there was no way within the screen to 
identify/control which update action the user chooses. Still, it is just a 
display issue and if they forget to U, the funky look will remind them :-)

Thanks and have a happy,

Karen Barrett

;----------------------------------

The second screen is called in the update procedure? If so, you should try 
to call it in the preupdate.
 
If this doesn't solve the problem, I would try to convert screen 2 into a 
slave screen, receiving the primary file of screen 1 as master.
 
Daniel Rodríguez-- 
= = = = = = = = = = = = = = = = = = = = = = = = = = = =
Mailing list: powerh-l at lists.sowder.com
Subscribe: 'subscribe' in message body to 
powerh-l-request at lists.sowder.com
Unsubscribe: 'unsubscribe &lt;password&gt;' in message body to 
powerh-l-request at lists.sowder.com
http://lists.sowder.com/mailman/listinfo/powerh-l
This list is closed, thus to post to the list you must be a subscriber.
Add 'site:lists.sowder.com powerh-l' to your search terms to search the 
list archive at Google.