Why is $DisplayedAttributes a list type attribute and not a set type?

I just stumbled across something strange and would like to understand the following decision and how I can prevent the related outcome: why is $DisplayedAttributes a list type?

When I take notes on a source/reference I do that in map view inside the reference container related to a particular source. I put a simple OnAdd-action-code to my Reference prototype that sets the displayed attributes of any child note to “Pages” and “CitationKey” (it also copies the $BibTexKey to $CitationKey as I am dealing with literature notes in that case).


I just duplicated a literature note and suddenly had two sets of the same attributes displayed in the note and that makes total sense because $DisplayedAttributes itself is not a set type but a list type and hence adds duplicates. Yet, it intervenes with my simple approach and as it is a system attribute there is no way to change that.

Is there a particular reason for that? And how could I circumvent the duplication of already displayed attributes when I want to duplicate a note inside a Reference container? I’d like to keep the “add displayed attributes to already existing displayed attributes” because I would like to have the opportunity to be able to drag in other notes – that might already have other attributes displayed qua prototype or manual edit – as well (just in case).

As you know, sets are free to order themselves as they like, while lists preserve the order you choose.

At one time, in fact. $DisplayedAttributes was a set! This makes actions like you’re easy, but it means you can’t decide that (say) $Price should be the top attribute, and $Address should be the bottom attribute.

You can use .contains() to get the effect you want:

if(!$DisplayedAttributes.contains("Pages")){ $DisplayedAttributes = $DisplayedAttributes+"Pages"} 

That’s a little more work, but not too terrible.

If you yourself don’t care about the order in which the displayed attributes appear, it’s easy to remove duplicates:

1 Like

Or, if using v9.5.0+, without using sets we can do this with lists:

$MyOutputList = $MyList.unique;

This de-dupes $MyList, retaining order but weeding any dupes as it goes, i.e. only the first-occurring item, by source list order, is retained. The output can be the source list:

$MyList = $MyList.unique;

So of course for Displayed Attributes we can thus use the following once any new items (and thus possible dupes are are added:

$DisplayedAttributes = $DisplayedAttributes.unique();

So your OnAdd could be like this (tested in v9.7.3):


Edit follows

Forgot to add link to documentation of List.unique(). :slight_smile:

1 Like

Incredible. Thank you both for the helpful replies! @eastgate also thank you for the explanation, that makes totally sense to preserve the order of the items.

1 Like