Check out the very first line of my post, Mark:<br>"This is a question more out of curiousity than anything else; I've already<br>
coded around it, though it's an ugly kludge using a flag."<br><br>As for the screen/end thing in a subroutine, I know it terminates processing. I am basically using it as an interrupt, like throwing an exception.<br>
<br>But that has zero to do with the question. I wasn't asking for someone to solve the coding issue - that's trivial. I just wanted to know if this is by design or a bug.<br><br>Tyler<br><br>Message: 7<br>Date: Fri, 17 Feb 2006 13:22:08 -0700
<br>From: Tyler <<a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:tyler.style@gmail.com">tyler.style@gmail.com</a>><br>Subject: GOSUB and SCREEN<br>To: <a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:filepro-list@lists.celestial.com">
filepro-list@lists.celestial.com</a><br>Message-ID:<br> <<a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:1e78e1e80602171222h79d5bdf1r6893da8439146678@mail.gmail.com">1e78e1e80602171222h79d5bdf1r6893da8439146678@mail.gmail.com
</a>><br>Content-Type: text/plain; charset="iso-8859-1"<br><br>This is a question more out of curiousity than anything else; I've already<br>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
<br>used to mediate between various files and makes system calls to allow<br>editing of these related files. I was getting errors "Too many gosubs"<br>after users had used it for processing a lot of data, I couldn't imagine
<br>why, as I impose pretty strict structure on all new processing. Since it<br>was structured code, it was easy if somewhat tedious to record each gosub<br>call and return - basically building a stack tracer, since the debugger
<br>doesn't seem to have one (which would be REALLY handy for tracing spaghetti<br>logic GOTOs).<br><br>The non-returning culprit was a subroutine that had a SCREEN command before<br>the return. This sub was called from input processing wef/wlf routines.
<br>This caused a slow build up of non-returned gosubs in filePro's gosub<br>counter. Does the screen command not clear out the gosub counter/stack when<br>the gosubs are called in the wef/wlf processing and wef/wlf processing
<br>ends? I would think it should:<br><br>"When a SCREEN command is encountered during @WLF or @WEF processing, the<br>user is put into update mode on the designated screen. When the user presses<br><ESC> to record the input on this screen, processing ends. @WLF and @WEF
<br>processing are not considered Input processing. These routines run<br>independently from Input processing, and do not affect the position of the<br>Input processing's execution pointer. Each @WLF and @WEF routine has its own
<br>pointer, and processing ends for these special routines only when one of the<br>specific @WLF, @WEF "closing" commands is encountered. SCREEN is one of<br>these commands."<br><br>Tyler Style<br>-------------- next part --------------
<br>An HTML attachment was scrubbed...<br>URL: <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://lists.celestial.com/pipermail/filepro-list/attachments/20060217/3fc4b4ce/attachment-0001.html" target="_blank">
http://lists.celestial.com/pipermail/filepro-list/attachments/20060217/3fc4b4ce/attachment-0001.html</a><br><br>------------------------------<br><br>Message: 8<br>Date: Fri, 17 Feb 2006 15:32:11 -0500<br>From: Fairlight <
<a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:fairlite@fairlite.com">fairlite@fairlite.com</a>><br>Subject: Re: GOSUB and SCREEN<br>To: <a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:filepro-list@lists.celestial.com">
filepro-list@lists.celestial.com</a><br>Message-ID: <<a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:20060217153211.A25834@iglou.com">20060217153211.A25834@iglou.com</a>><br>Content-Type: text/plain; charset=us-ascii
<br><br>This public service announcement was brought to you by Tyler:<br>><br>> The non-returning culprit was a subroutine that had a SCREEN command before<br>> the return. This sub was called from input processing wef/wlf routines.
<br>> This caused a slow build up of non-returned gosubs in filePro's gosub<br>> counter. Does the screen command not clear out the gosub counter/stack when<br>> the gosubs are called in the wef/wlf processing and wef/wlf processing
<br>> ends? I would think it should:<br><br>The question is, if you're going to SCREEN, and you self-admittedly know<br>that SCREEN acts as a de facto END, why are you putting it in a GOSUBed<br>routine at all? The only reason I can think of is if the screen switching
<br>is conditional. If it's not conditional, it sounds like it's poorly<br>planned.<br><br>The easy (and sane) solution is that, if the logic deciding that you should<br>use SCREEN -must- be in a GOSUB routine, set a flag variable in that
<br>routine and check for it immediately after the RETURN. QED. One extra<br>line of code, and one changed one.<br><br>mark->