How are actions parsed? I am trying to determine if it matters the order in which actions are added to the actions dialogue box in how they are applied to a note. For example I have created an action to 1. apply a particular prototype to a note then 2. Assign values to the user attributes applied to that note then 3. Assign a badge to that note and finally 4. move note to a new location based on the values added previously. Does that order make sense because most of the time it works but very occasionally one note is moved but neither the badge or some of the values applied.
How are actions parsed?
I’m not sure what you’re asking here.
If an action contains several statements, they are performed sequentially as they appear in the action.
If an action moves a note to a new container, note that the new container’s OnAdd action will be triggered, too. It will be applied at the point of the new container assignment.
Note, too, that agents might be triggered to run by the new container assignment. I think that, once an action begins to run, all its statements will be performed before any agent action. There may be exceptions.
Pushme-Pullyus arise when two agents (or, less often, two rules) each try to change the same value of a note’s attribute. This can make you believe you’re seeing impossible things.
Does that order make sense because most of the time it works but very occasionally one note is moved but neither the badge or some of the values applied.
There are hundreds and hundreds of tests on the action language, each of which runs many times a day. Assignment works. It’s been solid for ten, fifteen years.
To unpick this a bit:
For example This action code is four discrete statements, or expressions:
$Prototype="pProject";$Color="blue";$Badge="ok";$Container="/Projects/";
They can as easily be written on separate lines as it is a semi-colon and not a line break that indicates the end of a statement†:
$Prototype="pProject";
$Color="blue";
$Badge="ok";
$Container="/Projects/";
Whichever way you write the above it is read and executed the same way by Tinderbox, left-right/top/bottom. Thus, here—in order: a prototype is set, an attribute ‘Color’ has a new value set, a badge is set, lastlythe note is moved by giving it a new container, and the action is complete.
At the macro level, Tinderbox is constantly looping through all notes/agents/aliases in outline order and evaluating queries, rules, edicts, etc. Things like OnAdd or stamps run once when triggered or applied.
†. The last statement in the code example doesn’t need a terminating semi-colon as nothing follows it. However, for non-programmers its easier to always use one and not worry about optional omissions (and thus getting them wrong).