@sn not reset when expected

[GCC Consulting]

>  
> > 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?

Richard Kreiss
GCC Consulting