I’m working on something where I’d like to have a live count of notes sitting on adornments. (Something equivalent to $ChildCount.) I’ve read through the attribute lists and consulted TbRef but can’t find an attribute that holds that info.
Is there such an attribute?
Thanks
There isn’t such an attribute, but you can calculate this fairly easily.
Let’s suppose we want to have a dashboard note that tells us how many notes lie atop the adornment /counter. So we make a new note and let it use the built-in prototype Dashboard. We’ll call that note count.
So, what notes are on the counter? Our dashboard note can use a rule to find them:
Rule: $MyList=find( inside(/counter) )
This makes a list of all the notes that are insider the top-level adornment “counter”. We’re not interested in reading the whole list; we just want the count. So that’s step 2.
Rule: $MyList=find( inside(/counter) ); $Subtitle=$MyList.count
And we’re done.
As you might want to do something to the assembled notes on the adornment, the two-step process might be preferable as you can use $MyList to iterate over the notes currently on the adornment. However, once the structure of the above $Rule is clear to you, it also works nicely when condensed into this one-liner rule:
$Subtitle=find(inside(/counter)).count;
Thank you. Both examples make good sense.
The part that I didn’t know and seems like the most important element of the solution is the “.count” suffix. I’ve seen other examples of these dot-expressions in forum responses here, but what is that kind of thing called? I’d like to know what to look for in “help” etc.
And thanks again.
ps–as an aside, I was looking to add the count to the display expression of the adornment. The idea of having a dashboard that monitors the count will work better though: it’s less complicated and mobile/alias-able.
I believe that the technical term for these is “dot operators.” Unsurprisingly, Mark A has a master list of them in his aTbRef, here.
There’s quite a surprising range of them.
Just a quick word of warning: this count will include all aliases of notes on the adornment, even if those aliases are not on the adornment, as you can see from this rather contrived example:
Less contrived examples occur whenever an agent matches a note on the adornment. To prevent this, you may want to use this query instead:
$Subtitle=find(inside(/Counter)&!IsAlias).count
Unfortunately this means it won’t include aliases that actually are on the adornment.
I have been unable to find a comprehensive solution to this issue. I just make sure I don’t use aliases on the adornments that I use in this way. In practice I have not found this to be a significant obstacle.
inside() does have an odd behaviour in relation to other enclosure query terms like descendedFrom() when it comes to aliases. I tried your test and extended it a bit including trying it in a non-root container. Same problem. But there is a fix. The over-count is other instances within the same container/map of notes on the adornment (whether original or alias). find() returns a list of paths. So we can do:
$Subtitle=find(inside(/Test/Counter)).unique.count;
The odd behaviour of inside() is that it returns paths of all instances (originals and aliases) from anywhere of a note what has an instance inside the stated container.
So, if we add another alias of Note 1 and stick it elsewhere in the document, there is now an over-count of one as .unique is acting on this list:
/Note 1
/Test/Note 1
/Test/Note 1
/Test/Note 1
/Test/Note 2
Got to head to a mtg, but I guess the next step is this which looks - from a quick test - to work:
$Subtitle=collect(find(inside(/Test/Counter),$Name).unique.count;
Of course you could have two original notes called ‘Note 1’ on the same map in which case the count would be off at it would remain at 2. It’s a pain there isn’t a version of inside() that actually works as the word implies! (It’s been a regular feature suggestion).
To follow up my last post, I think the issue is that whilst in an agent query the de-duping aspect reduces the number of results, in find() it fails in the manner shown above by finding the wrong number of items. The aliases of ‘Note 1’ and ‘Note 2’ are not inside (on top of) the adornment; instances of matches elsewhere in the doc are irrelevant. This logic mismatch is what I mean by “a version of inside() that actually works as the word implies”.
I’m not suggesrting inside() itself changes as there will be active docs that would break functionally if that occurred. But an trulyInside() function that returns a single instance of items genuinely inside the specified container would be a useful adjunct.
Agreed. It’s less of an issue with proper containers, where you can use $Container=="/path/to/container/" instead of an inside query, but for adornments this strikes me as essential functionality.