Interaction between notes added to a container and adornments in that container


(George Wyner) #1

Looking for advice on how to make my combination of agents and adornments less glitchy. (The glitches clearly being due to my strategy, not TBX itself).

I have some agents that at key moments move notes from one container to another. Basic scenario: I have tasks that get placed in a container for snoozing tasks (the “naproom”) and, at a set time, get moved (by an agent) into an active project container. This is done by changing the $Container attribute of the note. In this project container I have added some adornments with Actions to set various attributes. This allows me to update notes by dragging them onto various adornments.

Overall the system is working really well, but I have noticed that when notes arrive in the project container (courtesy of the “unsnoozing” agent) they sometimes land on one of the adornments. In many cases the change made by the adornment can cause the note to whisk off somewhere else, so I do not necessarily discover the inadvertent attribute changes.

I have tried to address this by moving these adornments away from where the notes seem to arrive, but wondering if anyone had advice on how to completely prevent this issue. That is, I want to make sure that when notes get added to the container they do not land on one of these adornments.

Thanks for any thoughts!


(Paul Walters) #2

Maybe fiddle with your agent setting $Xpos or $Ypos, or both, to avoid the region of the adornment.


(George Wyner) #3

Just a follow up to this suggestion. I added an OnAdd action to set Xpos and Ypos to land in a target area (marked with an adornment for visibility) and it seems to work well so far. Multiple notes land on each other but do not form a composite, which is good. other rules then pull the notes off the landing area to other locations. The only issue I have, which is minor, is that when creating a new note, it will always appear in that area as well initially. not a big deal for me, but thinking I could have the rule that sets Xpos and Ypos use an if to run only if $Name is not “untitled” - thanks for this suggestion!


(eastgate) #4

I’ve added an issue to see whether setting $Container can be smarter about accidental collisions.


(Paul Walters) #5

Rather than have the OnAdd action do the setting of Xpos / Ypos, I would make the agent that you mentioned in your first post do that. Be sure to have the agent action set Xpos / Ypos before you change $Container otherwise the note will zip off to the other place without being told first where to go.


(George Wyner) #6

What are the advantages of moving to agent?


(Paul Walters) #7

The OnAdd action is going to apply to any note you add to the container. That’s why why when you create a new note in the container that note gets sent over to the adornment.

The reason for moving the code that sets Xpos and Ypos into the agent that is also setting $Container is the same as saying “When my agent finds notes that satisfy my query, I want to move this note to the location of my target adornment that resides in my destination container”. Setting location (i.e., Xpos / Ypos) is an action you only need to do once to this note. It’s not something you need to do to every note added to the container – just some notes. The ones the agent finds.

Generally, when using action code it’s always a good idea to think about "when do I need to have Tinderbox follow these instructions?

  • Every time an agent (or a query in AB) locates a note, but at no other time?
  • Every time I add a note to a container, but otherwise never?
  • Sometimes – like when I apply a stamp to a note?

Parsimony is a good rule of thumb – don’t execute action code when you don’t need to.