and found that while the color was successfully modified, the text showing on the note was a sort of truncated “minutes” value (e.g. when it was 10:49 PM here, the value showing was 49 PM).
I played around with a few different date modifiers, thinking that was my problem, until I enclosed the expression in single-quotes, as:
The second formulation is correct because $DisplayExpression is a string that contains action code. You do not want to set $DisplayExpression to the result of the code, as in your first formulation. What happens in the first case of your example is that $OnAdd evaluates the code to the right of the “=”, and then sets $DisplayExpression to that result.
Another context where care is needed is if setting the $DisplayExpression of another note, e.g. via an $OnAdd action. In this cases it is important to ensure the application understands the result is a string. A good example is when the code returns something that might be a sum, like a date in “20/5/2010” form: The following is not good $OnAdd code:
$DisplayExpression=$CreatedWRONG
$DisplayExpression=$Created.format("l")WRONG
Although both the above right side values can safely be added into a Text Inspector Title sub-tab’s Display Expression box, they do not work for code-based assignments. Instead, it is necessary to force a string:
$DisplayExpression='""+$Created+'"'GOOD
$DisplayExpression='$Created.format("l")'GOOD
Notice, in both how single quotes are needed. In the first case they enclose each instance single instance of a double quote (quote characters cannot be escaped in Tinderbox). In the second case they enclose the whole string as it already contains double-quotes surrounding the date format string.
@PaulWalters has kindly quoted my aTbRef notes, and the benefit of reading them posted by someone else make me wonder if I can’t/shouldn’t improve these. …
What you see on screen as a note’s title is actually $DisplayName which is either:
$Name is there is no $DisplayExpression or…
a static String evaluated from the contents of $DisplayExpression
IOW, $DisplayExpression is a string that holds the code of an expression. Confusion is further caused, on initial use, by the fact that what you paste in the ‘Display Expression’ box on the Text Inspector’s ‘Title’ pane is the contents of that string. Add in the fact that many Display Expressions are likely to use quoted strings and you hit the issue of having to nest double quotes using single quotes or vice versa (or more complex tricks is needing to use both quote types in the actual expression.
I think the confusion at the route of this thread is not what a DE does but how to set it and I’m open to a better way to describe it so we have a better resource for those new to the app who are feeling their way into such features.
It might be confusing to some to see that $DisplayExpression’s type in the Inspector is “action”. Perhaps the type should be “string expression” or similar?
Good point. The Tinderbox Help file (page: ‘Attributes’) describes Action-type attributes thus:
The Action data type is only used internally. $AgentAction, $DisplayExpression, $OnAdd, $Rule and $TableExpression are all Action type attributes. These attribute all hold strings of Tinderbox action code and are evaluated as such when used.
In many respects, Action-type attributes can be considered a special form of String-type attribute.
The attribute data type of ‘action’ represents a string that can be used as an action; under the hood, Tinderbox caches the compiled action so it does not have to constantly re-parse the same expression. Thus these attributes should contain a string [sic] of valid Tinderbox action code.
However, both these only makes sense after the fact. Not least, you won’t see those description if you don’t like to open Help or don’t know of aTbRef.
There are several issues intersecting here:
The “FFS, how hard can it be to just…” problem, especially for users still new to Tinderbox. How does one do [task] right now without being bored with background explanations.
Tinderbox data types, e.g. String vs Action and the nuance of that difference.
Expressions in general (Display, Hover, Table): how they are stored (in attributes) and displayed /used in the UI.
I get the immediacy of the first and am always happy to give the no frill-answer but an open to how to offer a better bootstrap option for new users. Something available to stop users getting caught in a loop of item #1 above.
It certainly took me a while to get the hang of how D/H/T Expressions work, and as importantly when to pre-compile them rather than compute on the fly. The latter is too nuanced for first use except for those who like to read the handbook first, which to be honest isn’t most of us most of the time—for all sorts of perfectly good pragmatic reasons.
I sense we need a tutorial type article (web, PDF, whatever) explaining the mechanics of Display Expressions, with appropriate illustrations/code examples/links to references, so as to enable better bootstrapping.
