@sn not reset when expected

[Joe Chasan]

On Tue, Jun 08, 2004 at 11:37:36AM -0400, GCC Consulting wrote:
> >  
> > > As to @sn. As you know if you do a browse that collects data to be 
> > > displayed on the screen below the browse lookup, you have to 
> > bring down 
> > > the browse, re-DISPLAY the bottom screen and then re-execute the 
> > > browse. I wasn't clear when you were doing the @wbl, so I 
> > can't comment more until you elaborate.
> > > I'll test what you are saying, but it sounds like SOP not a bug.
> > 
> > the fact is that clearp does remove the popup window and i'd 
> > expect clerk processing to recognize this and change @sn 
> > immediately.  because it does not, if you do a clearp in this 
> > scenario, all subsequent popup's fail until said "end" 
> > statement because of whatever internal tracking clerk is 
> > doing for @sn/popup status, so you get left with a corrupted 
> > screen, with bleed-through of the fields that used to be on 
> > the popup, but no screen borders/field names/etc as would be 
> > on the normal screen.  
> > i'd hate to think that a  situation that allows such a mess 
> > would be SOP .
> > 
> Have your tried video sync after redisplaying the screen?

yes, thanks, i tried video sync as well as every permutation of
switchto and display i could think of.  i'd guess it relates to
being within @wbl processing, but only ken would know for sure.
 
--- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ---
-Joe Chasan-                      Magnatech Business Systems, Inc.
joe at magnatechonline.com           Hicksville, NY - USA
http://www.MagnatechOnline.com    Tel.(516) 931-4444/Fax.(516) 931-1264