Switch..Case - Bug?
ekeppel
Posts: 37
I'm running the latest Netlinx Studio 2.4.0.129
This doesn't compile. "Major system error occurred during code generation":
SWITCH(Cmd)
{
CASE '.': SEND_STRING dvDevice, "'Dot'"
CASE 'Test': SEND_STRING dvDevice, "'Test'"
}
But this does:
SWITCH(Cmd)
{
CASE 'Test': SEND_STRING dvDevice, "'Test'"
CASE '.': SEND_STRING dvDevice, "'Dot'"
}
Just the same two CASE statements in a different order. Any idea what's going on here? Bug in Netlinx Studio perhaps?
I searched the forums and couldn't find anything on it, so I thought I would ask. Maybe it's related to the lower 8-bit bug/feature with switch..case statements. I read elsewhere on the forum of a similar problem with the order of CASE values beyond 255.
Just got me curious, so I thought I would see if anyone had an answer to offer.
--Eric
This doesn't compile. "Major system error occurred during code generation":
SWITCH(Cmd)
{
CASE '.': SEND_STRING dvDevice, "'Dot'"
CASE 'Test': SEND_STRING dvDevice, "'Test'"
}
But this does:
SWITCH(Cmd)
{
CASE 'Test': SEND_STRING dvDevice, "'Test'"
CASE '.': SEND_STRING dvDevice, "'Dot'"
}
Just the same two CASE statements in a different order. Any idea what's going on here? Bug in Netlinx Studio perhaps?
I searched the forums and couldn't find anything on it, so I thought I would ask. Maybe it's related to the lower 8-bit bug/feature with switch..case statements. I read elsewhere on the forum of a similar problem with the order of CASE values beyond 255.
Just got me curious, so I thought I would see if anyone had an answer to offer.
--Eric
0
Comments
Here's another thought... Maybe the compiler is having an issue with the single character being used in the same context as the array.
Try this instead:
The above is not true...
What is happening is the Compiler sees the '.' in the first CASE evaluation and registers single CHAR values for the SWITCH..CASE, thus any CASE after that MUST be a single CHAR value. A STRING after that will cause an error because it is not a single CHAR value.
I'm not sure if this is meant to be this way...or it is a bug, but thats the explaination why your example above doesn't compile.
even If Cmd is defined as a string, if the string only has a length of 1.(in this case '.'), it will still register a single CHAR value.