Automate $AgentPriority for smart adornments

Agents, Actions and Automation
1

I have a less used agent with smart adornments in the map view. I use stamps to manually turn the agent on and off (via $AgentPriority) per needs basis. I don’t need the smart adornments to run when the agent is turned off because the agent stops collecting new notes so the smart adornments processes are not required.

So my question is, when the agent is turned off ($AgentPriority=“-1”), does the child smart adornment turns off too? If it doesn’t, is there a way to automate it to turn off together with the agent?

2

I’m 99% certain this can’t be done in the manner imagined (happy to be wrong!), but read on… So, why is this a problem? Because queries, including find() used in actions, by design intent cannot match adornments even if logically they should. I believe this is because adornments were/are considered primarily visible UI affordances and thus adjusted via the UI (e.g. the Inspector) rather than via code.

Taking that as a constraint, what can be done? I have verified that is you know the $Path or (unique) $Name of the adornment, action code can alter its attributes. Consider an adornment “Anna Dornment” in agent “Test Agent” at $Path /Test Agent/Anna Dornment. To set its $AgentPriority to ‘off’ from elsewhere in the document, e.g. the agent

$AgentPriority(/Test Agent/Anna Dornment) = -1;

Or, to use its parent agent’s priority:

$AgentPriority(/Test Agent/Anna Dornment) = $AgentPriority(parent);

We can safely use the parent designator here as any adornment is only on one map and thus a child of the parent container (in this case the agent).

This gives us a way out of the problem of not being able to query for adornments. WE could give the adornment this $Rule:

$AgentPriority=$AgentPriority(parent);

Now if the parent agent alters its priority all its child adornments will follow suit. The code could also be set in a prototype. Note, the rule us just a rule and can be inherited from any prototype, so the prototype used doesn’t itself have to be an adornment.

Rather than have 100s of extra rules you could consider using an $Edict instead. Then, to trigger edicts on demand simply use menu File ▸ Update Agents Now.

So, a solution of sorts! [tested in v9.7.2]

3

How about using a rule of the agent? $AgentPriority(adornments)=$AgentPriority;.

That’s one rule, rather than several.

1 Like
4

Dang, I’d overlooked the adornments designator. Sorry!

5

Ah the adornment designator. Designators are something I’m struggling to use.

I did not frame my question properly as the crux of my issue is reducing the number of background processes from a rapidly scaling document. Which is why I have a stamp to turn off agents whenever they are not in use and avoid $Rule or $Edict for one-off actions.

The adornment designator is the solution. Instead of putting it in $Edict of the agent, I added $AgentPriority(adornments)=$AgentPriority to my stamp.

Agent:On (Stamp)
$AgentPriority=“0”;
$Flags=“green”;
$LastUpdated=date(“today”);
$AgentPriority(adornments)=$AgentPriority;

Agent:Off (Stamp)
$AgentPriority=“-1”;
$Flags=“black”;
$LastUpdated=date(“today”);
$AgentPriority(adornments)=$AgentPriority;

Thanks for your help! Turns out the solution is simpler than expected.

1 Like
6

Good identification and extraction there. Rules are great for getting going and so most users. But some projects grow a lot of rules.

Then, as needed by individual users/project, the progression route is normally rule → edict → stamp. Stamp being ultimate control where the automation is the human user applying the stamp when needed.

For later readers, note the two designators adornment and adornments are subtly different from other singular/plural name pairs in designators:

  • adornment (singular) does the same for an adornment as agent does for an agent (q.v.).
  • adornments (plural) allows a container (note or agent) to address all adornments in its child map (but note, not all descendant maps)

See Designators for more detail.