multitimer: allow one-shot alarms (delete after)

[bobrippling]

@frigis1 would you be happy with a "one shot" addition to multitimer? This lets a user set a timer or alarm to delete itself, once it's sounded

[gfwilliams]

Looks good to me... @frigis1 ?

[bobrippling]

I might adjust this to call the variable del, to match the alarms app - in fact it looks like multitimer's perhaps a little older than alarm app's sched.js - I'll update mulittimers and expand the .del functionality to alarms (as well as timers)

[bobrippling]

I'll update multitimers and expand the .del functionality to alarms (as well as timers)

That's been done, I'll test this for a little while.

I'm also considering instead using hooks (Bangle.emit()) in sched to fire multitimer events, rather than copying sched.js

[gfwilliams]

So just to be clear, by copying sched.js you mean the showAlarm function?

Why exactly did it need to be copied, rather than just having sched's default handler used? Since you can specify custom JS to run for the alarm handler, is it possible that whatever custom JS was needed could be put in there?

[bobrippling]

Yes, exactly - the two parts are hard mode and resetting the timer, the latter being possible via a custom handler, the former I'm not certain (going to look into it)

[bobrippling]

I suspect this will do the trick, but need to give it a good test first

[bobrippling]

This is good to go now - thanks for your patience!

• Delete after sounding
• Hardmode

[gfwilliams]

I'm just looking at this, and as far as I can tell, the idea is that for hard mode, you're trying to get multitimer.ext.js to be called before the rest of showAlarm?

Before this PR, we just set js in alarm to load('multitimer.alarm.js'), which feels like it has basically the same effect.

Can we not just do the same, and then when you want to show the alarm from multitimer.alarm.js, rather than duplicating code we just do load('sched.js')?

Or am I missing something?

[bobrippling]

Yes, that might be a simpler solution in fact. The original multitimer code modified the buzz count, but we could just buzz n-1 times in multitimer.alarm.js before then loading sched.js, like you suggested.

[gfwilliams]

Cool, thanks! That would be great.

Sorry about that - I'm just a bit anxious about bits tacked onto the scheduler if we can do without them. It's a bit hard to see triggercheck being useful for that much other stuff.

I did notice your if (alarmIndex >= 0) alarms.splice(alarmIndex, 1); - was that because you actually hit a case where alarmIndex was less than zero?

[bobrippling]

That makes sense, not a problem. The alarmIndex guard was safe in fact (never triggered), I'll drop that out

[bobrippling]

Just needs a re-test

• Delete after sounding
• Hardmode

All good now

[gfwilliams]

Thanks!