I'm trying to get an outline title to turn red under certain conditions and find this fails to do anything at all:

Code:

If (condition){$NameColor = "bright red"}; 

Probably something obvious.

Ah, okay. And, though I find

Code:

$Color="bright red" 

turns the outline note title to red when I use that as a rule, the following test to see if I understand how to construct a conditional does not:

Code:

If(1=1){$Color="bright red"}; 

Check out $Color, $Color2 and $NameColor. $Color is the main color of a map icon and used for the colour of the note title in all other views**. $NameColor is used for the colour of the title on map icons.

** In Outline & chart views, there are settings in Document settings/Outline that set note titles to use a darker tint of $Color or use a pure black for all titles.

For conditionals, use if(){}. Note that the 'if' is lowercase & case-sensitive. The initial condition must resolve to a true/false result:

if(true/false test){true code}
or
if(true/false test){true code}else{false code}

So:

if($Name.contains("red")){$Color="bright red"}else{$Color=;}

Any note called red or whose title contains the sub-string 'red' will be coloured red. All other notes will have $Color reset to use the default $Color value.

Semicolon terminators. Both inside the {} and after the final } a semi-colon is only required if there is another discrete expression within the overall code:

if($Name.contains("red")){$Color="bright red";$NameStrike=true}

if($Name.contains("red")){$Color="bright red"};$Pattern="diagonal"

[edit: fixed error in code example]

I posted my reply above without seeing your lengthy reply that preceded it. That long reply is very very useful to me. Thanks.

Also, in the online tutorial I noticed use of $Name.icontains() and I've been using that. I see you used Name.contains(). So apparently the dollar sign is no longer needed, and for some reason there was an 'i' in there that is no longer needed.

Oops single typos and 2 resulting copy/paste errors now fixed. OK, for clarity, Name.contains() or similar will likely work, but for legacy support reasons. Put another way, it's best no to start out learning syntax that may stop being supported - and I apologising for inadvertently contributing to the confusion.

Early in TB's existence, action code was much, much smaller in the scope of what it could do. You could write code like:

Color = bright red

TB would guess you meant the attribute Color should be set to the string value   'bright red', by cutting up the expression, checking the bit left of the operator matches a currently defined attribute, etc. Easy for the user to just write what they mean … except with more complexity the method doesn't scale well. So now, we'd write:

$Color = "bright red"

Now TB immediately knows we're setting the value of an attribute to a string value - it doesn't have to work out if the value is "red", "bright" or "bright red", it uses the provided quotes. However, there are plenty of users out there with old docs that don't want to update (nor know how to) so the old code is supported. That's why I list it as 'deprecated' in aTbRef. It may work, but it's not best practice to do so.

Also, as action code gets more complex, 'rules' make learning easier - you quickly spotted my earlier typo of omitting a $, using 'Name' not '$Name'.

So … it's complicated! But I hope that's helped give some background.

Meanwhile, with .contains() and .icontains() use the latter if you absolutely want a case-insensitive match and wend to override any lurking case-sensitivity switches.