A little CHOICE bug/enhancement

[StephenG1CMZ]

If a user program is choosing from a list of items, that list of items might be empty (all the asteroids between 9 and 9 m in diameter, perhaps). If such an empty choice is offered, the only meaningful response is 0 or Escape. If instead the user enters OK or Enter, it appears as though item 65 536 in the list has been selected.

Code:


EXPORT CHOOSEBUG()
BEGIN
 LOCAL CHOICE;
 CHOOSE(CHOICE,"",{}); //USE ENTER OR OK
 PRINT(CHOICE); //65 536
//GIVEN NO ITEMS TO SELECT SHOULD RETURN 0 (ESC)
//NOT ITEM 65 536
END;

Speaking of large choice lists, scrolling would be tedious. An enhancement to allow the displayed choices to be filtered by a text string typed on-screen would ease choosing an item from a large list.

BTW, I was pleasantly surprised at how quickly CHOOSE can open a large list..

[Arno K]

I think the problem is that 65536 equals 1 0000 in hex, if you now take 16 it integers that is zero, what you wanted, I think that lists with more than 65535 entries simply aren't supported on the calc, if you mask the result with #0FFFFh you get what you want, 0 represents empty list. As the help says that zero is provided if the user cancels you could better use your result 65536 as a hint for : uups, the list was empty. But I think such lists should be filled before giving the user the choose dialogue box.
Arno

[StephenG1CMZ]

I imagine many reading this post would assume most user programs would check the size of a list before presenting the user with a list and that this bug is of little consequence.

Whilst the bug can easily be avoided, if one takes a look at a practical example program - my Z editor - you will see several cases (annotated WA.CHOOSE) where it was necessary to surround a CHOOSE with an IF - basically, if the file directory is empty, or if no search strings are found.

if These IFs are omitted, the Android calculator is likely to require a Calculator virtual Menu/Exit. The consequence on the real calculator is unknown.

Whilst this example program might not be typical, it does suggest that dealing with empty choice lists might not be as rare an occurrence as first thought.

The usage in my program suggests that the best response is for CHOOSE to display the title and wait for a user response (as opposed to returning without displaying anything).