Scratch

[blocks]
        <key[ space ]pressed?>
[/blocks]

Fits as a condition in "if", "wait until".
When you keep pressing a key, this condition *is supposed* to return true all the time.

The correct way to use the combination of "wait until" and "Key [] pressed" is the following:

[blocks]
<wait until><key[ space ]pressed?>
<wait until><not> <key[ space ]pressed?> >>
[/blocks]

The program should only continue when the user presses the space key, and releases it (so it can be pressed again).

As you said, using "wait" is not the best solution (even if the user keeps pressing space, it will continue to the next step after x seconds)
Two "wait until"s are better...

Last edited by JSO (2008-10-27 15:53:18)

magdiego wrote:

I've always had trouble with the sensing block "key __ pressed" - it seems to work so quickly that if I press the key normally, the block senses it twice.
...

There are two keypress sensing blocks and they were meant for two different purposes.
With keypresses, there are two approaches of what is important to you:
1. You want to sense whether the key was pressed (that is, it went from "up" to "down" position; and, eventually, after a while, when you hold the key pressed, you want to be informed repeatedly that the key is pressed again and again. In other words, you want to treat keypresses as if you were typing.
2. You want to sense whether the key is down or up, no matter what position it was before, and always only get the "raw" answer - is it up or is it down? This is useless for typing unless you manage complicated timers for first press, the pause and subsequent presses, but it is useful in games.

Now, from your description, what you want is the first case, but you use block that is designed for the second case.
<when[ x ]key pressed> is the block that treats keypresses as in the first case.
<key[ x ]pressed?> is the block that treats keypresses as in the second case.

So, if I really got it right and you want to treat keypresses in "typing" fashion, not in "gaming" fashion, try to use the hat block, not the sensing block.

Somewhat exotic problem with sensing block is, given its nature, that if you press the key really quickly, you may even miss it (it is not down exactly at that moment when it is tested). Hat block has never that problem: one normal press and release means always one invocation.

If you need to use the keypress test inside loop, this is the solution (a bit awkward maybe, but working):
<when[ x ]key pressed>
<set{ x pressed }to( 1

before the loop use
<set{ x pressed }to( 0

and inside the loop
<if><( <{ x pressed }> <=> 1 )>
... do whatever you need ...
<set{ x pressed }to( 0
<end>

Last edited by deerel (2008-10-27 16:21:36)

JSO wrote:

Deerel - I agree, but I think using the Key Pressed Hat makes it more complicated in this case (controlling multiple steps)

This is an implementation of deerels scripts above.
...
And this is how I would do it:
I think it is easier.

http://resources.scratchr.org/adminAcce … tstep2.gif

This is as easy as yours, in fact it does not matter which method you use:
<when[ space ]key pressed>
<set{ spaceKey }to( 1

<when green flag clicked>
<set{ spaceKey }to( 0
<wait until><( <{ spaceKey }> <=> 1 )>
<broadcast[ step 1
<set{ spaceKey }to( 0
<wait until><( <{ spaceKey }> <=> 1 )>
<broadcast[ step 2
<set{ spaceKey }to( 0
<wait until><( <{ spaceKey }> <=> 1 )>
<broadcast[ step 3

<when I receive[ step 1

<when I receive[ step 2

<when I receive[ step 3