Adornment name in attribute of note

I found a few topics on the forum to answer this question but I can’t get it to work…
I want to order notes on top of adornments to arrange them in a way which makes sense to me.
I would love to get an attribute of the note I place on an adornment to get the name of the adornment. When I take it of this should change, if I place it on top of another adornment, the attribute changes.

In addition (? sorry…) it would be great if the note also gets a unique attribute to keep it apart from other notes on the same adornment.

Soryy for the question, I should be able to figure this out but I have really tried but can’t get this to work consistently.


OK, thats easy, using the OnAdd action ($OnAdd) of the adornment. So, I have an adornment called “Red Things”, and here is is’t $OnAdd as seen in the Inspector:

No a test note ‘Test’ with a default empty $MyString value:

Place the note on top of the adorment, and $MyString is set:


Adornments, don’t sort:

But smart adornments (adornments with a query) can. So I’ve set—just to make the query work, the $MyString of note “Idea” to be “Red Things”. Now the adornment’s query:

$MyString=="Red Things"

and the adornment’s $Sort is set to “Name” (i.e. cort the matched notes via their title ($Name). We get:

OK, I make another adornment “Blue Things” with this OnAdd:


Now, I drag note “Test” across onto “Blue Things” and see the value of $MyString, which was “Red Things” is now “BlueThings”:

‘Keep apart’? How would that work. If you use a smart adornment, the adornment controls where things are placed. In an ordinary adornment, placement is manual, i.e. where you place it.

You can have Adornment grids but note these are manual. the ‘grid’ is drawn onto the adornment and creates rectangular areas within the adornment (which may also have labels. BUT, placement on the grid is manual. You can’t use an agent to place different (query-matching) notes on different parts of the grid.

If I’ve misunderstood, please can you give us a little more detail of the task and why you need to do things this way. The latter is asked in case there is a solution but using a different method.

1 Like

Hi Marc,

Top, Thx! Works! I had it almost right, I forgot the semi-colon and perhaps that was the reason it did not work.

What I meant with the “unique attribute” was that if I search or use agents to find notes, I want to have a way to see where the original note is. I tried to solve this by creating a new attribute which is a combination of the higher and lower locations of this note. I have now put this as an agent in the prototype of the note-type as $Location=$Course+" - “+$Chapter+” - "+$Subtopic. This works “sometimes” for existing notes. Is there a way to “force” this for all existing notes?



1 Like

As an agent in the prototype? Do you mean the OnAdd action, as notes can’t have (agent) queries? If so, it would explain (some) things. An OnAdd is run once when a note is moved into a container (i.e. becomes a child or a new c hold note is created. Any child note existing before the prototype’s ONAdd code was added can’t trigger the action as it is already a child.

Does that help? If not, can you expand a bit on the context of the sometimes. For instance, I added 6 notes to the container but only 5 got a $Location value, the other was blank", etc.

Hi Marc,
Sorry! I meant “as an action in the prototype (which is used for all notes)” (see below)
Is this action run on a regular basis so that the substitution is also performed on all existing notes? Or do I need to do something to get this in all existing notes?

1 Like

Thanks for the clarification. Yes, you have populated the prototype’s OnAdd action ($OnAdd).

So, for any new child note of a note using that prototype or any note dragging under that note (i.e. making it a child), the OnAdd with run once and once only.

So the apparent failures are likely the children already existing. A temptation is to move the OnAdd code to an Edict or Rule. You could, but stop to think. You only need to set $Location once. Plus, I’m guessing most (child) notes don’t move much (I may be wrong!). so, you real problem is to find all notes that should have a $Location value but don’t, then set those notes’ $Location once.

The answer is an agent. The query needs to find all notes whose parent’s prototype is of [name] (I don’t know that so we’ll call it “X”) AND for which there is no $Location value. For those notes we then set the $Location, which then causes the note to no longer match the query—a self-emptying agent.

The agent’s query:

$Prototype(parent(original))=="X" & $Location==""

Agent action:

$Location=$Course+" - "+$Chapter+" - "+$Subtopic;

Now make the agent and let it run. It should initially add a lot of aliases which then disappear as all the notes that need a $Location value now have only. Once that has happened you can delete the agent as any new notes added to the document will trigger the prototype’s OnAdd.

In the query, why $Prototype(parent(original))? Well, the parent of a note and the parent of any of it’s aliases differ. By saying parent(original) we are being explicit that we want the parent of the note, or if testing an alias, the parent of the alias’ original note. It might not be needed here but as i’m working without a test file it’s a little harmless overkill and gives us another free action lesson!

Semicolons in code
Agents. Agent queries never need a semi-colon at the end and should not be given one, though Tinderbox is clever enough to ignore them if you do.

Actions (e.g. OnAdd). These only require a closing semicolon if there is more than one expression (complete action) as the semicolon tells the Tinderbox code parser, "action #1 ends here, run this code then come back for action #2, etc.).


$Color = "blue";
$Color = "blue"


$Color = "blue";$Badge="ok";
$Color = "blue";$Badge="ok"

Note that the ending semicolon is optional, but in the second case with 2 actions the semicolon must be added between the two actions.