GOSUB and SCREEN

[Tyler]

Thanks Rich, that's a good suggestion.  Unfortunately, I am switching to the
same screen, just to a different field, and switchto doesn't look like it
has a field parameter.  I don't know any way other than a screen command to
reposition the cursor in a particular field.

I'm curious - how do you know it resets the counter?  The documentation in
the manual is quite sparse on switchto.  And why does switchto but not
screen result in the counter reset if you call it from a wef/wlf?  I still
think that the reset is implied in "@WLF and @WEF processing are not
considered Input processing. These routines run independently from Input
processing".

Tyler



On 2/17/06, GCC Consulting <gccconsulting at comcast.net> wrote:
>
>
>
>  ------------------------------
> *From:* filepro-list-bounces+gccconsulting=comcast.net at lists.celestial.com[mailto:
> filepro-list-bounces+gccconsulting=comcast.net at lists.celestial.com] *On
> Behalf Of *Tyler
> *Sent:* Friday, February 17, 2006 3:22 PM
> *To:* filepro-list at lists.celestial.com
> *Subject:* GOSUB and SCREEN
>
>  This is a question more out of curiousity than anything else; I've
> already coded around it, though it's an ugly kludge using a flag.
>
> I have a driver program built into a dummy file's input processing that is
> used to mediate between various files and makes system calls to allow
> editing of these related files.  I was getting errors "Too many gosubs"
> after users had used it for processing a lot of data,  I couldn't imagine
> why, as I impose pretty strict structure on all new processing.  Since it
> was structured code, it was easy if somewhat tedious to record each gosub
> call and return - basically building a stack tracer, since the debugger
> doesn't seem to have one (which would be REALLY handy for tracing spaghetti
> logic GOTOs).
>
> The non-returning culprit was a subroutine that had a SCREEN command
> before the return.  This sub was called from input processing wef/wlf
> routines.  This caused a slow build up of non-returned gosubs in filePro's
> gosub counter.  Does the screen command not clear out the gosub
> counter/stack when the gosubs are called in the wef/wlf processing and
> wef/wlf processing ends?  I would think it should:
>
>
>
> "When a SCREEN command is encountered during @WLF or @WEF processing, the
> user is put into update mode on the designated screen. When the user presses
> <ESC> to record the input on this screen, processing ends. @WLF and @WEF
> processing are not considered Input processing. These routines run
> independently from Input processing, and do not affect the position of the
> Input processing's execution pointer. Each @WLF and @WEF routine has its own
> pointer, and processing ends for these special routines only when one of the
> specific @WLF, @WEF "closing" commands is encountered. SCREEN is one of
> these commands."
>
> Tyler Style
>
> Use switchto "screen_name"  instead of screen.  Screen ends processing and
> will leave the counter as is.
>
> See description below.
>
>
> Richard Kreiss
> GCC Consulting
>
>
>  SWITCHTO
>
>
>
> Syntax:
>
>
>
>        Then: SWITCHTO name
>
>
>
> "name" is the name of screen to switch to.
>
>
>
> Version Ref: 4.5
>
>
>
> Description:
>
> Switch to a different screen, without returning to the original screen
> upon ending processing (which is the default operation of the SCREEN command
> which also switches screens). Normally, when INPUT processing ends you are
> returned to the SCREEN you were on when processing started. The SWITCHTO
> displays a specific screen, and sets it to be the screen to be returned to,
> instead of the original screen.
>
>
>
> Examples:
>
>
>
> @keyP    If:
>        Then: switchto "pay";end
>
>
>
> Allow only certain users access to screen 9.
>
>
>
> @key9    If: "*root*kenb*ronk*lauraw*" co ("*" & @id & "*")
>        Then: switchto "9" ; end
>          If:
>        Then: errorbox "You are not authorized for screen 9." ; end
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.celestial.com/pipermail/filepro-list/attachments/20060217/b12d92cb/attachment.html