Ok, well, I guess standard isn't the word, but from what I see, it is a fairly common usage of those blocks. So yes, I guess you could call it a workaround. One, I solved the problem, and two, the problem isn't selecting an object and dragging it, the problem was the way scratch sprites sense when they are being touched by the mouse, using the

<touching [ mouse pointer] ?>

block. I guess it's just another quirk of Scratch! I will be releasing my project soon and will be sure to post the link here!

Indifferent. There's an easy workaround, but why should such a simple block be workaroundable?

It's not a good work around though! Take a look at the test project I made (link above) and you will see what i mean!!! The way that objects sense wether they are touching the mouse means that the wrong object can and will be selected when you click on it. The effects of clicking on the objects using the

when this sprite clicked

are very different than when you use the

<<touching [mouse pointer v] ?> and <mouse down?>>

I still think this would make a very good addition to the sensing category!

Edit: I also want to add and make clear that, in my opinion, the

when this sprite clicked

block is very impracticle and hard to use with bigger projects that require large amounts of precise code. There are a ton of situations where a

<sprite clicked?>

block would be immensely useful in not disrupting the flow of the code and also providing necessary functionality which

<<touching [mouse pointer v] ?> and <mouse down?>>

simply can not provide!

Not a good idea. Hat blocks are events and “when sprite clicked” is an event, hence its a hat block. Clicking a sprite isn't a state so the block you propose would be confusing.

@drmcw Hmm… I see your point. However, I really don't know if it would be that confusing. I mean, one could make the argument that being clicked is an event AND a state of sorts, although it' might not be a very strong one. But isn't

<key [space v] pressed?> 

an event, not a state? I don't see how

 <sprite clicked?> 

should be any different. However, if you had your script set up the right way, I suppose you could have:

when this sprite clicked
set [ clicked v] to [1]

And then in your script have:

forever
if <(clicked) = [1]> then
do whatever
set [clicked v] to [0]
end
end

However, all of these problems could be solved if either the mouse sensing worked differently, or if you could change an option to select the kind of
mouse sensing you prefer for your project, or if you had the aforementioned “sprite clicked?” block. Your thoughts?

drmcw wrote:

Not a good idea. Hat blocks are events and “when sprite clicked” is an event, hence its a hat block. Clicking a sprite isn't a state so the block you propose would be confusing.

I think it can be both an event and a state, like a key being pressed. The state would be true when the sprite is clicked and stay true until the mouse is released.

<<touching [mouse-pointer v]?> and <mouse down?>>

is not a perfect workaround for a couple of reasons. Firstly, it will report true if the sprite is behind another sprite or hidden with the hide block, while the sprite clicked hat doesn't fire when this is the case.

Second, it will report true if the mouse was clicked elsewhere and then dragged over the sprite, and will report false if the sprite is clicked and then the mouse is dragged away. The first of those is probably not the wanted behaviour, the second may or may not be.

A better workaround would be this:

when this sprite clicked
set [clicked v] to [1]
wait until <not <mouse down?>> // you could also add <not touching mouse>, depending on how you want it to work
set [clicked v] to [0]

although since it's a separate script, it might not work well with single-frame scripts.

Yes! Thank you! That is exactly what I have been trying to say!

Looks like a duplicate.

https://scratch.mit.edu/discuss/topic/44059/

Scratch on!

Another way to do this:

when gf clicked
forever
wait until <mouse down?>
if <touching [mouse-pointer v]?> then
repeat until <not <mouse down?>>
set [clicked v] to <touching [mouse-pointer v]?>
end
set [clicked v] to [false]
else
wait until <not <mouse down?>>
end
end

I'm pretty sure this does exactly what you want, but I'm not really sure. That's part of the problem with implementing a <clicked?> block - it could either behave like this, or slightly differently. Right now, my script will:

• Report true if, once the mouse is clicked, it is already under the mouse
  
• Report false if it was not under the mouse once the mouse was clicked
  
• Report false if the mouse was moved away from it
  
• Report true if the mouse moved away then back, and it was originally clicked
  

However, it's also possible that you wanted the sprite to remain clicked if the mouse left, or it's possible that you wanted the sprite to stop being clicked at all after the mouse left. The block is ambiguous.

Rather, it's best to construct your own mouse events, because then you can make them do exactly what you want.

I see the

<sprite clicked?>

As needing support due to the facts that One, the way a sprite senses when it is touching the mouse is entirely different than the way it senses whether it has been clicked or not using the

when this sprite clicked

I have made a test project demonstrating this here: https://scratch.mit.edu/projects/137039590/

Notice how sprites that are covered by other sprites still detect that they are being touched by the mouse, but a sprite can not be clicked when it is behind another sprite. This is the inherent problem with using the

<<touching [mouse  v] ?> and <mouse down?>>

Not to mention the problems you have to work around involving multiple sprites being dragged, a not really proper “click” still activating the sprite and it's scripts, and the fact that using

when this sprite clicked

Disrupts the flow of many scripts and makes programming more difficult. Why is there one for “stage clicked” but not one for “sprite clicked”? I think this really should be supported!

As stated previously, the problem is not getting to the point where a proper click is registered, as your script will no doubt do that. The problem lies in the fact that a sprite that is covered by other sprites or even one that is hidden can still sense that it is touching the mouse, a problem that the

when this sprite clicked

block avoids! That is the issue here.


Edit: I myself worked out a solution that worked very well except the fact that sprites that shouldn't have been clickable were still effected by the script due to the weird way sprites sense if the mouse is touching it.

Ibprofen98 wrote:

As stated previously, the problem is not getting to the point where a proper click is registered, as your script will no doubt do that. The problem lies in the fact that a sprite that is covered by other sprites or even one that is hidden can still sense that it is touching the mouse

Ah. Well, it's pretty easy still to adapt my script so it *almost* works:

when gf clicked
set [clicked v] to [false]

when this sprite clicked
repeat until <not <mouse down?>>
set [clicked v] to <touching [mouse-pointer v]?>
end

This will not activate if the sprite is behind another sprite when it is clicked.

The only problem it has is that it will remain clicked as long as the mouse pointer is within the sprite's area - even that that is hidden.

However, I seriously cannot think of a situation where it would be necessary to know that the mouse was within the sprite's on-screen area for a period of time. Do you have an example?

As it were, could you tell me which of these situations you are looking for:

• Sprite is no longer clicked as soon as mouse leaves sprite bounds
  
• Sprite remains clicked until mouse up (seems to be the most common interpretation)
  
• Sprite's clicked state is set to whether the mouse is inside its bounds until the mouse is no longer pressed (this is my workaround)
  

If you wish for the second one, this block is entirely workaroundable:

when gf clicked
set [clicked v] to [false]

when this sprite clicked
set [clicked v] to [true]
wait until <not <mouse down?>>
set [clicked v] to [false]

But having to do all that and having to try and work around all that mess would all be avoided and things would work so much smoother if they just added a

< sprite clicked?>

I think it deserves support.

Ibprofen98 wrote:

But having to do all that and having to try and work around all that mess would all be avoided and things would work so much smoother if they just added a

< sprite clicked?>

I think it deserves support.

Please answer these two questions:

TheMonsterOfTheDeep wrote:

However, I seriously cannot think of a situation where it would be necessary to know that the mouse was within the sprite's on-screen area for a period of time. Do you have an example?

TheMonsterOfTheDeep wrote:

As it were, could you tell me which of these situations you are looking for:

• Sprite is no longer clicked as soon as mouse leaves sprite bounds
  
• Sprite remains clicked until mouse up (seems to be the most common interpretation)
  
• Sprite's clicked state is set to whether the mouse is inside its bounds until the mouse is no longer pressed (this is my workaround)
  

Ok. The situation that I was actually dealing with was this: When a sprite is clicked it has to snap to the mouse, allowing you to drag it around until you have it in place, and then when you let go it unsnaps from the mouse. I solved the problem eventually using the

when this sprite clicked

block, but it involved altering all of my code, although it could have been worse if my game was more complicated. The problem was that when I went to drag one sprite, a sprite behind it would get selected instead. All I am saying is that the simplest way to get these kinds of things done would be a

< sprite clicked?>

block, just like how there is a

<background clicked?>

Housekeeping: Merged in another thread. Bump!

Ibprofen98 wrote:

Ok. The situation that I was actually dealing with was this: When a sprite is clicked it has to snap to the mouse, allowing you to drag it around until you have it in place, and then when you let go it unsnaps from the mouse.
…
The problem was that when I went to drag one sprite, a sprite behind it would get selected instead.

I see. Note that the workarounds above would work for this situation.

I'm not sure they would. Have you looked at my test project here? https://scratch.mit.edu/projects/137039590/ This demonstrates the way that sprites sense whether or not they are touching the mouse vs when they are clicked. This is the underlying problem here.

Just re-looked at your suggestions, and I think that the last one would work. My bad, didn't read that the right way originally. I still think that this block would be a great addition to scratch. It would eliminate all of this workarounding we have to do to accomplish such a simple task.

stickfiregames wrote:

drmcw wrote:

Not a good idea. Hat blocks are events and “when sprite clicked” is an event, hence its a hat block. Clicking a sprite isn't a state so the block you propose would be confusing.

I think it can be both an event and a state, like a key being pressed. The state would be true when the sprite is clicked and stay true until the mouse is released.

No a click is an event in time it's not a state, it can only be a state if it has meaning to the sprite, like it is a button, in which case it is up to the programmer to create that state. What if you moved the mouse off the sprite while the mouse was held down is that still a clicked state or not? All the new block is trying to create is an if mouse down and mouse touching state which is nonsense for most projects.
A key press is an event and a state, which is why both blocks are available.