Forum Discussion
Storyline 360 drag-and-drop issue: object moves away from cursor after state change
Hello,
or this interaction, I’d structure the triggers so the visual change happens only after the drag/drop action, rather than trying to reposition the object while Storyline is still handling the drag.
A clean sequence would be:
When the user drops the object on the correct target
→ Change the object to Drop Correct.
This is the point where the installed membrane should appear.
When the user clicks/starts interacting with the installed object
→ Change its state back to Normal.
Put this trigger before any subsequent action that depends on the state change.
Immediately after that state change
→ Reposition the object so its center is aligned with the pointer (if you're using JavaScript).
Allow the normal drag interaction to continue
→ The learner can now drag the small Normal-state object back to its original location.
when multiple triggers respond to the same event, Storyline executes them sequentially, so the order in the Triggers panel matters.
Hello ali066khan
I hadn’t seen your suggestion before posting mine. I really did try, but unfortunately, SL doesn’t allow you to place the JS trigger at the end of the sequence, regardless of the condition used to trigger it—it always goes at the beginning. So your clear sequence can’t be applied. Therefore, there’s an event missing to trigger this JS code. Unless you’d like to provide further details.
Furthermore, this doesn’t solve the problem (THE problem) of the misalignment between the clicked object (H328 pixels even though it displays the Normal state) and the cursor.
However, there might be a way forward.
Another two hours, and this Assistant still doesn't know any more than I do about how SL works. No progress, no results. I’m still running into the problem that I’m working with an H328pix shape that displays the Normal state of H48pix. The predefined states (in a drag-and-drop) apparently can’t be fully manipulated or accessed via JavaScript (I seem to recall having encountered this problem before). But if I give up on the drag-and-drop activity and use only triggers (Change the object’s state when the user moves the object onto… or when the interaction between the object and the target area ends…), I’m stuck there too. I’m giving up. Sorry ArminBaghaei
Don't give up yet, Thierry — your finding is actually useful, because it confirms why the JavaScript route is a dead end here. The two-object approach in my comment above sidesteps it completely: no predefined-state manipulation at all. One small object is the only draggable, and the big visual just sits underneath it, swapped by state changes on the non-dragged object. No JS, no drag-anchor math. Worth a quick test before you scrap the drag-and-drop.
Thank you so much for the suggestion and support. I have not tried your recom but speaking from my own experience, we cannot place JSs at the end of the list.
