Please confirm: removeRepeatingRow() function does not fire the on("remove:repeating_...", function) event

I've been depending on any row removal, including via the removeRepeatingRow() function, to trigger the "remove:repeating_foo" event.  It is becoming increasingly apparent that this function does not, in fact, trigger the event.  Can someone please confirm or discuss? N.B. I did a search before posting, and found a two-year-old post with this exact question (Bob O., I believe).  Nobody answered him.  I'm hoping to hear from someone this time.

I'm not familiar with the repeating section sheetworkers, but maybe it's worth to try out the existing sheets that use it, and see if any of them work, and why: <a href="https://github.com/Roll20/roll20-character-sheets/search?q=removeRepeatingRow" rel="nofollow">https://github.com/Roll20/roll20-character-sheets/search?q=removeRepeatingRow</a>

Thanks, Andreas.&nbsp; Just to be clear, the removeRepeatingRow() function works (it removes rows), and the remove:repeating_foo event also works (when someone clicks Modify -&gt; Trash , and the row is deleted, this event fires and can be used to cause a sheet worker to run).&nbsp; The problem is that one would expect them to be connected ; i.e. calling the&nbsp; removeRepeatingRow() function should be another action (besides Modify -&gt; Trash ) that causes the&nbsp; remove:repeating_foo event to fire, and apparently it does not. I'm afraid to assume that this will always be how this works - if I write my own row-removal-cleanup stuff into code that calls removeRepeatingRow() , and later someone at Roll20 decides that this was a bug and fixes things so that the remove:repeating_foo event does fire, my code will be broken.&nbsp; So I guess what I'm looking for is confirmation that this isn't a bug, and that it won't be changed.&nbsp; Or for it to be changed now.&nbsp; I don't care, I'd just like to know which way to write my code.

I dont know whether it's a bug. I know that API scripts by default don't trigger events, and that's a feature (an often irritating feature), not a bug. This may be the same. The way I'd handle this: whatever code you have in the remove:repeating_foo event, copy it out to a function called "removal_triggered (or whatever), and then in the remove:repeating_foe put removal_triggered(); Then wherevenr you have removeRepeatingRow, add a call to the removal_triggered function after it. This way, you have the same code being triggered in both situations. removeRepeatingRow isn't an asynchronous function, so there are no complications caused by doing this.

Your suggestion has merit.&nbsp; Aside from the fact that I might need several removal_triggered() functions (for the various repeating section situations), the only problem I can see is the possibility that removal_triggered() might get called twice by the same action, if removeRepeatingRow() triggers the remove:repeating_foo event someday.&nbsp; Well, I'll give the idea some thought - thanks!