The short answer is don’t use numerals (i.e. digit characters) as the strings for the list key. After testing more possible things is wasn’t (of which more below), I changed your 0-8 keys to A-I and use the same keys in the calling code and all worked. Thus the look-up list is:
And the calling action:
In hindsight this isn’t unsurprising. If you look at the examples for look-up lists (aTbRef based on Tinderbox’s own RNs) the examples use non-numeric key values. Back-of-houseTinderbox has to do lots of coercion of type figuring out if ‘1’ means integer
1 , string “1”, or a Boolean
true. Here, an unwitting choice of key names seems to have confused Tinderbox. As the keys were also the literal list
.at() values, it was returning the whole list value. IOW,
$ProgressImages("Lists").at("0") would return
"5:progress_0625" rather than
Until resolved, I’d work on the premise that look-up keys (i.e. the bit before the colon:) should not start with a digit. Or, at least not digit(s) which is actually the literal zero-based index number of any existing list item.
Thus I revalued the original keys as 1-9 and the look-up failed. When I then revalued the keys as 10-19, the loo-up worked. Why, because the lowest numerical key value used was 10 and and the highest actual list value was 9. Generalised, you may not know the number of list values which might change over time so it’s unsafe to assume a number is outside the range of list value positions.
A safe compromise to your existing list values is:
Now edge cases…
Line breaks in list creation. As it happens Tinderbox is smart enough to realise your second list value isn’t meant to start with a line break character. However, I think it’s not a sensible assumption as if/when Tinderbox guesses wrongly it may lead to some odd results you might find difficult. If you must use a value per line input, place the line breaks out side the values, thus:
List or Set for look-up? I did wonder if using a Set was an issue as Sets don’t always retain original input order. As it happens, a Set is fine and does de-dupe, which you do want if dynamically making the list. But it was considering correct list addressing that led we to find the glitch above.
Making lists with rules I think this was a byproduct of an exploratory test. But, in general don’t use a rule to set a fixed value except for the specific case where you need to constantly re-assert a particular value. Either use an edict, a stamp, or construct the list in a plain text editor
and simply paste that into the attribute value box.
[Edit] Note that if pasting to a KA value box, do not paste the action code as above but first remove all the action code. Thus for the last code example above you would paste this without enclosing quotes into the KA value box for $ProgressImages:
notice, no line breaks, no action code, just a _literal list string (the semi-colons being the list value delimiters)