[r207] DragDrop dragging

Problem Description

When using the dragdrop behaviour and you use "Is dragging" it is triggering on just a mouse click as well as when being dragged. Which seems wrong as you already have a condition for "On drag start" which you would expect to trigger on mouse click and "Is dragging" should work only with mouse down for instant.

The problem with having "is dragging" trigger with mouse click is if you are making a snapping functionality the object snapping will move as you click it. And also the functionality doesn't seem to match what you would expect when the word "Is dragging" is used.

Attach a Capx

https://dl.dropboxusercontent.com/u/109921357/DragDrop_bug/DragDrop.capx

Description of Capx

A sprite with dragdrop behaviour that will snap to the mouse position when "Is dragging"

Steps to Reproduce Bug

Single click anywhere on the sprite and it will trigger the "Is dragging" and jump to the position. But single clicking the sprite should not be considered dragging.

Observed Result

Sprite jumps to mouse click position

Expected Result

That nothing would happen, meaning the sprite would simply stay put.

Affected Browsers

• Chrome: (YES/NO)
• FireFox: (YES/NO)
• Internet Explorer: (YES/NO)

Operating System and Service Pack

Windows 7

Construct 2 Version ID

r207

drag means it will move with mouse you dont need to tell it to move to that position, you have to do "on drag start" set position to mouse.x and mouse.y to center it, then it will move by it self thanks to the dragndrop.

drag means it will move with mouse you dont need to tell it to move to that position, you have to do "on drag start" set position to mouse.x and mouse.y to center it, then it will move by it self thanks to the dragndrop.

I don't agree with you, because if you look at the normal behaviour of any program, like your browser and you press and hold the mouse button down on the top part of it you can drag it around.

If it worked like the dragging behaviour in C2 you could press anywhere on the top bar where you drag it and the browser would jump to the mouse cursor position, which I at least, wouldn't refer to as dragging the window around. I think its normal for anyone when the words "dragging something" is used, that you would expect a behaviour like you see in windows and not stuff suddenly jumping around depending on where you click.

So "On drag start" is not a solution as I see it. Because the behaviour you expect is nothing like it is in C2 currently.

what you mean is: if the object is not moving and it was a single click and release then "Is dragging" should not be triggered, but if the mouse click holds for a sec then "is dragging"?

what you mean is: if the object is not moving and it was a single click and release then "Is dragging" should not be triggered, but if the mouse click holds for a sec then "is dragging"?

Well what I mean is that it should work exactly as dragging a window/program/browser around in Windows. So "Is dragging" should trigger when dragging is currently taking place, as you would expect from the name "Is dragging". As you mentioned yourself with "On drag start", that could to some degree be triggering when a click happens, even though it still wouldn't be correct in my opinion. Because from the name "On drag start" it would be more correct that it triggered the moment Dragging was happening and not when a mouse click happens, because a mouse click is not a drag event, but a click event. But it would be more correct I think if "On drag start" triggered when a mouse click was encountered rather than "Is dragging". Because "On drag start" is a trigger once condition like "On created" etc. Where "Is dragging" is a trigger that is tested against every tick, so it shouldn't activate on a trigger once condition in this case.

I agree, but to make it clear for the community and scirra (they like simple stuff)

Expected behaviour:

• Drag SHOULD ONLY start if Mouse is hold and moves or it is hold in the same place for a sec, click and double click shouldn't trigger drag.
• "Is Dragging" shouldn't start if i do just a click (release the button in less than a sec)

Put something like that in the description.

This is not a bug, it's by design, you're asking for a behaviour's new functionality, not for a bug fix, so better post it to Construct 2 General forum as a feature request, but i don't think that everyone will agree with your vision of how dragdrop should work, just imagine how many projects are already rely on the way it works right now.

This is not a bug, it's by design, you're asking for a behaviour's new functionality, not for a bug fix, so better post it to Construct 2 General forum as a feature request, but i don't think that everyone will agree with your vision of how dragdrop should work, just imagine how many projects are already rely on the way it works right now.

Not sure what you mean or how many projects would be affected. In theory the only change is to make "Is dragging" not trigger on mouse clicks. Despite that I don't see why anyone would disagree that the dragging behaviour in C2 shouldn't work as it does in every other single computer application out there, including C2 it self?

Isn't it more important that things work as you would expect them to rather than trying to invent your own way of doing it, especially when its been done like that for ages and is expected behaviour for anyone using a computer today. Im sorry but I don't get your point why this should be suggested as a new feature, unless you ofc is correct that it is made this way by Scirra, because they believe a dragging behaviour like in C2 is much better than the normal way, but I seriously doubt that to be the case.

"Is dragging" not trigger on mouse clicks.

Let's say, in my project i already have an event "is dragging" that should trigger on mouse click, me and everybody use it like this since r78, if this will be changed i need to rewrite my project. Now let's say it's not about me, about 10-100 or more c2 users. So a breaking change, that will affect almost everyone who use dragdrop, like this, can be applied only if this change will fix a major bug, "dragging behaviour in C2 should work as it does in every other single computer application" is not really a major bug.

> "Is dragging" not trigger on mouse clicks.

>

Let's say, in my project i already have an event "is dragging" that should trigger on mouse click, me and everybody use it like this since r78, if this will be changed i need to rewrite my project. Now let's say it's not about me, about 10-100 or more c2 users. So a breaking change, that will affect almost everyone who use dragdrop, like this, can be applied only if this change will fix a major bug, "dragging behaviour in C2 should work as it does in every other single computer application" is not really a major bug.

Yes of course if a program rely on the dragging behaviour to work with mouse click it will cause problems if fixed and its annoying.

Its not about it being a major bug or not but whether the behaviour works as intended and it might very well do that as Ashley haven't commented on it, so you might be right that it works as they thought it should and then ill disagree with that, but can accept it.

But a lot of bug fixes and new features in C2 might cause problems in projects as C2 is being developed on the fly. Meaning when I bought it, it couldnt do half the stuff it can now. Looking at the page where you download C2 there are links to a stable version and a beta version. How many programs do you know of that you buy, that constantly release Beta versions? they release updates or patches to fix an already fully functional program with all the feature already available. This is not to say that the way Scirra does it is bad, just that when you release a program this way, making fixes and adding new features all the time things can go wrong that annoys users and causes them to having to change certain things.

For instant I have not long ago made a lot of bug reports regarding the video object causing all sorts of problems, where I had to make lots of workarounds to make my program work. Then I made a report about some audio problem and video, that was fix in r207 and suddenly most, if not all, the other video problems that I made bug reports for have been fixed as well, even though its not stated in the r207 release, so now my program contain a lot of workaround code that needs to be removed. Yeah its a bit annoying now, but its much better that these things now work as you would expect them to whatever the changes Scirra made in r207 that solved them. Then I should complain about that to Scirra as well, because I have to remove my workarounds in my project? that would make little sense, I think its great that they are now fixed.

Closing as won't fix: it is by design that the drag and drop behavior enters "dragging" mode upon the first mouse down (or touch start) event on the object. The reason the object jumps is because you set it to the mouse position disregarding the offset between the mouse and the object origin, which the drag and drop behavior preserves.