Firing the $OnRemove action when a note is deleted


(Galen Menzel) #1

Hi all,

I notice that the $OnRemove action of a container (or adornment) fires when a note in the container is dragged out, but not when a note in the container is deleted. I think I get why (namely because OnRemove actions have to run on a note, and the note to run it on has just been deleted), but it makes it annoyingly difficult to maintain state within a container without resorting to an agent.

For example, I have an expense prototype, and it would be great to be able to nest expenses so that the amount of the expense is the sum of the amount of its children. I could do this with an agent, of course, but it’s even simpler to do with OnAdd and OnRemove actions. However, this gets messed up if you delete a nested expense rather than moving it out of the container. Is there a nice way to do this, or do I just have to use an agent?

How feasible would it be to support firing OnRemove on the note to be deleted just before deleting it?

Thanks!


(Galen Menzel) #2

I should also mention that one of the reasons I would like this functionality is that I like to use “expense adornments” which set $DisplayExpression to the sum of the expenses within the adornments. Adornments cannot be queried by agents, and I have not been able to find a group note designator that designates all the notes in an adornment. Is there one?

Given that there are no group note designators that for adornments, and you can use agents to query adornments, and OnAdd and OnRemove have this fragility, is there any way to add this functionality to an adornment?

Thanks!


(Mark Anderson) #3

I’m not sure that remove and delete are the same intent, even if treating them thus solves the particular problem. IOW, if taken forward, I’d suggest ‘OnDelete’ being a separate event/attribute rather then be part of ‘OnRemove’. Otherwise you’d have to check and remove any $OnRemove before you could safely delete a note without firing unwanted code.

Sidenote: ‘OnCreate’ and ‘OnAdd’ are essentially the same thing albeit the only way to set a create event for root notes is to set the doc default for $OnAdd, though you could use an if (if($OutlineDepth==1){$Color="red"}).


(eastgate) #4
  1. To compute the current some of $Amount in a container of Expenses, define a rule on Expenses or use an agent.

  2. We’ll look into firing OnRemove before the note is deleted.

  3. To find all the notes atop an adornment: find(inside(/path/to/TheAdornment))


(Galen Menzel) #5

Hmm, my thought is that deleting is just another way to remove a note from a container, so it seems strange to separate them, though what you describe would be necessary to maintain the current behavior. Out of curiosity, can you think of an example when you wouldn’t want $OnRemove code to fire when deleting a note?


(Mark Anderson) #6

Yes but one results in firing the OnAdd of another container and one doesn’t. So, it all depends on context. If the in/out actions only ever affect the container’s values (counts, tag lists, etc.) then the two might be similar. However, one might use action where on containers’s OnRemove is balanced by an OnAdd action in the receiving container. Tinderbox is an open ended tool and it’s useful to consider if the result of fixing the problem at hand makes other things more difficult, e.g. someone having problems because deletions are firing a remove action when that’s not appropriate. Having separate Remove and Delete actions would fix your problem, just in a more flexible way.

In the meantime, here’s a workaround for your delete problem. Make yourself a discard container, e.g. at path ‘/bin’. Now make a stamp with the action:

$Container = "/bin";

Now, when you would delete an expense item, select it and use the stamp, which moves the note and thus fires OnRemove. Then, as often as necessary, select the bin container and delete the contents

Considerations in the design here:

  • Using a root-level disposal container moves the notes out of any other part of the general outline (except if you use a root level map) and thus likely out of scope of inside() or descendedFrom() queries.
  • The ‘bin’ has an OnAdd via which you might want to apply further cleaning actions. For instance, you might want the removed note to lose its prototype and to reset $Price as either might otherwise meet existing queries. Thus an $OnAdd code might be: $Prototype=;$Price=;

(Galen Menzel) #7

Hi Mark — thanks for the tip.

Do you have any idea why setting an adornment’s $HoverExpression to count(find(inside(/path/to/adornment))) would show the correct count of items in the adornment, but setting it to count(find(inside($Path))) would always show 0? I.e., hardcoding the path works, but using the $Path attribute doesn’t?

Thanks!


(Galen Menzel) #8

Thanks, Mark — this is also just nice for preventing accidental deletions. Unfortunately I feel it’s insufficient for the expenses example, because in a proper expense application there should be no way for the totals to be wrong, and there is still the possibility of the container or adornment’s total to get into a funky state, if I forget to use the “move to /bin” stamp, or simply delete an expense by accident. Looks like I’ll have to handle this with agents or rules to ensure consistency.


(eastgate) #9

inside() doesn’t allow another layer of indirection; it expects a designator but not an expression for its argument. This is a question of efficiency.

If this is the hover expression for the adornment, the designator that will be bound to the adornment. So that will take care of the issue.


(Galen Menzel) #10

Thanks to all for the responses here!

I ended up (correctly, I think) abandoning the $OnAdd and $OnRemove approach for my “expense adornments,” and using the following $Rule on the adornments instead:

$MyNumber=sum(find(inside(that)),$MyNumber);

This seems much less error prone, and is nice and simple.

In the course of coming up with this, I came across some strange behavior that strikes me as a bug, but I’ll post about that in another thread so as to not confuse matters further.

Thanks again!