I recently learned that you can use

<key (join [] [enter]) pressed?>

to detect whether or not the Enter key is pressed. Why can't we use

<key (join [] [shift]) pressed?>

to detect if the Shift key is pressed?

I wish we could do that with both shift and backspace, I don't see any downsides to it either.

Well, instead of using the join () () block hack, I feel like it should be added overall, like this:

<key [enter v] pressed?>
<key [shift v] pressed?>
<key [backspace v] pressed?>

It's a good idea but if you send a comment, you have to press enter and if you have to press enter on a platformer to skip a level, it will prevent the scratchers from sending comments. If you make a project with the enter buttons, use the enter key to do other action. And it's the same for the backspace key.

Support for backspace same way as enter because it is hard to do text editors or custom keyboard input without them.

No support for shift, instead support for

(join [] [])

to be used in

<key [ v] pressed?>

to detect characters like % & + @ ?

minor-edit wrote:

No support for shift, instead support for

(join [] [])

to be used in

<key [ v] pressed?>

to detect characters like % & + @ ?

That already exists. Try it out yourself!

Za-Chary wrote:

That already exists. Try it out yourself!

But they'll have to do this:

(join [%] [])

Nambaseking01 wrote:

Za-Chary wrote:

That already exists. Try it out yourself!

But they'll have to do this:

(join [%] [])

What he quoted was what he's talking about.

The workaround for keys that aren't in the dropdown exists, is what he meant

<key (join [%] []) pressed?>

IsaiahContreras wrote:

What he quoted was what he's talking about.

The workaround for keys that aren't in the dropdown exists, is what he meant

<key (join [%] []) pressed?>

Which is exactly what I said. I just put it in the [scratchblocks] tag.

Za-Chary wrote:

minor-edit wrote:

No support for shift, instead support for

(join [] [])

to be used in

<key [ v] pressed?>

to detect characters like % & + @ ?

That already exists. Try it out yourself!

I thought it did (!), but I'm on a tablet and cannot test it because the on-screen keyboard only appears when a text field has focus. I'm actually going to go buy a keyboard right now. Bbl.

minor-edit wrote:

No support for shift

Why not? Shift is one very important key to be able to detect!

It works. Interestingly, shift + green flag does not. It is a bluetooth keyboard. All the printable characters (letter case ignored) register, but backspace results in blocks being deleted unexpectedly.

griffpatch also supports backspace https://github.com/LLK/scratch-vm/issues/1892#issuecomment-551006403

mica43683 wrote:

minor-edit wrote:

No support for shift

Why not? Shift is one very important key to be able to detect!

minor-edit wrote:

instead support for

(join [] [])

to be used in

<key [ v] pressed?>

to detect characters like % & + @ ?

minor-edit wrote:

mica43683 wrote:

minor-edit wrote:

No support for shift

Why not? Shift is one very important key to be able to detect!

minor-edit wrote:

instead support for

(join [] [])

to be used in

<key [ v] pressed?>

to detect characters like % & + @ ?

Right, but why not shift?

mica43683 wrote:

minor-edit wrote:

mica43683 wrote:

minor-edit wrote:

No support for shift

Why not? Shift is one very important key to be able to detect!

minor-edit wrote:

instead support for

(join [] [])

to be used in

<key [ v] pressed?>

to detect characters like % & + @ ?

Right, but why not shift?

Since the symbol characters can be detected.

minor-edit wrote:

It works. Interestingly, shift + green flag does not. It is a bluetooth keyboard. All the printable characters (letter case ignored) register, but backspace results in blocks being deleted unexpectedly.

griffpatch also supports backspace https://github.com/LLK/scratch-vm/issues/1892#issuecomment-551006403
✂✂✂- - - - - - - snipped - - - - - - - - - - - - - - - - - - - - - - -

@griffpatch's ASCII Key Detector doesn't work anymore, which is sad.

BasisEssence779 wrote:

It's a good idea but if you send a comment, you have to press enter and if you have to press enter on a platformer to skip a level, it will prevent the scratchers from sending comments. If you make a project with the enter buttons, use the enter key to do other action. And it's the same for the backspace key.

As far as I know, you click a button to send comment. But I might be wrong.

minor-edit wrote:

mica43683 wrote:

-snip-
Right, but why not shift?

Since the symbol characters can be detected.

Right, but why not adding shift detection?

-FasterThanLight- wrote:

@griffpatch's ASCII Key Detector doesn't work anymore, which is sad.

And his Word Processor v3.6.1 is broken with no backspace sensing by Scratch 3.0 projects.

mica43683 wrote:

Right, but why not adding shift detection?

Because the symbol characters from using shift can be detected already.

minor-edit wrote:

-snipped-

mica43683 wrote:

Right, but why not adding shift detection?

Because the symbol characters from using shift can be detected already.

Yes, the % and # character and all the others can be detected, but not capital letters. That's what I'm interested in.

Existing projects detect uppercase and lowercase letters as the same, using

when [ v] key pressed

and

<key [ v] pressed?>

In Scratch 3, the latter block lets reporters be put in it to detect basic keyboard symbols and enter (sometimes called return, because modern keyboards are descended from typewriters). Griffpatch's Text Editor v2.4b gives a clue as to why shift detection may not be ideal. In the 31 Oct note he mentions having to choose between what shift + 3 produces on a UK keyboard and on a U.S. one. A pound (£) sign versus a pound (#) sign. Two different characters, same shift + key. That's one aspect of the problem. My Bluetooth keyboard not working for shift + green flag is another. Not only may some keyboards intend different characters by modifying the same key, some keyboards may not send a shift signal at all to conserve energy (my Bluetooth keyboard's battery) instead just sending the presumed intended character to the computer or only sending a shift signal under certain circumstances. The other aspect is the aforementioned detection of uppercase and lowercase as the same by today's Scratch blocks.

Since

<key [ v] pressed?>

means both uppercase and lowercase, then

< <key [shift v] pressed?> and <key [ v] pressed?>>

would only mean uppercase for a letter (if caps lock isn't active). How does one detect lowercase in those circumstances?

< <not <key [shift v] pressed?> > and <key [ v] pressed?>>

But what if caps lock is down?

These issues seems to present a difficult problem for the average Scratcher to solve, and may be why shift isn't part of what Scratch detects.

I hope for

<key (join [U+][whatever_the_dominant_UTF_encoding_says_this_should_be]) pressed?>

plus

<key (join[back][space]) pressed?> 

to become part of Scratch. But any better solution to these problems, if they exist, should be considered.