I had a problem with children and adornments. Adornments know items inside() them are ‘on’ the adornment but those items aren’t AFICT detected as children†. Also an adornment might be a smart adornment so notes might come and go not just by the user moving them.
So, an adornment can an OnAdd and a lesser known/used OnRemove action. Moving a note onto the adornment fires OnAdd (code in $OnAdd & Action Inspector ‘Action’ sub-tab). Moving a note off the adornment fires OnRemove (code in $OnRemove & Action Inspector ‘Remove’ sub-tab). Actually, OnRemove doesn’t seem to work for a smart adornment‡. But for a ‘manual’ adornment we can do the following…
$OnAdd: $Total(adornment) = $Total(adornment)+$Price;
$OnRemove: $Total(adornment) = $Total(adornment)-$Price;
As a fallback in case things seem to be out of whack we can make a reset/re-calculate stamp:
Stamp ‘Reset count’: $Total = sum(find(inside(that)),$Price);
For instance if calling the adornment’s $Total in code you can, if cautious, first call a stamp. so if the adornment is called ‘Anna Dornment’, the code might include this:
...
stamp("Anna Dornment", "Reset count");
RunningTotal += $Total("Anna Dornment");
...
Here, using 10.2.0, is my test TBX: Of-totals.tbx (132.3 KB)
Things to try:
- drag notes onto or off the adornment, check the adornment’s $Total changes/
- run the stamp on the adornment: regardless of items or note, the $Total should be correct.
†. As the logic of what an adornment is does not allow for it to have children, it would be neat if an adornment evaluated a call for its children as inside(that).
‡. Testing in v10.2.0, smart adornment fire the OnAdd, but not the OnRemove. Whether this on oversight or intention (for agent performance tuning?) . I’m not sure, so pinging @eastgate: comment not sought here, we can pursue this on the Backstage if needed.