8to16 wrote:

May I suggest adding the

when (::obsolete) clicked :: events hat

workaround?

Of course, and the suggestion is appreciated! But a couple of people have suggested and discussed this before: here through here, and earlier back here. I don't think we ever actually replied directly, so we'll do that now…

The main part of this workaround guide excludes “when stop clicked” on purpose. It's not that the workarounds aren't creative uses of Scratch's blocks (which would normally totally fit this guide!). I also recognize that this is something that the Scratch programming language totally “allows”. Someone on the Scratch Team is probably aware and decided it didn't matter enough to find a way to make the workaround impossible.

However, the stop button isn't supposed to do stuff. It is rude and possibly scary if you make your project “refuse” to stop, because Scratchers expect the stop button to, you know, stop the project. Sometimes Scratchers stop a project because it turns out their computer's volume was up way too high, and they would be in trouble if stopping played more sound. Generally, if you take away the way that you're supposed to stop a project, people will feel startled and stuck!

It's not part of the workaround guide because we are worried that would give it a lot of exposure, to people who might not think about the consequences. It doesn't really fit the tone of the rest of the guide, either: this is pretty much the only “unsafe” block. A workaround that does work, ooo, but you should think before you use it, spooky!

But you might still have a good reason to use “when stop clicked”. Since anybody can use the workaround, it is up to you to decide if your reason is “good enough” to counter the concerns above. For example, animating in a silent and slow-moving splash screen 1) would not cause volume problems, and 2) probably would not cause visual (motion) problems either. Or you're making an arcade game and could ask if the player wants to submit their score to the leaderboard, even though they quit earlier than if they'd lost in-game.

If you feel that your own reason is good, then go for it—just think about it carefully!

We haven't carefully tested each of these workarounds to know which ones are most reliable. Sorry If someone wants to create projects demonstrating which workarounds work better and ideally why, we can fill in better details here. Until then, if one workaround doesn't quite work, just try another.

Method 1: always reset the timer, detect when it goes past zero (thanks, @1080GBA!)

when [timer v] > (0)
reset timer

when [timer v] > (0)
do something in response to stop being clicked :: grey

Method 2: reset the timer while running, detect when it goes past a small number (thanks, @k0d3rrr / Scratch wiki!)

when green flag clicked
forever
  reset timer
end

when [timer v] > (0.1)
do something in response to stop being clicked :: grey

Method 3: set a variable to the timer while running, detect when timer goes past that variable (thanks, @8to16!)

when green flag clicked
forever
  set [running timer v] to (timer)
end

when [timer v] > (running timer)
do something in response to stop being clicked :: grey

Method 4: detect when timer goes past a variable plus an offset (thanks, @-ErrorPurpl_157!)

when green flag clicked
forever
  set [ahead of timer v] to ((timer) + (1))
end

when [timer v] > (ahead of timer)
do something in response to stop being clicked :: grey