Hi,
I have an agent with the following $DisplayExpression:
$DisplayExpression = '$Name + " (" + count_if(children, $Checked) + "/" + $ChildCount + ")"';
The expression works as expected: ticking a child’s $Checked attribute updates the parent’s display expression to show progress.
But Tinderbox shows the Errors and Warnings dialogue with “This note’s $DisplayExpression cannot be parsed”.
I just can’t see where the error is – what am I missing, please?
Thanks!
I though the parser might be stumbling on the forward slash being treated as a literal division operator but changing ' to : the error persists. But, changing parentheses to square brackets, i.e.:
$Name + " [" + count_if(children, $Checked) + "/" + $ChildCount + "]"
…seems to work. Testing in another new TBX, I find that although your original code throws a parsing error, the Display Expression works and if I open the error list and double-click the error message (which makes the app re-test the bad code) the error clears.
My hunch here is a gremlin in the parser but the details of that are hidden from users.
FWIW, my muscle memory is to never use (literal) parentheses in Display Expression, perhaps because they were (are?) problematic—even though your Display Expression code is not incorrect syntax.
Generally, practice is to avoid doing calculations in directly Display Expression (a very old Tinderbox feature when action code was less capable. Whilst the above works, simpler/more robust is to calculate the desired string and store that. Then just get the Display Expression to display that attribute’s value. So, we might make a string attribute DEText. Then a rule (or edict depending on update speed needed):
$DEText=$Name + " (" + count_if(children, $Checked) + "/" + $ChildCount + ")";
$DisplayExpression |= $DEText;
The |= in the second line essentially means don’t do this if already done, i.e. if $DisplayExpression is already set, ignore the right-hand side of the expression.
So, whilst I’m unclear as to why the error shows, above are some ways around it. 
Thanks for the clear advice, Mark!
Most of the display expressions I use are of the `$Name + " (" + $ChildCount + “)” variety and are so simple that I just enter them in the Inspector QuickStamp field. Then when they get a bit more complex (as here) I add them to the Edict, and usually only put the really complicated ones into a separate attribute. Perhaps I should cut straight to doing that in future!
I’ve never had a problem with parentheses before, though. I’ll change them to [] in future, just in case.
In the meantime, double-clicking on the error clears it for me, too - thanks for your help!
This sort of advice is hard as it’s in out nature to follow rules literally (especially when we’'re unsure why they are there!). So, don’t rush to change anything. But for new files, I think it’s easiest to get in the habit of the ‘stored string’ approach and then the expressions can get a gnarly as you like.
Linked to the last is to parameterise the Display Expression if you can. So if you’ve lots of containers using a Display Expression for slightly different input, your rule/edict could read that part for an attribute. Then a prototype can hold the general part and all you do is set one (or more) attribute values in the container (which you might make Displayed Attributes) and you’ve got both the ease of use of prototype-inherited configuration with customisation.
That makes sense – I shall have to experiment…
Thanks again!
I’ll investigate why the parser is complaining.
FWIW, when you want an agent to set $DisplayExpression, I find it’s MUCH easier to let it copy the $DisplayExpression for some other note, perhaps in Hints. This avoids worrying about escaping quotes and whatnot, and also gives you a place to debug the display expression.
I don’t see offhand why Tinderbox is complaining.
You are saying count_if(), but you’re not saying what you are counting. Should the syntax not be something like ‘count_if(Children,$Checked==true,$Name)’, e.g., count the number of names if $Checked==true.
Actually, no You’re confusing the syntax with collect_it(). Whilst many _if operator variants take 3 arguments, whereas count_if() takes 2 arguments. I feel into exactly this trap when first looking at the problem.
See count_if().
The operator silently assumes that you want a +1 count for each item in scope (argument 1) that matches the query (argument 2).
Ah, yes, you’re correct. Thanks.
Thanks, Mark. I shall try this…
The countIf() operator reports an error when no error is, in fact, present. This will be fixed in the next release; you can safely ignore the error.
That was quick work – thanks, Mark!