GOSUB and SCREEN

[Tyler]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.celestial.com/pipermail/filepro-list/attachments/20060217/3fc4b4ce/attachment.html