I’m currently living in the outliner, and working with a specific prototype for all the notes in it. I want to be able to press return, ⌘], then enter a title, and the note that is the parent of the note I’ve just created sets that child to have a specific (or inherited) prototype.
I’m kinda stumped about how to do this. Any suggestions? I’ve been looking for anything in the Action Inspector, but can’t figure out the best way to make code run when a child is added.
Also, once you’ve set up the parent’s $OnAdd as per-Eastgate’s solution above, you can also easily apply the prototype to existing child notes without the prototype. Simple select those needing the prototype, and then press Shift+Tab (promote as sibling) and Tab (demote as child). The second task causes the new $OnOdd to fire and the notes end up back where they were with the new prototype set.
Or, select all the notes without the prototype, right-click on the note icon (left end of any row) of any item in the selection and select the desired prototype from the pop-up. This might be a better method if you have a specific sibling order for the notes that can’t be (re-)created by sorting. the above promote/demote method will add the notes back at the end of the list of children, i.e. last by sibling order.
The selected item is an agent. This tab is the agent action ($AgentAction).
The selected item is an adornment. This tab is the on add action ($OnAdd), even though items are ‘on’ and not ‘in’ the adornment.
The selected item is neither of the above. This tab is the on add action ($OnAdd). Even a note with no children can have code here as a note becomes a container by the mere act of having other notes/agents nested within it.
In fact if there were one title for all three contexts , ‘Add’ (i.e.(On)Add vs. (on)Remove)might make more sense. In principle every cycle, the agent starts over and build an alias for each matching note. As the aliases are added into the agent it is like making a child and thus firing the OnAdd. Thus whilst $OnAdd and $AgentAction are stored separately yet do a similar thing, they can’t occur in the same context so there is no conflict. The adornment is the odd one odd and neatly illustrates the duality. For a normal adornment manually moving a note on top of an adornment fires the adornment’s OnAdd. If the adornment has a query, the movement of the note on/off the adornment is controlled by the $AgentQuery and the OnAdd takes on the role of the agent’s $AgentAction. Thus it is the agent that is the exception here.
For completeness, I’d note that for performance reasons the agent doesn’t actually re-create every alias every cycle. Rather it discards an no-longer matching aliases and makes new aliases for new ones. Those still matching are left in place but the agent action is still run on them, i.e. as if they were hitting the ‘on add’ context of a new aliases being added.
Anyway, the labelling is as it is, but I hope the above de-mystifies things a bit. Think of the Inspector tab’s label as ‘AgentAction/OnAdd’.