SWITCH...CASE vs SELECT...ACTIVE

richardherman

Today I got caught by a problem that, after some debugging, came down to this:

A 'SWITCH...CASE' does not work after a WAIT, while a 'SELECT...ACTIVE' does.

DEFINE_FUNCTION fnEndCeremony()
{
    WAIT 20
    {
    SELECT
    {
        ACTIVE (nEditorPlayerMode == PLAYERMODE):
        {
        SEND_STRING dvCMP, 'blabla_active_playermode'
        }
        ACTIVE (nEditorPlayerMode == EDITORMODE):
        {
        SEND_STRING dvCMP, 'blabla_active_editormode'
        }
    }
    SWITCH (nEditorPlayerMode)
    {
        CASE PLAYERMODE:
        {
        SEND_STRING dvCMP, 'blabla_switch_editormode'
        }
        CASE EDITORMODE:
        {
        SEND_STRING dvCMP, 'blabla_switch_playermode'
        }
    }
    }
}

If you execute the above function, the 'SELECT...ACTIVE' works fine, while the 'SWITCH...CASE' throws errrors:

Line 4 2017-07-18 (23:13:44.244):: Assign Stack Ref Error - Out of range
Line 5 2017-07-18 (23:13:44.245):: SetVariable - Error 2 Tk=0x1005
Line 6 2017-07-18 (23:13:44.247):: DoNumberExpression - Error 2 Tk=0x2008 Line=46
Line 7 2017-07-18 (23:13:44.247):: GetNumber - Error 1 Tk=0x0000
Line 8 2017-07-18 (23:13:44.250):: DoNumberExpression - Error 2 Tk=0x2008 Line=50
Line 9 2017-07-18 (23:13:44.250):: GetNumber - Error 1 Tk=0x0000

If you remove the WAIT, both options work fine. Of course this code snippet is not how it appears in the real program.

Is this expected behaviour? If so, which is 'correct'? I can't imagine that today would be the first time I used a SWITCH...CASE after a WAIT . Could it be that this has changed in a recent firmware?

I ran into this on a NX processor with the latest firmware and tested the code snippet on a NI-3100 with v4.1.419 firmware

zack.boyd

Is nEditorPlayerMode a instance variable or defined in DEFINE_VARIABLE?

richardherman

zack.boyd wrote: »

Is nEditorPlayerMode a instance variable or defined in DEFINE_VARIABLE?

It's a global variable, defined in DEFINE_VARIABLE.
'PLAYERMODE' and 'EDITORMODE' are constants, defined in DEFINE_CONSTANT. 'EDITORMODE' = 1 and 'PLAYERMODE' = 2

a_riot42

Post all the code. There are bugs with switch statements that have nothing to do with WAITs that you are likely running into.

I wouldn't write code like that though. I would put the wait where the function is called, or preferably, not use one at all.
Paul

richardherman

a_riot42 wrote: »

Post all the code.

There is no more code needed than posted above: run that function and the SWITCH...CASE fails.

Like I wrote: the code isn't like the example snippet. It is a simplification that still shows the problem. it is just to make it easier to reproduce it.

ericmedley

As a general rule I do not put any code in a function inside a wait that calls upon any variables. I might do something discrete. I like a_riot42's suggestion of doing the wait somewhere else. We use functionin Netlinx in a somewhat different way than most other languages. In other languages functions tend not to get as big as ours. In fact large functions are considered less desirable. While I don't necessarily agree with this notion, I do think it is a good idea to keep timing stuff out of functions. They're just not really built for it. We can get away with it occasionally.

MLaletas

I noticed at some version of netlinx that I couldnt use constants for cases, so I just hard-coded them. See if that has any effect. And I agree with the above about the wait, and I hear you it's a simplification I just try to use as little waits as possible.

ericmedley

MLaletas wrote: »

I noticed at some version of netlinx that I couldnt use constants for cases, so I just hard-coded them. See if that has any effect. And I agree with the above about the wait, and I hear you it's a simplification I just try to use as little waits as possible.

Interesting. I always use constants in Switch/Case. I have no code I've written in almost 10 years that this is not the case. I've not had any issue with it.

mush

richardherman wrote: »

Is this expected behaviour? If so, which is 'correct'? I can't imagine that today would be the first time I used a SWITCH...CASE after a WAIT . Could it be that this has changed in a recent firmware?

This has been a known issue for a long time.
See tech note 736.
http://trade.amx.com/techsupport/techNote.asp?id=736

richardherman

mush wrote: »

This has been a known issue for a long time.
See tech note 736.

Thanks!. that was what I was looking for. Seeing the tech note is dated november 2005, this probably won't be fixed ever.....

I probably did not ran into this before, because I usually do WAITS a little different, more like Paul wrote. If I do that in this situation (put the wait where the function is called) the SWITCH...CASE runs, although you could argue it is still inside a WAIT.

@MLaletas: Replacing the constants with hard coded values, does not help.

Anayway, thanks to all for the input.

Richard

MLaletas

ericmedley wrote: »

Interesting. I always use constants in Switch/Case. I have no code I've written in almost 10 years that this is not the case. I've not had any issue with it.

I know, I dont understand what the probem is using them, I used it for a couple years and I remember updating my software and after that I couldnt use constants in there, so ever since then I stopped using them.

fogled@mizzou

MLaletas wrote: »

I know, I dont understand what the probem is using them, I used it for a couple years and I remember updating my software and after that I couldnt use constants in there, so ever since then I stopped using them.

It seems like around half the common practices I use coding Netlinx center around some version of this: "Well. it didn't work right in that situation or version, so I developed the habit of doing it this other way."

Long live Netlinx and Netlinx compiler!

sling100

If you try the 'switch ... case' wait thing on a nx processor it crashes it!

richardherman

sling100 wrote: »

If you try the 'switch ... case' wait thing on a nx processor it crashes it!

That also happended to me. When I noticed the problem it was on a NX-3200. It either completely locked up the processor (power cycle needed) or suddenly rebooted. On a NI processor nothing much happens, except it doesn't run the code and throws up errors, of course. It never crashes.

Just one of those 'subtle' differences between the NetLinx family members, I guess...