Make an action run only once as soon as I apply a prototype to a note

Agents, Actions and Automation
1

Dear Tinderbox users,

I often work inside a “Quotes” container and create notes that contain excerpts of sources (“Quotes” notes). Then, inside the same “Quotes” container, I may add new notes in which I comment on the “Quotes” notes, link the new notes to the relevant “Quotes” notes, and change the prototype of the new notes from “none” to “Thoughts”. The $Thoughts prototype has a rule that moves “Thoughts” notes to the right container — the “Thoughts” container. I have a similar rule for each prototype, such that if a note is created inside the “wrong” container, as it often happens for practical reasons, once the right prototype is applied to the note, the note is moved to the right container. I don’t mind that linked notes are in different containers because of the wonderful hyperbolic view, which cuts across containers.

The system works, but it’s unnecessary for the rule I created to run all the time on all the notes: after all, the action only needs to run once on each note that is created in the “wrong” container. I know I could create stamps to move a note to the right container, but if possible I would really like to have a note move automatically to the right container as soon as I apply a prototype. Therefore, I was wondering whether there is a way to make an action run only once as soon as I apply a prototype to a note. I am trying to keep the size of the document as small as possible and with the smallest possible number of Agents, Rules, and Edicts running.

If it helps, here is the rule I currently have in the $Thoughts prototype:

if ($Prototype=="Thoughts") {$Container="/Content/Thoughts";}

As mentioned, I have a similar rule for each prototype.

Thank you for your consideration.

Best regards,
Enrico

1 Like
2

Yup, there sure is. :slight_smile:

Try this:

if{$Checked=false}
   If($Prototype=="Thoughts"){$Container="/Content/Thoughts";};
   $Checked=true;
   $RuleDisabled=true;
};
if($Checked==false){RuleDisabled=false;};

This will only move the notes when checked is false. Once the notes are moved it will turn checked to true and disable the running of the rule for the note.

If you manually uncheck the check, it will run the rule again.

You’ll want to make it $EdictDisabled=...etc. if you’re using an Edict and not a Rule.

Note: I use this quite a bit in my project management file: Tinderbox Training Video 26 - Daily Journal Time Tracking Project Management Part 1 - #27 by TomD.

1 Like
3

Thank you for the prompt reply, Michael! It works — though, for anyone else interested, the code is:

if{$Checked=false}

   {if($Prototype=="Thoughts"){$Container="/Content/Thoughts";};

   $Checked=true;

   $RuleDisabled=true;

};

if($Checked==false){$RuleDisabled=false;};

The one thing I do not understand is why that Rule has to be disabled (“Enable” checkbox ticked off in the Rule tab of the Action Inspector) for it to work. I think I will really have to watch your video to understand the logic! In the meantime, thank you very much for solving my problem!

Best regards,
Enrico

4

Just a thought (ahem)…

AIUI all you want to do is make sure that every note with the $Prototype “Thoughts” ends up in a specified container with the minimum of processing.

Michael’s approach obviously works, but I’m wondering why we need to bring in $Checked when we already have the defining attributes to search on? i.e. We know that the rule only needs to check whether the note is a) a Prototype and b) not already in the Thoughts container.

So, wouldn’t

if ($Prototype == "Thoughts" & $Container!="/Content/Thoughts")
{$Container="/Content/Thoughts";};

do the same thing, and only require one if statement, rather than a pair of nested ones? Are Booleans intrinsically so much more efficient that the gain is still worthwhile, especially in the context of a rule which is designed only to run once?

Secondly, I may be misunderstanding the code supplied. When does the final statement (if($Checked==false){$RuleDisabled=false;};) ever get triggered?

i.e. If you invoke the whole rule when $Checked==false, then the first if($Checked==false) statement will already have turned it to true before you ever get to this second if($Checked....

So, by the time you get to the last line, $Checked will never be false, and $RuleDisabled=false will never run, will it? Apologies if I’m missing something obvious!

A final point, rather than complicate the note’s rule with switching RuleDisabled on and off, can’t you simply add it to the $OnAdd action of the /Contents/Thoughts container? Then you can have a sister action $RuleDisabled=false in the $OnRemove pane, so that if the note is ever accidentally moved out of that container, the rule will be invoked to move it back in again?

Again, apologies if I’ve missed something here — I’m just trying to think my way around the problem as an exercise to understand what’s going on!

5

Thank you very much, David, for the suggestion! Michael’s solution forced me to read about the $Checked and $RuleDisabled Attributes, of which I was unaware, so I am very grateful for his suggestion; however, I find particularly attractive the simplicity of your solution — which has the added value of moving back a note to the container specified by the rule should I inadvertently move the note out of the container. So thank you both very much for your time and energy!

Best regards,
Enrico

6

@brookter I agree that your rules seem simpler.

Another technique for one-time rules is: let the rule conclude by deleting itself

.....do things.....;$Rule="";

or, alternatively, set the rule to a different rule:

....do things.....;$Rule=$Text(/config/another/Rule)
1 Like
7

Oh, nice idea. I like that. :slight_smile: There are so many ways to accomplish your goals in Tinderbox!!!

8

Thank you very much: with some effort I might have been able to imagine the second solution, but never the first one, so thank you very much for bringing it to my attention!

Best regards,
Enrico

2 Likes
9

No problem – it was interesting to try to understand what was going on and I learnt some things in doing so. E.g. Previously I’d vaguely thought that applying a prototype triggers the $OnAdd statement (which would have been the obvious solution to your problem), but it doesn’t…

l also like Mark’s self-deleting rule technique… I wouldn’t have thought of that, I think.

1 Like