Messages in this thread

Possible bug in switch statement? - Tony, 12 Jun 09:05AM
     Re: Possible bug in switch statement? - Bob Zawalich, 12 Jun 10:42PM
         Re: Possible bug in switch statement? - Tony, 14 Jun 05:35AM

Possible bug in switch statement?
Posted by Tony - 12 Jun 09:05AM (edited 12 Jun 09:07AM)
I think there is a bug in the plugin language regarding the switch statement. I am calling a method to convert decimal numbers to roman.

switch (pNumber)
{
case "1"
{
positionRoman = "I";
}
case "10"
{
positionRoman = "X";
}
}

I have missed out the intervening numbers for brevity.

When pNumber is "10" the above switch statement returns "I" when it should return "X". It would seems that the switch statement is not matching the whole string, but the first character when it matches.

I have found the workaround is as follows, proving my point.

switch (pNumber)
{
case "10"
{
positionRoman = "X";
}
case "1"
{
positionRoman = "I";
}
}

This switch statement does return "X".

Hope you find this helpful.

Back to top | All threads
 
Re: Possible bug in switch statement?
Posted by Bob Zawalich - 12 Jun 10:42PM (edited 12 Jun 10:43PM)
Tony - you should probably sign up for the plugin-dev list and ask ManuScript questions there, since they are really not of interest to most people using this list.

The problem is known. There is a thread about it from 2010, where this was part of my response:

*********************************
I am not sure it works with cases, but in some situations I have set up comparisons so that substrings of a longer strings are always compared after the longer string is tested - this is consistent with what you are showing below.

You can sort an array in reverse order, for example, and then use
utils.getArrayIndex to find a string.

I am not positive, but I think the problems only occur when you have a
single character literal. These are internally of type "char" and not
"string". CharAt also produce a char. I have often wished that data type were gone. I see no advantage for it and it causes trouble.

I often do something like
str = "" & str:

if it is possible to be called with a literal that may be a single
character. That forces str to be of type string.
**********************************************************

I do think that the problem only happens if single character literals are involved. It is, of course a problem to have comparisons return the wrong result, but it is been like this from the start and is not likely to be changed. Kind of like the way expressions are evaluated from left to right with no priority, so you always need to parenthesize anything complex. Or like the fact that an array always returns an address rather than a value, so you can't say

y = arr[1];

but you must say

y = "" & arr[1]; or
y = 0 + arr[1];

It is a really quirky language.

--
Bob

An experienced user of Sibelius. Sib 1.2 - 8, Windows 10 Pro 64 bit, 32 G RAM. Year 2018.
For plugin lookup and categories see https://www.nycmusicservices.com/musicresources
For manual plugin installation see http://www.sibelius.com/download/plugins/index.html?help=install

Back to top | All threads
 
Re: Possible bug in switch statement?
Posted by Tony - 14 Jun 05:35AM
Hi Bob

Understood.

I have a workaround, so no problem. I just need to remember to place the longest strings before the shorter ones.

Thanks.

Tony

Back to top | All threads
 

Quick reply

To add a reply to the end of this thread, type it below, then click Reply.

(.sib, .png and .jpg only)

Messages in this thread

Possible bug in switch statement? - Tony, 12 Jun 09:05AM
     Re: Possible bug in switch statement? - Bob Zawalich, 12 Jun 10:42PM
         Re: Possible bug in switch statement? - Tony, 14 Jun 05:35AM