Problems using $SiblingOrder-1 in Export when using same Code in another file

Exporting from Tinderbox
1

I am not sure if this is a bug, but the code I am using in one file (works perfectly) doesn’t work in another file.

$Text(parent(original)) contains 4 lines of text which I do reference from child notes during export. I run the export via an Agent where I have collected ll children notes.

The line of code which works differently in the new file is:

^value($Text(parent(original)).split(“\n”) .at(** $SiblingOrder(original)-1 ))^

Instead of getting Line 1…4 I only get Line 1…3 (see picture to illustrated the case)

image
image2611×1685 554 KB

In the old file the line code works fine. I tried several things but I don’t get any other result.

For reference I have attached the file.

SiblingOrder issue.tbx (128.6 KB)

2

Wow! That was an adventure!

The problem is… (drumroll) …

You have a user attribute named “1”! As a result, Tinderbox is interpreting

$SiblingOrder(original)-1

as requesting the value of the attribute named “1”. And the value of the attribute named “1” is zero.

Renaming or deleting this attribute will resolve the problem.

2 Likes
3

Thanks Marc for your prompt response. I have imported an excel table via copy and paste. Most probably that caused the issue and the user attribute was created.

1 Like
4

:rofl: Kicking myself now. I spent a good while on this last night before giving up and heading off to bed. I’d verified the error and proved it only happened in the test file, and seen the ‘1’ user attribute but didn’t join the dots.

For later readers, expanding on @eastgate’s description, this is a good example of where legacy usage support for old action code, before the days $-prefixes were needed, can bite. The issue is the user had (inadvertently) made a user attribute. This resulted in:

$SiblingOrder(original) - 1

being interpreted as:

$SiblingOrder(original) - $1

As the default for attribute ‘1’ was 0 (zero), this meant:

$SiblingOrder(original) - 0

Odd, when $SiblingOrder subtracted by any other value but 1 works!

I’ve made a note to reference this in my aTbRef article on suggested attribute naming. From today’s perspective, it’s too easy to say “take this legacy stuff out”. But, the app’s been around for >20 years, originally action code didn’t use the $-prefix, and yanking such support would just ruin the day of long-standing (paying!) Tinderbox users.

A really interesting support case that had me stumped and ‘chapeau’ to @eastgate for catching this.

If there is a ‘lesson learned’ from this, it is: don’t make user attributes with ‘names’ that are numbers, e.g. ‘5’, and if you do make the default the same as the name-number. Taking the latter into account, I think this means, friends don’t let friends make user attribute whose names are literal numbers.

But, this is a real and odd edge case. No one, user or app did anything stupid or wrong. It shows that the easy “why doesn’t it ‘just’ work?” reaction that we all have can un-pick some odd confluences.

1 Like
5

Sorry Mark, I didn’t wanted to trash your evening. I had the same and got stuck with this. As it was working in the other file, I wasn’t able to figure it out.

Just forgot the excel sheet I pasted just before and I remember now that Tbx creates Attributes on the fly. This is very convenient and makes importing notes with meta information very easy.

1 Like
6

No harm done, I was under no compulsion to try. Most times I can figure out the problem and I like a puzzle. :slight_smile: But thanks for your kind post.

2 Likes