Stamp behaviour between documents

Agents, Actions and Automation
1

I have a large TBX document I use for a family quiz night. I collect questions from the internet in $Text and have a note attribute $Answer - I use simple templates to export the question in $Text with and without the $Answer

I recently found a long list of questions in the format

‘What is the capital of France? Paris’

I cut a pasted 50 questions and used explode to create a note for each question

I then used this stamp to populate the $Answer ( the bit after the ? ) and expected $Text to be just the question

$MyList=$Text.split("\?");
$Answer=$MyList[1];
$Text=$MyList[0];

The $MyList is populated as expected “What is the capital of France;Paris”
$Answer (Paris) also populates ok too
However, any attempt to use $MyList[0] results in a blank - ie the whole of $Text disappears

(Same happens if I use $MyList.at(0))

I created a small test file and it worked fine - all of it.

So I’m stumped - stamp works in one file and not another?

I’m happy to keep testing but was wondering if one reason is the age of the document. ( The quiz one started over 4 years ago and is massive which is why I haven’t posted it )

Are there any other generic reasons why a stamp would behave differently between documents?

tia

2

I can’t replicate this in v9.5.2(b606) (on macOS 12.6.8) using the description above. I see:

Untitled 2023-07-29 23-17-08
Untitled 2023-07-29 23-17-081752×462 32.2 KB

I think some other factor is at play.

3

If you can share the file, that would (a) be really interesting — what a fun application! — and (b) help get to the bottom of this mystery.

4

I’ve cut down the main quiz file as too big to upload ( but will happily share it with anyone that would like it ) and also created a test file with the same stamp and same set of 50 question notes as are in the ToSort container of the quiz file

In the test file the stamp works as intended - in the quiz file the text is deleted (or replaced with an empty MyList[0] value)

Thanks for taking a look

Quiz_Stamp.tbx (609.7 KB)
test_stamp.tbx (763.3 KB)

5

Well, that is odd. I can replicate this ‘error’, i.e. that calling a list item number 1 (i.e. index value 0) fails. It fails forMyList, it also fails for a user list attribute. But only in TBX ‘Quiz_stamp’ and not in other notes.

Why that’s happening is beyond me. I’ve checked for rules, edicts etc., but there are no queries, no rules, in fact no automation. so, nothing running in the background that might interfere. The code creates valid List-type data which can be seen in a Displayed Attributes and which reports the right number of list items, etc. It will return any item except the first. Thus List[N] and list.at(N) works for any valid value of N (i.e. depending on list size) _except for an N value of 0 for the first item. go figure.

As the gremlin seems to be in this one file, the pragmatic fix is to copy the question notes to a suitably customised (user attributes, etc.) new file and carry on. It’s probably quicker than figuring out what’s gone wrong in the original TBX (though the file will be of interest to @eastgate as the glitch is bizarre and definitely not like anything i’ve encountered in the past).

A side observation: your exploded text has inherited 3 spaces at the beginning. It wasn’t the cause of the above but a factor I had to check before discounting it (having seen you had list items with leading spaces, which is very unusual). Anyway, if you have unwanted leading/trailing spaces on a String ($Text or otherwise) String.trim() is your friend. See the link for more features in .trim().

1 Like
6

Thanks, Mark appreciated - I’ll look forward to @eastgate response.

7

Hmmm! This might take a day to diagnose.

1 Like
8

Oh, this was great!

If we open the User Attribute inspector, we see that the first attribute is named “0”! (You can’t do this anymore, but in days of yore you could.)

Screenshot 2023-07-30 at 11.06.31 AM
Screenshot 2023-07-30 at 11.06.31 AM730×968 147 KB

So, Tinderbox sees $MyList[1] as a request for list element 1, but $MyList[0] is a reference to the default value of the attribute 0, which happens to be ‘false’. So it tries $MyList[“false”], but $MyList isn’t a dictionary, so no dice!

3 Likes
9

Thanks Mark - potential for some kind of compatability check perhaps when opening old files?

I’ve no idea why I created an attribute called ‘0’ - I expect it was a typo. My incremental formalisation tends towards messy files so I’ll use the Attribute inspector as part of my debugging from now on

Thanks again Mark A too

1 Like
10

It can’t happen anymore :slight_smile:

(Of course, in the meetup Michael Becker came up with a scenario where it can happen during spreadsheet import. We’ll close that loophole in the upcoming release.)

11

You might not have created it. If you ever copied or pasted in a CSV file that had a column head labeled “0”, then, as it is designed to do, it would automatically create the attribute.

Love this edge case. :slight_smile: Super interesting.

12

So, whilst this edge case looks to (be being) fixed, an interesting question arises from @satikusala 's point about tabular data (aka spreadsheet) import making new attributes. Things are easy if you’ve only 2 or 3 user attributes, but what if you have 40, or 60 or more?

Action code to the rescue!

Tip. Use this code as a stamp (or rule, etc.) on a new note:

$Text=document["user-attributes"].format("\n");

Now the $Text of the note is an A-Z sorted list of all the current document’s user attributes. You can now review the list and take a closer look at any attributes you don’t recall making.

In context, another…

Tip. For any document you’ll be keeping is to add a description for your user attributes. A purpose ‘self-evident’ from the attribute name can fail to be so 6 months later. So, good to note is what the attribute does and, why it was needed—e.g. it relates to a particular workflow issue or a particular subject or source.

1 Like