CALL question

TurnipTruck

Greetings,

Can a CALL pass back a string to its DEFINE_CALL? I am having trouble with this.

CHAR cSCROLL_MSG[32]

DEFINE_CALL 'SCROLL'(cSCROLL_MSG)
{
//sends a scrolling message
}

CALL 'SCROLL'('MESSAGE')

This return a variable conversion warning at compilation.

Thank you for any help.

[Deleted User]

TurnipTruck wrote:

Greetings,

Can a CALL pass back a string to its DEFINE_CALL? I am having trouble with this.

CHAR cSCROLL_MSG[32]

DEFINE_CALL 'SCROLL'(cSCROLL_MSG)
{
//sends a scrolling message
}

CALL 'SCROLL'('MESSAGE')

This return a variable conversion warning at compilation.

Thank you for any help.

I think you need to consider the call string parameter a local variable with a defined size.

DEFINE_CALL 'SCROLL'(cSCROLL_MSG[32])
{
//sends a scrolling message
}

CALL 'SCROLL'('MESSAGE')

DHawthorne

Yes, CALLs can be recursive (call themselves), and as Brian has stated, your problem is not that, but that your definition does not include the array brackets, so the call is actually looking for a single CHAR rather than a string. You don't need to put a number in there, you can use just [], and it will work just fine. NetLinx programs ignore that value in a parameter anyway, since they work on the actual value of the variable passed to them, not on a local copy. If you change the value of a parameter inside a CALLL or FUNCTION, the original variable gets changed too.

Back to recursion; you need to be very careful with this. Whenever a CALL (or FUNCTION) calls itself, a new instance of it is allocated in memory, and if too many get called at one time before the originals close, it will eat up your memory until the master crashes. Use recursion carefully, and make real sure each iteration runs quickly and exits so this can't happen. Also be careful of endless recursions where it keeps calling itself forver with no exit point.

Hedberg

You have two variables called cSCROLL_MSG. One is global and the other is local to your define_call. The global one is an array of characters and the local is a single byte character variable. Though they have the same name and look very similar to the eye, I believe that Netlinx keeps them separate and inside your define_call, only the local will be used. That is, I think it's impossible to reference a global variable from within a call or function if the call or function has a local variable with the same name as the global variable. I'm not exactly sure as I haven't tested this in a long time, but that's what I recall.

Anyway, what you are trying to do is assign an array of characters to a single character variable (I think) and that's not good.

To fix:

DEFINE_CALL 'SCROLL'(char cSCROLL_MSG[])
{

}

Hedberg

DHawthorne wrote:

NetLinx programs ignore that value in a parameter anyway, since they work on the actual value of the variable passed to them, not on a local copy.

Yes, this appears to be correct and I was wrong. Modification of the value of a variable passed to a function or "call" changes the value of the variable in the calling scope. "Call by reference" and not "call by value."

But, changing the value of a local variable within a subroutine does not change the value of a global variable with the same name. For example:

DEFINE_CALL 'SCROLL'(char cSCROLL_MSG_2[])
{
local_var char cSCROLL_MSG[32]
cScroll_Msg = 'Inside Scroll'
}

will not change the value of a global variable named cScroll_Msg. I think.

cwpartridge

Hedberg wrote:

But, changing the value of a local variable within a subroutine does not change the value of a global variable with the same name. For example:

DEFINE_CALL 'SCROLL'(char cSCROLL_MSG_2[])
{
local_var char cSCROLL_MSG[32]
cScroll_Msg = 'Inside Scroll'
}

will not change the value of a global variable named cScroll_Msg. I think.

It is as you stated. The compiler adds extra namespace scoping so even though we see they have the same name, the compiler sees them as unique names.

In NetLinx, a DEFINE_FUNCTION would be a better use. If this is in Axcess, then the DEFINE_CALL is all that is available.

Just a note on recursion. The NetLinx Interpreter tracks the depths of recursion and the memory available when doing recursion, so if the interpreter task memory gets low due to recursion being too deep, the recursion is exited.

Chuck