Nested Gosubs

[GCC Consulting]

> -----Original Message-----
> From: filepro-list-bounces at lists.celestial.com 
> [mailto:filepro-list-bounces at lists.celestial.com] On Behalf 
> Of Nancy Palmquist
> Sent: Monday, November 01, 2004 4:39 PM
> To: Fplist (E-mail)
> Subject: Re: Nested Gosubs
> 
> I have enjoyed this thread and all the references to me.  I 
> guess I should have hung around yesterday (SUNDAY) instead of 
> wasting my time watching the Steelers tromp on New England Or 
> go trick or treating.
> 
> But it looks like Mark understands the posting I did early in the day.
> 
> I would like to clarify some processing logic.
> 
> 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,

You left out one very important command ESCAPE/SAVE.  This is what will end the
processing on a record and force the save.

Type1 processing will run after the record is saved either by command or by
pressing the proper key for saving the record - <esc esc> for *nix or <esc> or
<F10> for native.

Richard Kreiss
GCC Consulting