Can someone point me to some information that explains where and when to use the rc = ?

I have been muddling through my code, but just ran into something where it would not seemingly work in simulation mode, but does work on the real machine. Adding in the rc =  seemed to fix it. On the simulation it would complete the line of code, but then just hang there for no apparent reason.

If it has the "rc =" in the LUA Syntax part of the API help for that command, does that mean I should use it anywhere that I use that API code?

Hi,
ideally you would use rc (return code) on EVERY API call.

Lets take a typical Lua API:

hsig,rc=mc.mcSignalGetHandle(inst,mc.OSIG_OPUTPUT23)

This API requires two parameters (or inputs if you prefer the term) namely an instance number and a number identifying the output
signal for which you want a handle. Note that mc.OSIG_OUTPUT23 actually evaluates to a number.....the text string is called an 'enumeration'
and is done that way because humans remember names better than numbers.

This API has two returns, one is the handle we wanted but also a return code.

When the Lua function, in this case mcSignalGetHandle(), is returned it returns values in the form of a stack. The stack is read from the lefthand most
entry.

Thus:
hsig=mc.mcSignalGetHandle(inst, mc.OSIG_OUTPUT23) is perfectly OK. The variable hisg will hold the correct value after the call has been executed.
the variable rc will be on the stack but if you don't read it thats OK.

However:
hsig,rc=mc.mcSignalGetHandle(inst, mc.OSIG_OUTPUT23) is also perfectly OK. The variable hsig will have the required handle AND rc will have a return code.

Most of us don't bother with return codes and we consequently get a lot of code errors without understanding why. Expert programmers read return codes EVERY
API call and they have far fewer crashes.

I myself are somewhere in between, certain APIs which give trouble I test completely, others I don't bother.
Also if you write code for a newcomer to Lua then including all the extra code just to read return codes often confuses the newcomer which is definitely
not helpful..........but tends to start a bad habit, namely that of not reading return codes.

Craig

So are you just monitoring the number of the variable rc = in the stack window with each line to see if returns something other than 0 that correlates to the code list (all negatives I believe).

Hi,
yes that is correct.

A list of return codes and there numerical representation is found here:

https://www.machsupport.com/forum/index.php?topic=40051.0

Craig

Hi,
ideally you would use rc (return code) on EVERY API call.

Lets take a typical Lua API:

hsig,rc=mc.mcSignalGetHandle(inst,mc.OSIG_OPUTPUT23)

This API requires two parameters (or inputs if you prefer the term) namely an instance number and a number identifying the output
signal for which you want a handle. Note that mc.OSIG_OUTPUT23 actually evaluates to a number.....the text string is called an 'enumeration'
and is done that way because humans remember names better than numbers.

This API has two returns, one is the handle we wanted but also a return code.

When the Lua function, in this case mcSignalGetHandle(), is returned it returns values in the form of a stack. The stack is read from the lefthand most
entry.

Thus:
hsig=mc.mcSignalGetHandle(inst, mc.OSIG_OUTPUT23) is perfectly OK. The variable hisg will hold the correct value after the call has been executed.
the variable rc will be on the stack but if you don't read it thats OK.

However:
hsig,rc=mc.mcSignalGetHandle(inst, mc.OSIG_OUTPUT23) is also perfectly OK. The variable hsig will have the required handle AND rc will have a return code.

Most of us don't bother with return codes and we consequently get a lot of code errors without understanding why. Expert programmers read return codes EVERY
API call and they have far fewer crashes.

I myself are somewhere in between, certain APIs which give trouble I test completely, others I don't bother.
Also if you write code for a newcomer to Lua then including all the extra code just to read return codes often confuses the newcomer which is definitely
not helpful..........but tends to start a bad habit, namely that of not reading return codes.

Craig

Well said, spot on.

The default screens and profiles are all set up to take advantage of the included mcErrorCheck (I think that is the name) module.