Different colors in display expression

Hi everyone.
So, a quick question.
Is it possible to change the color of only one part of a $display expression?
here is my code:

$Name+" “+if($ReleaseDate==“never”) {”"} else {$ReleaseDate.year}+" ("+$TextLinkCount+"/"+$Text.paragraphCount+")"

I want only the $TextLinkCount to be in green color, and the rest to be normal.

In short ‘No’. To explain some background…

The display expression ($DisplayExpression) is evaluated to produce a plain text string ($DisplayName) which is rendered in place of $Name as the note’s title. However, the font face/colour rendering of the note’s title is set via other attributes and don’t have a granularity of setting below that level.

Put another way, in case it was supposed $DisplayName (and indeed $Name too) are not RTF strings.

Furthermore I suspect that the current view designs, not having been intended for such extra formatting, might not be adapted with out unexpected time/cost.

Thank you, Mark, for the quick response. Too bad it can’t be done because it might have been very helpful.

Indeed. My experience, over the years, is to pare pack on these sorts visual tweaks as a side-effect is visual noise. What looked good for a few test notes can make for an eye-searing effect if deployed in hundreds of notes.

There are other ways to foreground information (depending on view type). But there’s insufficient info here to suggest what those might be.

Incidentally, your action can be re-written to same affect, whist using less code. Thus:

Can be written:

$Name+" "+if($ReleaseDate){$ReleaseDate.year}+" ("+$TextLinkCount+"/"+$Text.paragraphCount+")"

Furthermore, if using such code in a display expression for lots of notes, best practice is to do all the calculations outside the expression. Thus we use an Edict or Rule (depending on the frequency of changes) to set a string attribute value. In the following example, it is $MyString - but you can use a String attribute name of your choosing. So the edict/rule is:

$MyString = $Name+" "+if($ReleaseDate){$ReleaseDate.year+" ";}+"("+$TextLinkCount+"/"+$Text.paragraphCount+")";

I’ve also moved the extra space after the branching code inside the if statement for better formatting. The display expression is then simply:

$MyString

…which displays the pre-calculated string stored in the note’s MyString attribute as the DisplayName value.

You might consider using both title a subtitle, each with their own color.

Thank you, @mwra, for elaborating on the subject.
I’m definitely going to use your code and suggestion to place it outside the display expression. But, how do I know whether to use Rule or Edict?
As for the visual presentation, I couldn’t agree more with the idea of avoiding visual noise. In this specific instance, I need the note display expression to represent the number of items on a list in the $Text, and how many of them have their own individual note. This note is “Album” prototype I created, which holds information about the artist in $KeyAttributes, and list of the songs in that album in the $Text. Another prototype I made is “Song” which automatically takes information from the album one I link them. I could have simply put the songs note inside the album container, but that doesn’t work for me since the main work I regard finding relationships between songs lyrics. The album is there just to hold and show a broader context. So, I wanted the album note to show me, how many songs are in the record, and how many of them I already actually use.

thank you @eastgate.
I already use Subtitle and Caption for other information

First, see this on Edicts. I would say you generally want an edict unless the data in the display expression changes more than once an hour. Otherwise you’re simply running the code unnecessarily often Plus as the article explains you can run edicts on demand.

If the data basically is unchanging once set - bar the odd correction - there is an even lower impact approach of using a stamp. In such a case the code only runs once on the selected note(s). After a correction, you’d simply re-apply the stamp.

That said, if you’ve only 30-40 notes in the document the differences between a rule and an edict may be indiscernible. But, if the document is large, or set to grow, then edicts generally trump rules in practical terms. Also the more complex the code being run, the greater likelihood an edict may be a better choice.

Confusion arises because edicts only arrived in v5 (IIRC) so much older documentation only mentions rules.

However, fear not. You won’t break anything. The main effect of lots of complex rules is the rules take longer to cycle through (as seen in the Agents & Rules Inspector). Even then, it’s not that hard to move $Rule code to $Edicts, especially if you’ve made use of prototypes. Don’t worry unduly about getting the ‘right’ solution first time around. As you use the app more you’ll find he sort of choices that suit your style of use by the things you’ve had to do-over in your earlier documents.

Last tip. If you’re the sort of user who basically has one (or a few) big files for their work, I suggest you experiment with things like action code in a separate throw-away test file. Then, once you’ve ironed out any mistakes you can port the code to your real work file(s) and throw away the test. It means you lessen the chance of fixing something you’ve just inserted all the way through your main file.

Ok, that’s great. I used your code in the Edicts and placed $MyString in the display expression of the prototype, and now it only displays $Name and $ReleaseDate.year and not the rest. I can’t figure out why.

OK, it seems you can use a conditional inline in a display expression but not a normal action As per my notes on the if() operator). IOW, in an action, the closing } of the if(){} ends the expression. But it would appear that an extra set of parentheses allow inline use of an if. This works for me in v7.5.6, as an edict:

$MyString = $Name+" "+(if($ReleaseDate){$ReleaseDate.year+" ";})+"("+$TextLinkCount+"/"+$Text.paragraphCount+")";

Perfect. It works well now. thanx a million Mark