I don't know if that was already suggested:

set mouse cursor to [hand v] :: sensing

That would turn the mouse cursor into a hand. There would also be options for the move cursor, no cursor at all (you could use a sprite with go to mouse instead) and so on.
I think that it would be useful for buttons. I thought that a program has crashed just because the buttons didn't changed the color, neither the mouse cursor.

So, but that's only half of my suggestion. The block should also have the option to “grab” the mouse (if that's the right word). That means that your mouse cursor is trapped in the little project window. Some emulators like STeem do that. It would be extremly useful for 3d games so you can look around with the mouse and don't have to use the arrow keys. It would just generate x and y coordinates for

(mouse x) // and
(mouse y)

as usual, but they will just keep increasing or decreasing when you move the mouse, even if they get higher then 240 or 180.
You would simply use a right-click or press Esc to get out of the window.

So, what do you think about my ideas?

I know that a hide mouse cursor block is rejected, because it wouldn't change much, but this is different, so don't tell me that it's a duplicate and don't report it. It was rejected because it would only make your mouse cursor invisible, which may be confusing. This would make it rather less confusing.

I'm confused on the first part about the hand, but changing the looks of the mouse pointer is also rejected.

If you go over a link, then your mouse cursor turns into a hand. And that's more or less only a side feature, the major suggestion is to be able to trap the mouse in the scratch window.

Changing mouse pointer to a hand or a move cursor probably falls under the rejected suggestion, but I'm not sure.

Locking it, however, isn't rejected – you mean something like this?

Maximouse wrote:

you mean something like this?

Exactly. I don't know if there's a name for that. You should also be able to leave the area with a right-click, since the right-clck is nut usable in projects so far.
I think that only changing the cursor isn't enough for a whole block, but together with this it could be.

*bump*

*bump*

I *really* don't like the idea of a project screwing with where my mouse is. Even if you could press esc to release the mouse, imagine if the page is lagging, or stopped responding, then your mouse is just stuck in the same place until you hard-reset. I've had this problem multiple times with browser applications trapping my mouse and then not being able to release it. Also, this wouldn't do anything on mobile.

Overall, no support. Scratch should be able to use OS features, but this one feels like it would be a pain. In general, the mouse should never be screwed with. Imagine kids using Scratch in school and getting their mouse trapped and not knowing how to release it, having to annoy their teachers every time.

Fupicat wrote:

Imagine kids using Scratch in school and getting their mouse trapped and not knowing how to release it, having to annoy their teachers every time.

The browser says “Press esc to show your cursor”. Isn't that enough?

Fupicat wrote:

Imagine kids using Scratch in school and getting their mouse trapped and not knowing how to release it, having to annoy their teachers every time.

I think that pressing Esc is pretty obvious. And when you do that, then you can right-click. Maybe there should be an alert like “Grab mouse? Yes No” and it only gets trapped when you click on it.

Fupicat wrote:

Even if you could press esc to release the mouse, imagine if the page is lagging, or stopped responding, then your mouse is just stuck in the same place until you hard-reset.

When that happens, then you should still be able to press Esc. Or Alt+F4. That shouldn't be a problem, if it is, then I don't support my own idea.

Fupicat wrote:

I *really* don't like the idea of a project screwing with where my mouse is.

But most shooters do that.

No support.

That mouse being stuck in the project screen is making me feel extremely claustrophobic.

Nambaseking01 wrote:

No support.

That mouse being stuck in the project screen is making me feel extremely claustrophobic.

But at you see in the example, it's very easy to release it.

Nambaseking01 wrote:

No support.

That mouse being stuck in the project screen is making me feel extremely claustrophobic.

Okay, it makes me somehow to ^^
Maybe that could be a fullscreen feature, you enable fullscreen and the project takes over the whole screen and the mouse too. It's more like an application like a shooter this way.

HTML-Fan wrote:

I think that pressing Esc is pretty obvious. And when you do that, then you can right-click. Maybe there should be an alert like “Grab mouse? Yes No” and it only gets trapped when you click on it.

Kids will be kids. :\ My cousin asks me stupid computer questions all the time, literally stuff that is already on the screen. That's just one specific situation I hypothesized but from experience only, but it's very real. I do like the idea of an alert appearing.

HTML-Fan wrote:

When that happens, then you should still be able to press Esc. Or Alt+F4. That shouldn't be a problem, if it is, then I don't support my own idea.

Ok that might be more of my own problem because I use Linux, and the OS I am using doesn't have ctrl+alt+del. If I want to end a process, I have to go to the menu and open the System Monitor, but that requires having control of the mouse. So I either have to sit there waiting or hard-reset the computer.

HTML-Fan wrote:

But most shooters do that.

When I go play a shooter, I already know what is going to happen to my mouse. When I go play a Scratch project, I know nothing about it, and if my mouse gets constantly trapped I would be quite annoyed. Imagine if 50% of all games were shooters, but all of them were just called “COOL GAME” and were secretly made by people who had just learned how to code that night. Would you trust them with your mouse?

Za-Chary wrote:

1.10 “Change mouse pointer” or “hide mouse pointer” blocks
The block below, and others, could be used to hide the mouse pointer or change the way the mouse pointer looks in a project. These blocks, however, do not significantly change the types of projects that can be created with Scratch. In addition, they may cause confusion to users, wondering where the mouse pointer went.

hide mouse pointer :: looks

Above is a quote from the rejected suggestions list. Correct me if I'm wrong, but this falls under the category of “change mouse pointer” doesn't it?

whiteandblackcat wrote:

Za-Chary wrote:

1.10 “Change mouse pointer” or “hide mouse pointer” blocks
The block below, and others, could be used to hide the mouse pointer or change the way the mouse pointer looks in a project. These blocks, however, do not significantly change the types of projects that can be created with Scratch. In addition, they may cause confusion to users, wondering where the mouse pointer went.

hide mouse pointer :: looks

Above is a quote from the rejected suggestions list. Correct me if I'm wrong, but this falls under the category of “change mouse pointer” doesn't it?

Here, “change mouse pointer” refers to setting the mouse pointer to look like something other than a mouse pointer. I think some computer games have the mouse pointer look like a flower or something.

So I don't believe the OP's suggestion is rejected right now, but I can see how it may cause some issues and confusion.

I think I can say with certainty that we will not be implementing mouse position control blocks, or features that “trap the mouse in the stage”. The potential for confusion outweighs the anticipated benefits, in my opinion.