Wolfgang Lenerz via Ql-Users wrote:
Hi,

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.

Regards

Wolfgang
"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
   END DEF
   :...
   DEF FN SetDBS(..)
    :...
    er= FDB_SET(..)
    :...
    PRINT er
    REturn er
   END DEF
   :

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?

As expected it was stack problem with my MC_FnB.
Not being an expert I had looked at some examples and ended up using a mix.
It has now been sorted and I can go on with testing the rest of the program.

I agree with Francois, using LOOKUP% as alternative for EXISTS.
I use it a lot. It returns the place in the name table which can also be used to test for conflicting keywords if found out of place.

Bob



--
Deze e-mail is gecontroleerd op virussen door AVG.
http://www.avg.com

_______________________________________________
QL-Users Mailing List

Reply via email to