in my experience, this is often caused by a Basic extension not
resetting the stack correctly. This generally seems to be the case
either when a keyword changes the value of an entry parameter, to make
it into a return parameter, or when a function returns a value (very
often a string).

But without having a complete program to test, this will be difficult to
find out.


> "RETurn not in procedure or function"
> What is causing this error in my Basic?
> The error has bugged me for weeks now.
> It even seems able to move around (see below).
> I have checked for the obvious and didn't find any mismatches.
> Also XREF, BasicLinker or QLIB did not report any.
> Below a summary of the program section from where the error occurs.
>   DEF FN GetScreen(..)
>    :...
>    IF hd =10
>     MC_ProcA parms..
>    ELSE
>     er%= MC_FnB(..)
>     :...
>    END IF
>    :...
>    IF NOT rn% : er%= SetDBS(..)
>    REM > rn% is set if the screen file is in the database
>    :...
>    RETurn 0
>   :...
>   DEF FN SetDBS(..)
>    :...
>    er= FDB_SET(..)
>    :...
>    PRINT er
>    REturn er
>   :
> The program is numberless and testrun from QD with the F10 Sbas/qd thing.
> The code for the MC_ProcA and MC_FnB keywords has also successfully been
> tested in other Basics.
> MC_FnB nicely returns zero in er% and not one of the possible negative
> values.
> SetDBS does some DBAS handling and doesn't return an error in er, as
> tested just before the RETurn line which produces the "RETurn not..."
> error. Checking the database confirms that SetDBS works properly.
> Strangely when I REM the SetDBS call, the same error is given in another
> FN when GetScreen has long been left by its own RETurn.
> Also the MC_ProcA route does not generate the error when doing the
> SetDBS call or in the other Sbas FN if skipping SetDBS.
> When I compile the Basic with QLIB v3.36 there are no errors reported
> and the compiled _obj executes without producing this error.
> Of course the Sbas version differs slightly from the _obj but this has
> mainly to do with reporting variable values. Also the Basic extensions
> as for the MC_xxx ones above are LRESPR'd in the Sbas run and $$asmb'd
> by Qlib.
> The numbered Basic as generated by BasicLinker and then run from job 0
> produces the same error as run from QD.
> So what could be messing up my RETurns?
> Bob
QL-Users Mailing List

Reply via email to