Can I safely detect if a clone/sprite has been deleted?

There is a race condition in the timer blocks I published a while back: if the timer expires, the clone the timer was running in deletes itself after sending a message. However, the cancel block depends on telling the sprite to stop the timer, and if the sprite is deleted the cancel block fails with "Inside: Error cannot operate on deleted sprite", stopping the block it's embedded in.
I could rewrite this, but it seems like a useful thing to be able to detect without failure.

You could have all the cancelling done by the Stage?

Not sure I understand how that would work. The broken design tells the sprite to set a variable that then causes it to delete itself. Even if i 'tell [sprite] [delete this clone]' it still fails if the sprite has expired and deleted itself.
I've already rewritten the timer to have a separate 'create' function that returns a timer clone that doesn't delete itself on cancel or expiration. Now the creator is explicitly responsible for the timer lifetime. This should be robust at the cost of a little more bookkeeping

we would understand the problem better if you shared the project (well, at least I would)

Look at the startTimer and cancelTimer Sensing blocks in this project: https://snap.berkeley.edu/project?user=lowclouds&project=messaging
This shows the problem.

Try https://snap.berkeley.edu/snap/snap.html#present:Username=donotforgetmycode_snap&ProjectName=sprite%20is%20deleted

Oh! Does the forum have a maximum username length?

Edit: Not so good for the forum and Snap! to disagree about this, or we'll eventually have two users with the same forum name.

Yep
Also lots of characters change to _ in the forum.

and it appears that caps are replaced with lowercase letters

That didn't seem to work for me, but this does:

Hi @lowclouds,
Or just...
clonCheck

Joan

Joan @jguille2,
That wouldn't work because the sprite calling cancelTimer isn't the parent of the Timer clones, but maybe using "my [clones]" is better in the ask block

Yes @lowclouds, you are right!

I tested your project, just inside the Timer sprite. And then, that clone was really a child of it.
But I don't see you used "a new clone of (Timer)". And then, your "asking" solution is the right. (Aside this, I posted without having seen your last post). You can ask for children or for clones.

Joan

:thinking:,Why did you use flat view?

I didn't make a choice, it is what it is. Is flat view what you get when you check 'Flat design' on the wheel menu? If so, it's not set

I replyed to jqulle.

Hi,
Yes, I always use flat design (more for the white than for the flat).
I'm a Catalan teacher and here, I think here most of us use it. I don't know if partly because of us (our presentations, videos, classroom materials...)

Why? I'm not sure. At the beginning (with our first steps in Snap! at the end of 2015), our students (and also teachers) were working with Scratch2, and also with other Blockly soft (Blockly for Picaxe, Arduinoblocks, Appinventor...).
I think this is the reason we begin to switch always to flat design. It seemed more comfortable for our students. We are focused on 10-18 years old children, and we are working with a non-specialized perspective (CS for all).

That's all.
Joan