Nested Gosubs

[Fairlight]

With neither thought nor caution, John Esak blurted:
> 
> It absolutely does... The SCREEN is _not_ a de-facto 'end' of any kind for
> regular INPUT processing (the processing pointer which starts at the top of
> the table... will simply -stop- at a SCREEN and wait there while the user is
> busy throwing junk on the screen. When the user presses the SAVE key, the
> processing pointer takes up from that point and moves on until it hits
> another function which may give control to the user... or it hits and END or
> and EXIT or whatever.
> 
> The difference is that for any @wlf or @wef, a SCREEN command (and a END,
> SKIP, or RESTART) actually _do_ stop the processing pointer right there
> forever. They stop the @when_field processing pointer, NOT the main INPUT
> table pointer.
> 
> So, GOSUB's and RETURNS do act as they should (and they do just un-nest one
> GOSUB back) until the original GOSUB is hit.

Doh!  INPUT processing.  Well, that explains the contextual paradigm change.
I've been dealing so much with CGI stuff and so little with the actual UI
that I didn't even consider it in those terms.  I see your point (and Brian,
nevermind...I asked before I read this post...I get it now).

> Thanks for the nice words about my writings about filePro... it is great to
> hear that they are clear sometimes...   When I'm talking to Ken, I often
> feel like I know nothing about the program, though. :-)

*chuckle*  I know the feeling.  I'm reminded of Stargate SG-1 when O'Neill
tells the ambassador in the "2001" episode, "You really have to be careful
when you ask 'How?' around Carter."  Or something -very- similar.

mark->
-- 
Bring the web-enabling power of OneGate to -your- filePro applications today!

Try the live filePro-based, OneGate-enabled demo at the following URL:
               http://www2.onnik.com/~fairlite/flfssindex.html