Adding a child note, and making the parent set the prototype on creation

Agents, Actions and Automation
1

This is more complex than I thought it would be.

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.

2
  1. Select the parent note.
  2. Open the Action pane of the Action Inspector.
  3. Enter the action you want, perhaps $Prototype="pTask";
  4. Press return.

Now, the parent will perform this action whenever a new child is added or created in the container.

Hint: Another way you can make a new child of the selected note is to select the parent and press shift ⇧-Return. That saves one keystroke…

image
image910×526 40 KB

1 Like
3

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.

1 Like
4

This is also called performing and on add operation; the Action Mark refers to above is stored in the $OnAdd Attribute.

here is a common $OnAdd I run:

$Prototype="pTask";if($Name=="untitled"){$Name="Tsk- "};

In other words, I have the on-add automatically give a prefix to the child.

With this process, you can call stamps and functions as well.

1 Like
5

Oh dear me. Thanks everyone; I was wildly confused by a tab labelled ‘Action’ being the same as an $OnAdd property. This helps clear it up quite a lot.

This is working very nicely for me now.

If I were to want to copy an attribute from the parent, would that be

if(Parent($OutlineNumberise) == true) {
   $OutlineNumberise = true; 
}

(I’m assuming not, because it’s not working for me, but it looks like it should be that…)

6

Yes, I hear you. We are talking about this Inspector:

746×984 64.5 KB

So:

  • 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’. :slight_smile:

1 Like
7

The right way to write this is:

if ($OutlineNumberise(parent)) {
    $OutlineNumbers=true;
    }

You might prefer the more concise:

$OutlineNumberise=$OutlineNumberise(parent);

The Actions and Dashboards tutorial in the Help menu might be helpful.

2 Likes