Drag and Drop Behavior Variance

Problem Description

General: Sprites with the Drag and Drop behavior function differently based on whether or not other sprites have the behavior assigned.

Specific: Sprites which have the Drag and Drop behavior that are moved or created in response to user input will drag immediately if and only if the first sprite ("first" based on what, I don't actually know) does not have the behavior. Adding the behavior to that "first" object causes all objects to be dropped (as opposed to dragged) immediately after movement or creation.

Attach a Capx

Test 1a https://dl.dropboxusercontent.com/u/18512418/BugReport/DD%20Touch%20Bug%20Test%201a%2C%20Control.capx

Subsequent tests provide additional data if needed (as documented below), but Test1a is the primary capx and may be altered according to the steps below to recreate the bug shown in Test1b.

Test 1b https://dl.dropboxusercontent.com/u/18512418/BugReport/DD%20Touch%20Bug%20Test%201b%2C%20Bug%20Demonstration.capx

Test 1c https://dl.dropboxusercontent.com/u/18512418/BugReport/DD%20Touch%20Bug%20Test%201c%2C%20Further%20Analysis.capx

Test 2a https://dl.dropboxusercontent.com/u/18512418/BugReport/DD%20Touch%20Bug%20Test%202a%2C%20Control.capx

Test 2b https://dl.dropboxusercontent.com/u/18512418/BugReport/DD%20Touch%20Bug%20Test%202b%2C%20Bug%20Demonstration.capx

Description of Capx

Test1a is a control, showing four sprites with graphics that look like dice, correlating to the order in which they are created via 1-4 simultaneous touches. Die1 does not have the Drag and Drop behavior, Die2, Die3, and Die4 have it. In response to 1-4 simultaneous user touches, Die1 is created but does not drag, Die2, Die3, and Die4 will drag immediately. Releasing all touches will destroy the sprites. This is all as expected (considering which dice have the Drag and Drop behavior).

Test1b is the same test, but with only 1 change: Drag and Drop is assigned to Die1 (as well as the other dice, like in test 1a). Now, after 1-4 simultaneous touches, no dice will drag. The behavior of all 4 sprites has been changed by the addition of Drag and Drop to Die1.

Test1c is not necessarily useful, and simply prevents the destruction of the sprites after touches are released. Its only purpose is to show that the Drag and Drop behavior functions correctly for additional user touches.

-----

Test2a/Test2b demonstrates the same effect, but using "set position" instead of "create object," and using two sprites that are already onscreen so that the bug is visible with a mouse instead of a multi-touch touchscreen (Test2 has also been performed with the "mouse" object only, instead of "touch," with no change in outcome.

In Test2a, which is a control, click to the right of either sprite in the white area and without releasing the mouse attempt to drag. Die1 will not drag, because it does not have the behavior. Die2 will drag, because it does have the behavior. This is exactly as expected.

In Test2b, both sprites have the Drag and Drop behavior. Now neither sprite will drag without first releasing the mouse and clicking on the sprite. The behavior of both sprites has been changed by the addition of Drag and Drop to Die1.

Steps to Reproduce Bug

• Step 1 - Preview the capx "Test1a" (aka "DD Touch Bug Test 1a, Control.capx")
• Step 2 - Place 4 fingers on a touchscreen and drag (the second, third, and fourth touches will drag their sprites)
• Step 3 - Within the capx, apply the Drag and Drop Behavior to sprite Die1 (this replicates the conditions of the Test2b capx)
• Step 4 - Place 4 fingers on a touchscreen and drag (no touches will drag their sprites)

Observed Result

The way Die2, Die3, and Die4 drag is affected by whether or not Drag and Drop is applied to Die 1.

Expected Result

For all dice to behave only according to whether or not that specific die has the behavior applied (specifically, I'd like all four dice in drag upon creation, as seen in dice 2,3, and 4 in Test1a).

Affected Browsers

• Chrome: YES
• FireFox: YES
• Edge: YES
• Safari: YES

Operating System and Service Pack

Windows 10 Anniversary 64 Bit

Windows 10 64 Bit

Android 7.0

Mobile iOS 8.3

Mobile iOS 9.3.5

Construct 2 Version ID

239 64-Bit

-----

Thank you!

Closing as won't fix: creating an object with a drag-and-drop behavior on a touch start is not a reliable thing to do - the drag&drop behavior listens for touch events, but by the time you create it the touch event has already fired. I'm surprised this ever works in any circumstance, I'd expect it to never drag when you create an object in a touch event. I don't think it's reasonable to expect objects to catch events that have already started firing. This should be reasonably straightforward to implement via events anyway.

[quote:1g6cl1gs]I'm surprised this ever works in any circumstance, I'd expect it to never drag when you create an object in a touch event.

The lack of predictability here was sort of my point I wasn't making a request that the behavior system be modified for my needs, but that the behaviors of seemingly unrelated objects are affected by whether or not another object has that behavior assigned. This is the only circumstance that I have seen of this, so I reported it as a bug.

But I agree, on a scale of importance from 1 to 10, it's about a 0.2