In a file, I have a $DisplayExpression that reads:
$ExamText+": "+$Title
The two attribute values are displaying correctly but the string displays as:
;:;
I’ve tried to clarify things by adding parenthesis:
$ExamText+(": ")+$Title
and I’ve copy-pasted the expression into and out of BBEdit to verify the quotations aren’t curly (even though I think the display expression box in the inspector won’t accept curly). I’ve also tried the expression in a sample file and it works. A near identical expression was also working an hour ago in my work file. (I simply inverted the attribute order around the colon.)
So I’m stumped and wondering if anyone has a suggestion about what else might be causing the semi-colons to appear now?
correction: The display expression that was (and still is) working is:
$Title+" ("+$ExamText+")"
So I guess my question is why the expression I want to use is generating semi-colons?
I’ve also tried replacing the colon in the string with a double hyphen (–) and that revised expression also produces semicolons.
$Title and $ExamText are String-type user attribute
Values of the above are simple strings with no line-break, control characters, etc.
Thus I took a new TBX, added a note, set it’s KA to the two above variables (both create and set them). I gave $ExamText the value “yy zz” and $Title the value “xxxx”. Using the DE $ExamText+": "+$Title I get a $DisplayName string of:
yy zz: xxxx
Which is correct. This test would suggest other factors at play. Things to consider when checking in a TBX with other structures:
Is the DE code set via inheritance? If so, are the notes you are viewing using the inherited DE or a local value - e.g. the detritus of a failed earlier test.
Are either/both of the input values possibly using problematic values.
To test one aspect of the latter - a semi-colon in the input string, in my text note I changed $ExamText the value "yy;zz"with the same DE code. The result is:
yy;zz: xxxx
So it’s not that problem.
Bottom line, and general advice, is that if you hit an apparent glitch like above and the cause isn’t self-evident then make the smallest possible test file and validate your code (here, that was quicker than typing this reply). We’ve quickly proved the issue isn’t the DE code but some other factor: either an unstated (and untested) assumption or the effects other code.
First off, real apologies: I made a test file and saw that the syntax was working there before writing my original post but for some reason that I can’t fathom now I didn’t mention that (important!) information in my post.
Regarding source of the DE code: I have a note with the code as its DE sitting in a utility container and use a stamp to apply this DE to other notes by using this code:
The stamp seems to be correctly applying the DE code because the stamp places a DE for the stamped note that I can see in the inspector. As I switch the DE in the utility note, I can use the stamp to apply the changes elsewhere. When I use the working DE in the utility note, the stamp makes the DE work in the stamped note.
The attribute $Title is a string but $ExamTexts is a set. Neither contain any values that include punctuation. I also don’t have any agents in the file that contain Action Code. For now they simply query. So I really can’t figure out what other factors could be at play that aren’t at play in the small sample file and that could make a quotation mark suddenly read as “;” in one DE but not in another.
For now I’m just going to use the DE that works. But if I figure out what is causing the problem with the other one, I’ll report back.
Thanks for the follow-up explanation. Guest are due here soon, so I can’t test, but…
Given the extra info on the attribute data types instead of two strings we’ve a string and a list of strings (e.g. a List or set type)
In the original working DE:
$Title+" ("+$ExamText+")"
we have in generic terms:
string+string+list-coerced-to-string+string
In my test doc I changed $ExamText to a set , value ‘yy;zz’. The result in my test doc of the above DE: xxx (yy;zz)
Now the bad case:
$ExamText+": "+$Title
which is now
list+list-item+list-item
as we are adding new strings to a list, i.e. adding new items to a list. In my test doc, the result is yy;zz;:;xxxx
To get a value like I think you want, if we make the DE this:
$ExamText.format(";")+": "+$Title
The result is a DisplayName string yy;zz: xxxx, which is what you expected. the use of .format() on our $ExamText set-type data, turned it into a literal string with a semi-colon wherever a value join occurs. If we used a DE:
$ExamText.format(", ")+": "+$Title
we now concatenate the Set using a comma+space, resulting in a title like yy, zz: xxxx
Take-away points:
when concatenating (joining) inputs from different Tinderbox data-type sources, do consider the effect of coercion of data types. If Tinderbox’s best guess doesn’t work, you might need to use extra action code function like .format() to indicate to Tinderbox your true intent.
test files win out. I’d actually deleted my original test file when I saw the follow-up reply. But, the simplicity of the technique made it the work of moments to build and re-test. Had the file still been open, it would have been a simpler task of changing the data type of $ExamText in the User tab of the Document Inspector.
Thank you for the very detailed explanation. I was just coming back to post that I didn’t see the problem if I switched $ExamText to a string and to ask why starting with a set-attribute would change how the following items were interpreted.
What I take away from your explanation is that order matters and that the data type of first/earlier attributes in an expression can effect how subsequent pieces are read because it determines what kinds of data an expression is understood to be trying to generate. That wasn’t on my radar at all. So thanks.