(I made a topic with multiple questions, here's one of them, that's why it may sound out of context)
Also lacking is a mode for typing. You have

ask [] and wait

, but that's less customizable then Windows 10. I would like to have

when typed (input :: events) :: hat :: events

with input as a string so you can code

when green flag clicked
set [text v] to []
show variable [text v]
enable typing mode :: control
when typed (input :: events) :: hat :: events
set [text v] to (join (text) (input :: events))

That could also enable the on-screen keyboard on mobile devices.

*bump*

*bump*

*bump*
Does noone cares about typing? It could be a cool extension, together with this

*bump*
You you have no opinion about my idea?

when typed (input :: events) :: hat :: events

I assume (input) is not something that you replace with text, but something dragged like a variable. In that case, it would be no different than

when [ v] key pressed

except more compact.

Naleksuh wrote:

when typed (input :: events) :: hat :: events

I assume (input) is not something that you replace with text, but something dragged like a variable. In that case, it would be no different than

when [ v] key pressed

except more compact.

Input contains a string, the letter you type. And it's totaly different to when x is pressed because that's an event when the specific key is pressed, not when anything is typed. And even with a when anything is pressed block you couldn't do that because you would have to figure out which key is pressed. And you can't detect if shift is pressed or not so everything would be lower-case. input would contain a upper-case letter when you press shift while typing. And input contains a string with a special character (in C++ it's ‘\b’) when you type backspace and

(join [test] [*backspace*])

would return “tes”.

Also, while the typing mode is enabled,

<key [ v] pressed?> //and
when [ v] key pressed

are disabled.

And, the last thing, the typing mode enables the on-screen keyboard on mobile devices.

*bump*

*bump*

That could be interesting. I suppose it would work kind of like the “when up up down down left right left right are pressed in order” block, from the Makey Makey extension.

I have another idea:

enable typing mode with other key blocks [enabled v] :: control

This could enable a mode for cheats: You can type while other keys are still working. And

clear input :: events

so you can use

when green flag clicked
enable typing mode with other key blocks [enabled v] :: control
when typed (input :: events) (clear input :: events :: stack) :: events :: hat
if <(input :: events) = [cheat]> then
enable cheat mode :: grey
clear input :: events

and still control the game with the arrow keys.

*bump*

Has anyone an idea how to improve this?

HTML-Fan wrote:

when typed (input :: events) (clear input :: events :: stack) :: events :: hat
if <(input :: events) = [cheat]> then
enable cheat mode :: grey
clear input :: events

Maybe instead of the blocks being inside the hat block, like what happens when you define a custom block, there could be an “input” reporter that could be used anywhere. Here are my ideas for the blocks:

input :: sensing reporter
[start v] typing detection :: sensing

clear input :: sensing

So it could be used like this:

when green flag clicked
clear input :: sensing
[start v] typing detection :: sensing

when [any v] key pressed
if <(input :: sensing) = [cheat]> then
enable cheat mode :: custom
clear input :: sensing
end

Okay, you're right, it could be useful.

But you need a separate event for this, since it shouldn't trigger an event when you just press shift but should when you press enter or type something.
And I think that it doesn't quite fits into the sensing caterory, there should be an extention with this and this: https://scratch-mit-edu.ezproxyberklee.flo.org/discuss/topic/348958/?page=3#post-4173044

HTML-Fan wrote:

But you need a separate event for this, since it shouldn't trigger an event when you just press shift but should when you press enter or type something.

I just think the events are way too similar. The “when typing” event would just work the same as the “any key pressed” event, except for some keys? Maybe instead of that there could be a new block in the extension, something like “last key typed”, which would give you control over which keys are allowed to start typing, like this:

when [any v] key pressed
if <not<last key typed is [shift v]? :: sensing>> then
...
end

I chose a boolean instead of a reporter with the last key typed because I think it's more convenient to have all your options laid out for you instead of remembering which keys are supported and how they are spelled, but this could just be a “last key typed” reporter too.

HTML-Fan wrote:

And I think that it doesn't quite fits into the sensing caterory, there should be an extention with this and this: https://scratch-mit-edu.ezproxyberklee.flo.org/discuss/topic/348958/?page=3#post-4173044

Yeah it would be better as an extension, just made it in the sensing category because the question and answer blocks are there, and they're the most similar thing I could think of to what you were suggesting.

I think that they may be very similar, but I personally think that they mean something different, if you know what I mean.
And when I think about it, the only spot where it makes sense to do something with the input is at the event typing itself so it could be like a parameter in a custom block. The clear block too.

Fupicat wrote:

I chose a boolean instead of a reporter with the last key typed because I think it's more convenient to have all your options laid out for you instead of remembering which keys are supported and how they are spelled, but this could just be a “last key typed” reporter too.

But the whole point of this is that you can use the keyboard for typing easier then ever because you just get the input as a variable.

HTML-Fan wrote:

I think that they may be very similar, but I personally think that they mean something different, if you know what I mean.
And when I think about it, the only spot where it makes sense to do something with the input is at the event typing itself so it could be like a parameter in a custom block. The clear block too.

What if you want to do something like, “type this in 10 seconds!”, so you have a green flag block with a wait block, and at the end of the timer, you check to see if the input is correct, and then wipe it. That doesn't require a “when typing” hat. My point is that restricting a type of block to one specific event is not necessary unless it literally cannot be used outside of it. Like custom block parameters, they can't be used outside of custom blocks because every time a custom block is called they're different values, and the only context where these values make sense is inside the custom block definition.

HTML-Fan wrote:

Fupicat wrote:

I chose a boolean instead of a reporter with the last key typed because I think it's more convenient to have all your options laid out for you instead of remembering which keys are supported and how they are spelled, but this could just be a “last key typed” reporter too.

But the whole point of this is that you can use the keyboard for typing easier then ever because you just get the input as a variable.

I don't know what you mean there, that quote was just me justifying why I used a dropdown selection for keys instead of just a reporter that says which key you last pressed as a string.

But a reporter is the point of this, so you don't have to mess with shift and so on.