Screen display problem on return

[Karen Barrett]

Thank you vey much Bob.
I tried moving the call to pre-update but lost the ability to have all the data commit together. I think your tip on setting the subscreen on line 25 may bear fruit!
One other thing - could you give me an example of how to use the restore=lines? quick procloc=xxx/xx restore=lines auto=xx.qkg??
 
Appreciate all you do for us...
 
Karen
 
> To: kbarrett00 at hotmail.com
> CC: powerh-l at lists.sowder.com; powerh-l-bounces+bob.deskin=ca.ibm.com at lists.sowder.com
> Subject: Re: Screen display problem on return
> From: Bob.Deskin at ca.ibm.com
> Date: Thu, 10 Feb 2011 10:02:56 -0500
> 
> 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.
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sowder.com/pipermail/powerh-l/attachments/20110211/b4df1ed1/attachment.htm