@sn not reset when expected

[John Esak]

> > 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 hve 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
> ..

Well, I wasn't referring to that at all when I mentioned SOP... I was
referring to my statement about having to re-display the base screen after
doing a browse that changes variables on that screen. I can not duplicate
what you mention above. I think (know) I have seen some behavior that was
similar i.e., losing the screen parts and reatinging field values... etc.,
but I have always been able to remedy these times when the screen gets
corrupted by simply doing "display @sn".

John