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.<br><br>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).
<br><br>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:
<br><br>"<font style="font-size: 10pt;">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."</font><br><br>Tyler Style<br><br>