There should SERIOUSLY be a cancel button when a sprite asks you a question (

ask [] and wait

). It's really annoying.

I mean, next to the checkmark when answering a question, there should be an cancel button.

What use would it serve? Just leave the answer box blank.

Sonickyle wrote:

What use would it serve? Just leave the answer box blank.

What if you want to close the box? The user might not do that.

However, leaving it up to the user to close it isn't really any better…

But what would happen when you close the box?

As sonicklye said, what would happen? Would the script just stop? Thank wouldn't be very useful. Would it keep going? What would it do then? Would the answer string be blank or would it say something like “answer cancelled”? There are too many possibilities for what would happen. So sorry, no support.

LeDerpy123 wrote:

As sonicklye said, what would happen? Would the script just stop? Thank wouldn't be very useful. Would it keep going? What would it do then? Would the answer string be blank or would it say something like “answer cancelled”? There are too many possibilities for what would happen. So sorry, no support.

Also, you could just put a null answer.

[ v]

I think the main problem is that he only way to get rid of an “ask” is to stop the whole project (e.g. “stop all”).

I don't see how there could be any real difference between having a “cancel” button, and just clicking the tick button with nothing typed in - in the case of “cancel”, the only sensible way would be to have “answer” being blank. Anything else (except perhaps stopping the script, or adding a new boolean reporter [“answer cancelled”!], which seems unnecessary and cumbersome) would be a string that the user could also have typed as the answer (as mentioned, “answer cancelled”. say).

In terms of “cancel”, then, the user giving a blank answer seems to be what you want (i.e. clicking the tick with no text entered).

In terms of actually being able to programmatically remove the ask box (which I think would be useful), the quickest and least problematic solution I can think of would be to have another item in the “stop” block list that says something like “stop asking”. That would allow easy removal of the ask box under the appropriate conditions (e.g. the user clicked some other button-sprite to get back to a main menu), and, importantly, it wouldn't cause any changes to the behaviour of any existing scripts.

LeDerpy123 wrote:

As sonicklye said, what would happen? Would the script just stop? Thank wouldn't be very useful. Would it keep going? What would it do then? Would the answer string be blank or would it say something like “answer cancelled”? There are too many possibilities for what would happen. So sorry, no support.

+1

The ‘cancel’ would be useful if you have a time limit. For example you want the user to only answer the question in let's say 10 seconds. Then you would have when 10 seconds have passed, cancel ask. Then the user cannot answer anymore. I really need this in the project I'm working on now. Because I don't want the player to have an infinite amount of time to answer the question…

Edit: Lol, first post on the Scratch 2.0 site XD

Am I the only one here who agrees with you? There could be 2 uses:

• A cancel button while answering
  
• A cancel block. Here are a few ways it may look:
  

  cancel question // category=sensing

  ask [What's your name?] for (10) secs // category=sensing

  ask [What's your name?] // category=sensing

  The last one would make sense if the first one was created.
  

mariobros406 wrote:

Am I the only one here who agrees with you?
,,,

I think you're quite right in suggesting there needs to be some way to remove a question (i.e. an “ask” that's currently showing) - it was a pain to hack around the problem in this hangman project (via “stop all”, which is currently the only way to get rid of an ask box, and then “when timer” to make the project continue on again).

Personally, I would have expected “stop other scripts in this sprite” to remove ask boxes (that were showing from another script in that sprite) - but it doesn't, and making it do so would be a change in behaviour that might break some existing scripts (though I wonder how many…?)

I suggested above that having an extra “asking” menu item in the “stop” block menu might be a possibility (which wouldn't break any existing scripts). Adding something like a “cancel asking” block, as you suggest, might also be a way to do it (more obvious, because it's in the same section as the “ask” block).


However, I think the original poster was suggesting an actual cancel button on the box itself (at least, that's how it seemed?) I don't think there's any need for such a thing (clicking the tick, or hitting return, with a blank response, seems like the closest thing), and it's really unclear how that would be implemented in terms of the script knowing it had happened (as others have pointed out above).

Besides, adding a way to remove the ask box from a script (with “cancel asking”, for example), then it's easy enough to create a button yourself in the project somewhere that performs that functionality…

The“Stop all” is a problem but we can use event scripts. I maked a very simple program: https://scratch.mit.edu/projects/52408418/

Support for

stop asking :: sensing

I think it should be in the sensing category rather than part of the existing stop block, because that one is used to stop scripts and doesn't seem very related to this one. It would set

(answer)

to an empty string when it was triggered.

stickfire-test wrote:

Support for

stop asking :: sensing

I think it should be in the sensing category rather than part of the existing stop block, because that one is used to stop scripts and doesn't seem very related to this one. It would set

(answer)

to an empty string when it was triggered.

this.

stickfire-test wrote:

Support for

stop asking :: sensing

I think it should be in the sensing category rather than part of the existing stop block, because that one is used to stop scripts and doesn't seem very related to this one. It would set

(answer)

to an empty string when it was triggered.

^

stickfire-test wrote:

Support for

stop asking :: sensing

I think it should be in the sensing category rather than part of the existing stop block, because that one is used to stop scripts and doesn't seem very related to this one. It would set

(answer)

to an empty string when it was triggered.

Support. I think there should be one. When you close an answer window, if you've set it to add the answer to a list, it adds an empty space, and can cause errors. It would be much more convenient.

forever
    
if <(evil kumquats) > [0]> then
    
set [evil kumquats v] to [0]
patch eaten signatures
end

end

stickfire-test wrote:

Support for

stop asking :: sensing

I think it should be in the sensing category rather than part of the existing stop block, because that one is used to stop scripts and doesn't seem very related to this one. It would set

(answer)

to an empty string when it was triggered.

That.

Just to note that there's been a breakthrough in this particular issue…

I've been wrong all this time in thinking that the only way to remove an ask box was “stop all” - it turns out you can also do it by having it ask within a broadcast receiver script, and then resending the broadcast (but have it not do the ask on the second time).

Restarting the receiver script removes the ask prompt.
(Also when restarting “when this sprite clicked” and “when backdrop switches” scripts, though I think those are less generic than “when I receive”)

The basic procedure then looks like this: https://scratch.mit.edu/discuss/post/1593995/

Much less destructive than “stop all”!

stickfire-test wrote:

Support for

stop asking :: sensing

I think it should be in the sensing category rather than part of the existing stop block, because that one is used to stop scripts and doesn't seem very related to this one. It would set

(answer)

to an empty string when it was triggered.

The main question I would have about that is what happens to the script that was running the ask block? Does it get stopped? If not, how does it know the answer was cancelled? (Having answer blank is the same as someone typing nothing.)

Here's an alternative idea, where it does make it clear that it is stopping the script doing the asking:

stop [asking script v] :: control // should have tab at the bottom so you can append blocks

That would basically work in a very similar way to the broadcast method above, and there's no chance of confusion over the value of “answer” for blocks after the ask block (since they don't get run).

The main downside I see is that it's not near the ask block itself in the block palette, so it's not going to be obvious how to find it (and so how to stop asking) unless you already know about it. (Though I think once you see it, then it is clear what it does, right?)

Enter a null answer, no support

Also, I found a workaround here