Question Drag events not working at runtime.

I've been wondering how to get the Drag events working at runtime

I've created a card system that uses drag and drop for games like solitaire which works great. While in the process of making it, I found that the built in drag events do not work and need something else to get them going other than registering for the callbacks and creating a draggable element. The event system will not trigger any of the 5 drag events.

If I look at this document page https://docs.unity3d.com/Manual/UIE-Events-DragAndDrop.html. I find that it uses an editor only class DragAndDrop. After reading this thread https://forum.unity.com/threads/how-to-use-draganddrop-with-visualelements-and-manipulators.684382/ I find that I need to use that class to have the events trigger. Also the example for runtime drag and drop from https://github.com/Unity-Technologies/UIToolkitUnityRoyaleRuntimeDemo doesn't show drag and drop using those events.

So I created a DragManipulator that the cards use. It registers for MouseDownEvent, MouseMoveEvent and MouseUp event. While being dragged I get all the VisualElements from the root and check if the cards bounds are overlapping any that match and add them to a list. I then check that list to see which one is the closest. For this type of game it works great.

Since UITK got Input System support I have been switching over an inventory/item system over to UITK. I don't need the same bounds check and would like to use the built in drag events. What am I doing wrong? Do I not understand how those events work? Or is it something that isn't setup for runtime yet?

 

I just implemented my drag and drop system for inventory recently and I did it the same way as you - implementing Mouse Down/Move/Up. It's a bit of DIY but gets the job done and is pretty clean. The Drag events are probably still editor only.

 

Wondering how do you handle mouse up outside panel? Doing drag&drop manipulator as well and have this issue when you release mouse button outside. Dragged element remains in dragging state as manipulator do not get mouse up event.

 

You have to call target.CaptureMouse() in MouseDown and target.ReleaseMouse() in MouseUp which will register th events even if you leave the dragged element. This will also prevent the dragged element from "leaving" the mouse.

 

Yep, it works if mouse is over UIDocument panel (Game view), but it doesn't if mouse up happens outside it, lets say Hierarchy tab (in editor) for example.

 

I just have a top level calling Input.OnMouseUp in LateUpdate to do the actual force MouseUp method call for the cleanups, and MouseUpEvent in potential drop elements for actual drop handling


On to my own question:
Kinda wondering what's so special about ve.AddManipulator(new MouseManipulator)
Im seeing it being used in the TextureDragger example (albeit this is for editor)

@Chris-Trueman In some post, you said you used MouseManipulator for a same window case, and did NOT use it for inter-window drag drops
Inside MouseManipulator, in the example, it's just some more RegisterCallback<MouseDownEvent> etc
So yeah. Why not just directly do the RegisterCallbacks in the element. Why use MouseManipulator?

Is it just to make things "neater" ? Fair enough
But i want to handle the callbacks from the outside, and if i have to use a class for it, then... i have to make a delegate in the class, that gets triggered when the MouseDown etc are called inside the MouseManipulator. And from the outside, register my specific method to this delegate. Is this the proper usage?

edit:
Late to realize that MouseManipulator is Manipulator. Searched and found exactly what i'm wondering about:
https://forum.unity.com/threads/why-are-there-multiple-event-metaphors-in-uielements.688552/
Hurrah to ClickEvent btw!
(^ conclusion: Manipulators are optional)

 

@Crouching-Tuna Manipulators are optional yes. Unity is currently deciding if they want to scrap them completely. I used them to clean up the code(neater) for the card class, the drag and drop would have bloated it up too much.

This seams like it would work. As for it being proper usage? No clue, if it works, it works though.