GOSUB and SCREEN and closer reading....

[Tyler]

Check out the very first line of my post, Mark:
"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."

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.

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.

Tyler

Message: 7
Date: Fri, 17 Feb 2006 13:22:08 -0700
From: Tyler <tyler.style at gmail.com>
Subject: GOSUB and SCREEN
To: filepro-list at lists.celestial.com
Message-ID:
       <1e78e1e80602171222h79d5bdf1r6893da8439146678 at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

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-0001.html

------------------------------

Message: 8
Date: Fri, 17 Feb 2006 15:32:11 -0500
From: Fairlight <fairlite at fairlite.com>
Subject: Re: GOSUB and SCREEN
To: filepro-list at lists.celestial.com
Message-ID: <20060217153211.A25834 at iglou.com>
Content-Type: text/plain; charset=us-ascii

This public service announcement was brought to you by Tyler:
>
> 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:

The question is, if you're going to SCREEN, and you self-admittedly know
that SCREEN acts as a de facto END, why are you putting it in a GOSUBed
routine at all?  The only reason I can think of is if the screen switching
is conditional.  If it's not conditional, it sounds like it's poorly
planned.

The easy (and sane) solution is that, if the logic deciding that you should
use SCREEN -must- be in a GOSUB routine, set a flag variable in that
routine and check for it immediately after the RETURN.  QED.  One extra
line of code, and one changed one.

mark->
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.celestial.com/pipermail/filepro-list/attachments/20060217/af861b1d/attachment.html