Return without a gosub

[Richard Kreiss]

> -----Original Message-----
> From: filepro-list-bounces+rkreiss=verizon.net at lists.celestial.com
> [mailto:filepro-list-bounces+rkreiss=verizon.net at lists.celestial.com] On
> Behalf Of Robert T. Repko (R Squared Consultants)
> Sent: Wednesday, March 02, 2011 8:05 AM
> To: filepro-list at lists.celestial.com
> Subject: Re: Return without a gosub
> 
> Believe it or not at 3/1/2011 10:46 PM, Richard Kreiss said:
> >I have a routine that is activated by @keyA.
> >
> >It does some lookup before initiating the main portion of the routine
> >with a gosub.
> >
> >The program executes a popup update-
> ,"pop_memo",ad;clearP;clears;GOTO
> >f_stat
> >
> >Once the screen opens with dummy fields, @wefad, @wlfad, at wefae and
> >@wlfad occur.
> >
> >When the processing for the 2 fields ends, there is an input popup y,
> >to confirm if the information entered is correct.  The information is
> >then posted.
> >
> >The program hits a save and then executes the balance of the popup
> >update line.  This ends with the GOTO f_stat.  (22 line of code)
> >
> >1350: if:@keyA
> >   Then: Return
> >
> >Here is the point my client called this afternoon saying he got a
> >return with no gosub.
> >
> >Question: how many lines of code with some gotos before filePro loses
> >track of a label used on the if line.
> >
> >I have tested this routine a number of time before today and have never
> >gotten this error.
> >
> >This routine starts at line 346 and executes the GOSUB at line 360. The
> >subroutine starts at 1324 and ends at 1350.
> >
> >The reason for the return here is that this same routine for adding a
> >comment is also used from a browse lookup using @bk="A"
> >
> >
> >Richard Kreiss
> >GCC Consulting
> >rkreiss at gccconsulting.net
> >
> 
> It sounds as though you have a routine that is entered using goto and is
also
> entered using gosub:
> 
> 'The reason for the return here is that this same routine for adding a
> comment is also used from a browse lookup using @bk="A"'
> 
> If that's the case then you would have to set a flag so you either 'end'
or
> 'return' based on how you entered the routine.


You are correct except that I am using the @keyA on the if line as a flag
for the return.

My problem is that this routine has been test by me and in use to 20 or so
users at my client's site for the past few weeks without a problem.

Although this problem should not have occurred, I modified the program
slightly.  I declared a long variable KeyA(1,*) and when @keyA executed the
variable is set to "Y".
Then line 1350 checks for KeyA="Y" and if true, does the return.  

This should not have been necessary as labels have always been available for
use on the if line to make setting conditions easy.

Richard