Help with Lookup Tables

Agents, Actions and Automation
1

I have a Note called Lists. Its Rule is as follows:

$ProgressImages="
0:progress_0000;
1:progress_0001;
2:progress_0125;
3:progress_0250;
4:progress_0500;
5:progress_0625;
6:progress_0750;
7:progress_0875;
8:progress_1000
"

$ProgressImages definitely exists in the Document, as is a Set.

A Note called Test has a simple Rule:

$Badge=$ProgressImages("Lists").at("0");

That fails to assign a Badge. However, this works:

$Badge="progress_0000"

What am I missing?

2

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:

"A:progress_0000;B:progress_0001;...."

And the calling action:

$Badge=$ProgressImages("Lists").at("A")

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 "progress_0625".

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:

$ProgressImages="x0:progress_0000;x1:progress_0001;..."

And calling:

$Badge=$ProgressImages("Lists").at("x0");

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:

$ProgressImages=
"x0:progress_0000;" +
"x1:progress_0001;" +
"x2:progress_0125;"

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. :smiley:

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:

x0:progress_0000;x1:progress_0001;x2:progress_0125

notice, no line breaks, no action code, just a _literal list string (the semi-colons being the list value delimiters)

1 Like
3

Thanks, Mark. I have prepended my keys with ā€œxā€ and now it all works. I also got rid of the Lists note and just inserted my $ProgressImages value in its Default box in the Attribute dialog. I didnā€™t know I could do that. Makes sense.

I do notice that modifying the format of the Set as suggested here:

"x0:progress_0000;" +
"x1:progress_0001;" +
"x2:progress_0125;"

makes it impossible to insert that value in the Attribute Default box and make it work. TB wants to surround the entire string with quotes.

1 Like
4

Sorry. Yes I should have been more explicit about the format in each case. KA value boxes wonā€™t have the extra inbound parsing that action code inputs take. Generalising advice gets tricky as what works for 4-5 terms might not really work with 400-500 terms. Conversely, something that works for the latter might be pointlessly cumbersome with the former.

Iā€™ll amend my earlier post lest it trip up readers coming to this in the future.

1 Like
5

Got it. Thanks, Mark.

1 Like
6

Iā€™ve updated my guidance on look-up tables to cover the issue of number-only key values.

1 Like
7

Looks good.Thanks for what you do here, Mark.

1 Like