Nested Gosubs

[John Esak]

> You have to look at the input processing as containing different tables
> entirely.
>
> TYPES OF PROCESSING
> 1) INPUT FLOW PROCESSING.
> You have the normal input processing or any @key processing logic -
> This logic starts at line 1 or the @key label depending on what is
> appropriate.  The logic continues forward until an END or EXIT.  During
> the flow, the processing goes back and forth between the User having
> control with a data entry opportunity or the processing having control.
>
> 2) WHEN PROCESSING
> These are little baby programs that are TRIGGERED by an event such as
> When Entering or leaving a field.  When a key is hit in a data field,
> and other field related events.  These processes are in the same table
> as type 1 but they function independently and may or may not happen
> depending on the triggering event.  These are closed with END, SCREEN,
> RESTART, SKIP
>
> 3) @once, @done, @menu  - these offer processing that is not record
> related but happen as a prefix or post script to the session.  They are
> processed until an END or EXIT statement.
>
> 4) @entsel - processing that occurs before a record is displayed and is
> usually used to display browses, lookup data, or change the user prompts.
>
> Now only in TYPE 1 does the END command really signal the end to a
> records processing.
>
> EXIT used anywhere always means EXIT so that would throw your butt out
> in any context.
>
> Now since the WHEN processing and the INPUT processing share the same
> table, it sometimes happens that you try to share a subroutine.  Well
> and good, but that is where you must be careful that the subroutine does
> not contain any condition where it issues a command that the WHEN would
> react to as a end command but was really intended to be treated
> differently.
>
> @wlf1
> 	then: gosub calc
> 	if: 12 gt "1"
> 	then: msgbox "HERE I AM";end
>
> calc
> 	then: 12=1+2
> 	if:	12 gt "1"
> 	then: errorbox "YOU MADE A BOO BOO";screen,2;goto calc
> 	then:return
> Now in this little sample.  WLF1 it will run the calc routine.  If 12 gt
> "1", it will put the user in field 2.  The RETURN was not run.  So one
> RETURN is now hanging.
>
> It will also never display the msgbox "HERE I AM" because it will never
> return from the gosub.
>
> That is what you have to control.  You have to keep two streams of logic
> seperate and know if you are running a routine from input, WHEN's or
> both and structure it correctly.
>
> Nancy
>
 --
> Nancy Palmquist

Actually, I hope you are not advocating this kind of programming as shown
above.. other than to illustrate _very_bad_programming_.  This is
_precisely_ the kind of spaghetti code that we are all always fixing for
people who are just starting out... or who have made and error in their
coding and can't debug it becaus of things like this.  You should never
allow a SCREEN command to come up in @when processing if you don't *WANT* it
to specifically end that when-processing snippet.  There is no justification
for this, since there are umpteen-dozen other ways of writing this to work
exactly as the "intent" of this code is meant to work.  Especially, since
this code is so "mixed_up" (which I'm sure you meant it to be) as to imply
that the goto calc would always execute...which, obviously, you are pointing
out, it won't.  Coming from the when-processing you show, the "goto calc"
will not get executed... so it doesn't really show any kind of example... of
anything good at all.  If CALC were only called as a subroutine from INPUT
procesing, yes it would function, but the point is, don't do it from a
when-leaving situation.  So, therefore, in my opinion, it is a very badly
constructed subroutine... and shouldn't be used ever anyway.

John