Changing alias name without changing original note name

Is there a way to change the displayed name of an alias note inside of an agent without changing the original note’s name? My agent is collecting notes that are buried in a hierarchy, and it would be useful for them to have the name of their grandparent (but only in the agent). I’ve tried this with the following code in the AgentAction:

$Name=$Name(grandparent(original));

But that changes the $Name of the original note. If $Name is an intrinsic attribute (based on this list from atbref), then shouldn’t any changes made to an alias by an agent apply only to the alias? Does an agent create aliases but apply its AgentAction to the original note rather than the alias?

An agent action applies to the alias in the agent, which is why you need to use the ‘original’ offset designator on intrinsic attributes.

$Name is listed as intrinsic because the app reports it as such in the Document Inspector, ‘System’ tab.

You’d do better to use a user attribute to store the custom value you want and then display as a column in column view.

$Name isn’t behaving as intrinsic, and I don’t believe it ever did.

A method that works for me is to set up $DisplayExpression for the original, which will be inherited by that note’s aliases, and then set $DisplayExpressionDisabled to TRUE for the original and FALSE for the alias(es).

2 Likes

$Name is an anomalous attribute; it is not inherited from Prototypes, but it is passed to aliases.

So should it be marked in the Inspector as ‘intrinsic’ if it doesn’t exhibit the expected behaviour of such an attribute? That’s not to be judgmental but I’m simply thinking from the standpoint of giving (unintentionally) misleading info via the UI (in the Inspector).

I assume it’s treated as intrinsic because it’s not inherited from the prototype? If so, as a one-off it’s an outlier and even if necessarily flagged as intrinsic in the XML, I’d suggest it isn’t marked up as such in the Inspector. If nowhere else, the aTbRef section on the XML used in TBX files can annotate the apparent discrepancy as I suspect that’s the only place the difference need surface.

There does seem to be one possible solution to @jafish’s question, intrinsic status of $Name notwithstanding (I didn’t post this earlier as I’d not had time to test). Edit: this doesn’t disagree with @PaulWalters answer above (which I’d fforgotten when writing this answer), in fact it just builds on it.

The title you see on screen is actually $DisplayName, which is a read-only result of $DisplayExpression. If there is no display expression, then $DisplayName’s value is simply that of $Name. IOW, in most cases the on-screen title is $Name.

However, $DisplayExpression is an action code expression and that is evaluated in the context of the note or alias. This allows an original note and an alias to have a different $DisplayName. For instance, this trivial example I just did by way of a test, whereby the note and aliases:

The note “Thing” and its alias both have the same $DisplayExpression but, due to context, a different $DisplayName. The position of the alias in the container does not matter. In each case the note/alias shows its own contextual sibling count.

It is not recommended, for real use, to use lots of conditional code in lots of note display expressions (as it’s evaluated on-the-fly) but to extend the example above:

if($IsAlias==true){$Name+ ": "+$ChildCount(parent);}

…works as per the screen grab except that the original note would now not show its sibling count and the display label would just be the $Name; the alias would continue to show its sibling count. Or consider the effect of this display expression:

if($IsAlias==false){“No, I am Spartacus”;}

Because $IsAlias is false for the original note, its $DisplayName is the same as $Name. But, for all the aliases, they adopt the string in the display expression as their $DisplayName. You can also see a limitation here as all the aliases use the same ‘alternative’ title. You can also see, above, from the selected item—and alias—that the original and aliases are using the same $DisplayExpression code.

Anyway, that may give a few ideas as to how an alias might be named differently from its original note.

Notes:

  • I used sibling count as it is easily evaluated by eye in the screen grab to validate the code result. There is no ‘sibling count’ attribute but it is the same as the parent container’s $ChildCount
  • ($IsAlias==true)and ($IsAlias), or if($IsAlias==false) and if(!$IsAlias) are the same test. I use the long form above as it is more easily understood by those just starting out with Tinderbox action code.

Does this get to a different end point than what I suggested above?

No disagreement, and I’ve just added an edit note to my post to - hopefully - clarify that. The (your) idea is unusual enough for beginners that I thought it warranted a worked example.

Thanks, all. @PaulWalters’s suggestion of using $DisplayExpressionDisabled to control when the set $DisplayExpression was used, combined with @mwra’s suggestion of using columns (I forgot about that capability) got me exactly what I wanted.

What this allows me to do now is have child notes for each of my students indicating which weeks I’ll have consultations with them (Names are of the form “Week 3”). I use dates to schedule those consultations. Then, I have an agent that uses those dates to collect all the consultations for the current week. I wanted to avoid having a bunch of notes displaying “Week X” without the context of the parent (the student’s name). I could have just used a calendar, but I like that this is integrated into the place I take all my notes and do all my planning for my class. I’ve used Tinderbox for a long time but sometimes still get hung up on things, so I really appreciate the support!

1 Like

It remains that there are uses cases where allowing Agents to have Display Expressions that are different than that of their Original (without disabling Display Expressions) would be most welcome. Have I missed something since this discussion ended?