Bluepoint Design

Multiple Choice Menu Save Item Value above 9 does not work properly

2009/04/22 1054

I experimented with many values and created the map below of what's happening. It's useful to see the ASCII decimal value for what is returned so I put that in the second column. First column is what appears in the creation dialog box. The right column shows what text is returned. As you can see A-9 work fine but AA does not return AA. Quite simply the ASCII values start at 65 for A and then shift down to 48 for zero. After zero the decimal value simply continues to increment until 255 after which it starts back over at zero. This means it repeats the upper case alphabet. So a user expecting AA or other such values will not get the desired results. What's worse if the end user selects HH the value returned will be A! Very dangerous.

Suggestion: Probably the easiest solution is to remove AA and above from the list and at some validation not to allow any more items but I would like ot suggest that instead of returning ingle digit letters and numbers that instead simply return an integer value corresponding to the row. Of course I can see the reverse compatibility issues here. Perhaps we need Multiple Choice Menu Enhanced command and keep the old one for reverse compatibility.

I was really hopping I could just use the ASCII decimal value but obviously that will not work as it will repeat itself. 

Note: Save Item Text appears to support unlimited values but after a few hundred items it does slow down significantly.

2009/06/04 1338 Update

A change was made in version 4.0.3 to fix this problem but there are a couple of problems with the fix. The release notes said "Made a change to the 'Multiple Choice Menu' command where options above '9' will return an ASCII character starting at character 90 and up through 255." but even this is not correct. Below is my original chart to which I added 2 more columns for version 4.0.4.

The first and most dangerous problem is that 9 in the command dialog should return a "9" but it actually returns ASCII 90 which is a "Z". This means Z is not unique in the table!

The next problem is that the command dialog lists the next line after 9 to be "AA" but instead a user will get "[". According to the release notes the correct character is being returned but the command dialog should not suggest that the value returned is "AA". EG the last label should be 9 and we should see none of the double characters.

In case anyone is wondering I plan on using the ASCII values to make a quasi row numbers by subtraction of the ranges. EG I can tell "M" is row 13 because it's ASCII value is 77 and I subtract 64. This can be used as a array pointer to retrieve multiple values in parallel arrays that I use as quasi tables.

2009/06/08 1125 ISS has opened a new tracking number 7112 for this incident.