$DisplayExpression truncated if it contains punctuation

[brookter (David Bertenshaw)]

Hi. V9.5.2 on an MBP M1

I’ve just come across some behaviour that I’m finding it difficult to understand.

$DisplayExpression (as the first outline column or map title) refuses to show anything beyond the first punctuation item if it’s the reslt of a conditional. (The underlying attribute is correct, it’s the display which is wrong.)

Take the following rule:

if($MyString=="") {$DisplayExpression = $Name} else {$DisplayExpression = $MyString}

This produces the following results in the Outline ‘name/displayexpression’, or as the note title on a map.

1. An empty $MyString shows the name as expected
2. $MyString=="A string with no punctuation" → "A string with no punctuation.
3. $MyString=="A string with some, at least, punctuation." → “A string with some”. (String truncated at comma)
4. $MyString=="Another string. With some more punctuation" → “With some more punctuation”. (String before full stop and following space ignored)
5. $MyString=="Well: what is going on here?" → " what is going on here" (String before colon and following space ignored).

NB: the actual $DisplayExpression is being calculated properly, it’s the display as the first Outline column or the note’s map title which is behaving oddly.

Here’s a screenshot to make it clearer:

A previous post with the same issue was resolved because there had been an earlier action affecting the output, but my problem occurs in a freshly created tbx, with no prior agents / rules at all. (DisplayName does not match DisplayExpression due to punctuation)

DisplayExpression issue.tbx (283.8 KB)

Can anyone see what I’m doing wrong please?

Thanks

[eastgate]

A $DisplayExpression is an expression — a formula that Tinderbox evaluates. For example, if a note’s $DisplayExpression was

$Name + ":" + $Width

then a note 5 units wide and named “Dodgers” would appear was “Dodgers:5”.

So, what happens if the display expression is just some text, say albatross? Tinderbox asks, “could this be an expression?” Is there a local variable named albatross? Is there an attribute named $albatross? No? If not, the value of the expression is the text that Tinderbox couldn’t parse.

Now, suppose we insert a period: cat. The period in an expression introduces an operator — something like $Text.size() or $MyList.reverse. So Tinderbox says, “Hmmm… OK: I take cat, whatever that is, and pass it to the operator… Whoops! There is no operators! Something has gone wrong! So, the value of the expression is the text that Tinderbox had consumed before the parser recognized the failure.

In all these cases, I believe that you’ll have the result you expect if you enclose the string in $DisplayExpression in either single or double quotes. Quotation marks tell Tinderbox: “This is a string!”

[brookter (David Bertenshaw)]

Hi Mark,

Thanks for the quick answer! That makes sense – and I’ve done a quick test and it seems to work for my examples.

I suppose I was thinking that $MyString is a string attribute, so any content would always be treated as string unless I explicitly converted it, but clearly that’s not the case.

Many thanks!

David

[eastgate]

$MyString is a string attribute, but you’re storing it in an Action attribute. So it’s converted to an action first.

[brookter (David Bertenshaw)]

I hadn’t appreciated the distinction – thanks!

[mwra (Mark Anderson)]

Unpicking this a bit for general understanding of the principles…

So $DisplayExpression is an action type attribute, most easily checked via the Dcoument Inspector’s system tab:

So in the demo TBX above we have this Rule being used:

if($MyString=="") {$DisplayExpression = $Name} else {$DisplayExpression = $MyString}

Here the ‘error’, easily made, is one that was a top topic in early Tinderbox days. A Display Expression is an action and so these two similar-looking expressions actually have differing outcomes:

$DisplayExpression = $MyString; // set the value of $MyString
$DisplayExpression = "$MyString"; // sets the string '$MyString'

Using the former the Display Expression result is:

When what we actually wanted is:

![Text Inspector: DisplayExpression issue 2023-08-01 09-21-19|656x244, 50%]
(upload://cKPjaJwptjlL8viUzht3neXi6kn.png)

We are setting an attribute value of an action, so the contents of the attribute need to be the code that _evaluates (as $DisplayName) to the desired
So the rule needed is:

if($MyString==""){$DisplayExpression = $Name;}else{$DisplayExpression = "$MyString";}

or in shortest form with allowed elisions:

if($MyString){$DisplayExpression = $Name}else{$DisplayExpression = "$MyString"}

fixed the latter, per post below:

if(!$MyString){$DisplayExpression=$Name}else{$DisplayExpression="$MyString"}

Test file with original rule:

Test file with corrected rule:

If we add $DisplayName as a column the process is a little clearer:

Display Expressions are thus one place where at times you do want to do the counter-intuitive task of putting a $-prefix attribute reference inside a quoted literal string.

Container OnAdd actions is another were people trip on this same issue. There the user wants the new child to inherit the parent’s OnAdd action ($OnAdd). Again, the trick is to pass the necessary code as a quoted string rather than the code itself (even if only a single attribute reference like above) .

Apologies for an image-heavy post but I think it perhaps makes the differing outcomes easier to see (no pun intended!).

[brookter (David Bertenshaw)]

Thanks for interesting details, Mark – I appreciate it. Quite a lot to take in, but I shall study it with interest.

Just a minor pick, though: in the ‘shortest form with allowed elisions’ statement, shouldn’t if($MyString) actually be if(!$MyString)?

Thanks again.

[mwra (Mark Anderson)]

@brookter

shouldn’t if($MyString) actually be if(!$MyString)?

Ha - yes! To explain for lurkers.

$MyString==""

tests that MyString, which is a string type attribute, has the String default empty value of "", an empty string. In such condition the note is held to have no value for attribute ‘MyString’. The opposite test is

$MyString!=""

i.e. the attribute value is not empty, i.e. it therefore has a value.

The ‘short’ way to write such test:

$MyString!=""
// becomes
$MyString
//because coerced down to a true /false state any value but "" becomes true
// and it behaves like $MyString==true

The opposite:

$MyString==""
// becomes
!$MyString
//because coerced down to a true /false state the value but "" becomes false
// and it behaves like $MyString!=true aka $MyString==false

I’ve fixed the post above - I changed the short form on the fly which i s why i missed it. I was thinking more about whitespace before/after the { } (which is allowed but little seen) and the semi0colon is the code branch is but a single expression.