Ziggy741 wrote:

Workaround:

if <key [r v] pressed?> then
... :: grey
end

What about for this?

set [user input v] to (join (user input) (key pressed :: sensing))

I support, but I think this might be a duplicate.

TheMonsterOfTheDeep wrote:

Ziggy741 wrote:

Workaround:

if <key [r v] pressed?> then
... :: grey
end

What about for this?

set [user input v] to (join (user input) (key pressed :: sensing))

I support, but I think this might be a duplicate.

Don't get it.

Ziggy741 wrote:

TheMonsterOfTheDeep wrote:

Ziggy741 wrote:

Workaround:

if <key [r v] pressed?> then
... :: grey
end

What about for this?

set [user input v] to (join (user input) (key pressed :: sensing))

I support, but I think this might be a duplicate.

Don't get it.

It's just a user input variable being set.

NanoRook wrote:

Ziggy741 wrote:

TheMonsterOfTheDeep wrote:

Ziggy741 wrote:

Workaround:

if <key [r v] pressed?> then
... :: grey
end

What about for this?

set [user input v] to (join (user input) (key pressed :: sensing))

I support, but I think this might be a duplicate.

Don't get it.

It's just a user input variable being set.

OK thank you, but I didn't understand what the block was being used for in that example.

What if multiple keys are pressed? What would it report?
Say the key “r” was pressed. Obviously, the block would report “r”
But if both “r” and “g” are pressed, the block wouldn't be “r” anymore, so

<(keys pressed::sensing)=[r]>

Wouldn't work even though the r key is being pressed.

And how'll the cursor keys, enter/return, backspace/delete, delete/delete, and ctrl/command/shift/alt/option/etc. be reported via this block?

Sheep_maker wrote:

What if multiple keys are pressed? What would it report?
Say the key “r” was pressed. Obviously, the block would report “r”
But if both “r” and “g” are pressed, the block wouldn't be “r” anymore, so

<(keys pressed::sensing)=[r]>

Wouldn't work even though the r key is being pressed.

And how'll the cursor keys, enter/return, backspace/delete, delete/delete, and ctrl/command/shift/alt/option/etc. be reported via this block?

That's a good question. I think an unambiguous one (that would clearly have some limitations) is:

(last letter pressed :: sensing)

Support! This definitely would be helpful!
Here's an example:

when green flag clicked
forever
wait until <key [any v] pressed?> 
set [words v] to (join (words ::variables) (key pressed ::sensing)
end

So the (key pressed) will report the key(s) pressed, like if I were to press b it would report b and if I were to report a and c at the same time it would report ac, correct?

TheMonsterOfTheDeep wrote:

Sheep_maker wrote:

What if multiple keys are pressed? What would it report?
Say the key “r” was pressed. Obviously, the block would report “r”
But if both “r” and “g” are pressed, the block wouldn't be “r” anymore, so

<(keys pressed::sensing)=[r]>

Wouldn't work even though the r key is being pressed.

And how'll the cursor keys, enter/return, backspace/delete, delete/delete, and ctrl/command/shift/alt/option/etc. be reported via this block?

That's a good question. I think an unambiguous one (that would clearly have some limitations) is:

(last letter pressed :: sensing)

By “last” does that mean the last key unpressed? If not, that still doesn't explain what happens when multiple keys are pressed

scratch0maker0 wrote:

Ok, I want a block that senses which key was pressed and returns that key.
like this:

if <(key pressed:: sensing) = [r]> then
your stuff :: grey
end

It would be helpful in touch typing projects.

Take a look in sound and costume for a key It might be helpful for that you are needing.

Suppose I have a custom block called text ().
Instead of this,

when [a v] key pressed
text (a) :: custom
when [b v] key pressed
text  (b):: custom
when [c v] key pressed
text  (c) :: custom

and on... :: grey

I can do this:

when green flag clicked
forever
if <key [any key v] pressed?> then
text (key pressed :: sensing) :: custom
end
end

A simple way of doing this is letting 2 inputs being in the block at the same time.

Like, if I pressed a and b together, it'd report “a b” or “a, b”.

I support, this could be useful.

Scratcher1002 wrote:

A simple way of doing this is letting 2 inputs being in the block at the same time.

Like, if I pressed a and b together, it'd report “a b” or “a, b”.

I support, this could be useful.

However, if the keys were separated with spaces, it'd make this intended use:

forever
set [input v] to (join(input)(keys pressed::sensing))
end

not work anymore. Maybe have them all in one string of text (without spaces other than the space key), based off the order they started to be held down?
However, how would “upper characters” (i.e. !@#$%^&*() on US keyboards) and capital letters be reported? Currently, Scratch treats the upper characters as a unique key by itself, but capital letters as shift (technically, ctrl, alt, etc. are also considered “shift” due to Flash) + the lowercase letter. Would arrow keys and other keys that aren't necessarily a character be reported with this block as well? If so, how would they be reported? Are keys not in the key pressed? dropdown detected as well, since different language keyboards have different symbols?

I will elaborate:

Sheep_maker wrote:

Scratcher1002 wrote:

A simple way of doing this is letting 2 inputs being in the block at the same time.

Like, if I pressed a and b together, it'd report “a b” or “a, b”.

I support, this could be useful.

However, if the keys were separated with spaces, it'd make this intended use:

forever
set [input v] to (join(input)(keys pressed::sensing)) // this would be "key pressed", not keys pressed, since it reports the last key pressed. 
//If two keys are being pressed, It will use the fact nobody can press two keys at exactly the same time. 

(this^^)
not work anymore. Maybe have them all in one string of text (without spaces other than the space key), based off the order they started to be held down?
However, how would “upper characters” (i.e. !@#$%^&*() on US keyboards) and capital letters be reported? (as capitals)
Currently, Scratch treats the upper characters as a unique key by itself, but capital letters as shift (technically, ctrl, alt, etc. are also considered “shift” due to Flash) + the lowercase letter. ( I have no idea what your talking about.)
Would arrow keys and other keys that aren't necessarily a character be reported with this block as well? If so, how would they be reported? (think about it, NO!)
Are keys not in the key pressed? (I am looking for reports of THE key pressed, not IF A key is being pressed!) (dropdown detected as (What does this mean?)) well, since different language keyboards have different symbols? (different languages will report the same key, just like hacking an if key pressed block:

<key [language key] pressed?>

That's how it would be treated)

Support.

No support

all the suggestions made here are actually workaroundables with a VERY LARGE SCRIPT, but whatever, workaroundable



PD: i will start working in the workaround

when green flag clicked
I will never give you up
Darude Sandstorm
Illuminati
Doge
Doritos
More memes

Minecratch_project wrote:

No support

all the suggestions made here are actually workaroundables with a VERY LARGE SCRIPT, but whatever, workaroundable



PD: i will start working in the workaround

But what if I don't want script that, it would easier thats all I'm saying.

scratch0maker0 wrote:

Minecratch_project wrote:

No support

all the suggestions made here are actually workaroundables with a VERY LARGE SCRIPT, but whatever, workaroundable



PD: i will start working in the workaround

But what if I don't want script that, it would easier thats all I'm saying.

Well, now you re saying… you have the reason!

semi-support

when green flag clicked
I will never give you up
Darude Sandstorm
Illuminati
Doge
Doritos
More memes

scratch0maker0 wrote:

I will elaborate:

Sheep_maker wrote:

Scratcher1002 wrote:

A simple way of doing this is letting 2 inputs being in the block at the same time.

Like, if I pressed a and b together, it'd report “a b” or “a, b”.

I support, this could be useful.

However, if the keys were separated with spaces, it'd make this intended use:

forever
set [input v] to (join(input)(keys pressed::sensing)) // this would be "key pressed", not keys pressed, since it reports the last key pressed. 
//If two keys are being pressed, It will use the fact nobody can press two keys at exactly the same time. 

(this^^)
not work anymore. Maybe have them all in one string of text (without spaces other than the space key), based off the order they started to be held down?
However, how would “upper characters” (i.e. !@#$%^&*() on US keyboards) and capital letters be reported? (as capitals)
Currently, Scratch treats the upper characters as a unique key by itself, but capital letters as shift (technically, ctrl, alt, etc. are also considered “shift” due to Flash) + the lowercase letter. ( I have no idea what your talking about.)
Would arrow keys and other keys that aren't necessarily a character be reported with this block as well? If so, how would they be reported? (think about it, NO!)
Are keys not in the key pressed? (I am looking for reports of THE key pressed, not IF A key is being pressed!) (dropdown detected as (What does this mean?)) well, since different language keyboards have different symbols? (different languages will report the same key, just like hacking an if key pressed block:

<key [language key] pressed?>

That's how it would be treated)

Actually, two keys can be pressed at the same time. People normally press shift + A for capital A and ctrl + C to copy selected text.
Currently, the key pressed? boolean reports true when the specified key has been held down. Here you're saying that multiple keys can't be held down at the same time.

If I pressed “b,” let go, then pressed and held “a” first and “c” a bit later, what would the block report now? Both “a” and “c” held down, so key a pressed? and key c pressed? will both return true. You said that the key pressed reporter reports the last key pressed, but that's still a bit ambiguous. “b” is the last key unpressed and “c” is the last key that has started to be pressed, but “a” is still being held down, so which of those would the block report?

There can be multiple keys pressed, depending on what you mean by “pressed,” so there can't just be the key pressed.

Sheep_maker wrote:

scratch0maker0 wrote:

I will elaborate:

Sheep_maker wrote:

Scratcher1002 wrote:

A simple way of doing this is letting 2 inputs being in the block at the same time.

Like, if I pressed a and b together, it'd report “a b” or “a, b”.

I support, this could be useful.

However, if the keys were separated with spaces, it'd make this intended use:

forever
set [input v] to (join(input)(keys pressed::sensing)) // this would be "key pressed", not keys pressed, since it reports the last key pressed. 
//If two keys are being pressed, It will use the fact nobody can press two keys at exactly the same time. 

(this^^)
not work anymore. Maybe have them all in one string of text (without spaces other than the space key), based off the order they started to be held down?
However, how would “upper characters” (i.e. !@#$%^&*() on US keyboards) and capital letters be reported? (as capitals)
Currently, Scratch treats the upper characters as a unique key by itself, but capital letters as shift (technically, ctrl, alt, etc. are also considered “shift” due to Flash) + the lowercase letter. ( I have no idea what your talking about.)
Would arrow keys and other keys that aren't necessarily a character be reported with this block as well? If so, how would they be reported? (think about it, NO!)
Are keys not in the key pressed? (I am looking for reports of THE key pressed, not IF A key is being pressed!) (dropdown detected as (What does this mean?)) well, since different language keyboards have different symbols? (different languages will report the same key, just like hacking an if key pressed block:

<key [language key] pressed?>

That's how it would be treated)

Actually, two keys can be pressed at the same time. People normally press shift + A for capital A and ctrl + C to copy selected text.
Currently, the key pressed? boolean reports true when the specified key has been held down. Here you're saying that multiple keys can't be held down at the same time.

If I pressed “b,” let go, then pressed and held “a” first and “c” a bit later, what would the block report now? Both “a” and “c” held down, so key a pressed? and key c pressed? will both return true. You said that the key pressed reporter reports the last key pressed, but that's still a bit ambiguous. “b” is the last key unpressed and “c” is the last key that has started to be pressed, but “a” is still being held down, so which of those would the block report?

There can be multiple keys pressed, depending on what you mean by “pressed,” so there can't just be the key pressed.

Good point. I didn't think of that.

If you mean this…

(key pressed ::sensing

…then +1