I want to execute an event dispatcher after detecting a drag and pass an arbitrary Visual/Payload to the Operation, but doing so makes the drag operation extremely unstable.
It appeared to work fine when Create Widget was called internally or when a self-reference was used. However, because I wanted to keep the drag functionality independent, attempting to implement an external reference introduced random delays before the drag actually started. In the worst cases, the drag would only begin after the input had already ended.
I am already completely disappointed with UMG, but bad things are still happening, so I still need help. How can I make dragging work correctly while referencing the Visual/Payload?
the instability almost always comes from what you put in the payload, not from the dispatcher itself. the drag drop operation is managed by the drag layer, and anything widget shaped you stuff into it fights that lifetime.
rules that make it stable:
payload carries data, never widgets. make the payload a plain object or struct reference, an item id or soft reference is enough. the drop target resolves the data and builds whatever visual it needs. passing an externally created widget as the payload means umg reparents or garbage collects it mid drag, which reads as lag or a dead operation.
the drag visual is created in on drag detected from a dedicated widget class, set its data in pre drag. do not feed it an existing widget from somewhere else in the hierarchy, that widget is still owned by its parent panel and now two containers think they own it.
keep the event dispatcher on the source widget class, bind to it in the drop target, and unbind in on drag cancelled as well as on drop, missed unbinds accumulate listeners and the whole drag system degrades over a session.
if the visual must literally be an existing widget (rare), hide the original, and let the drop target rebuild its own copy from data on drop, rather than re-parenting the dragged instance.
It appears that unnecessary and unexplained restrictions once again existed.
Drag-and-drop is supposed to make the widget itself function as a container, so the fact that doing so breaks it is completely ridiculous. Since the goal is to move the widget, it stands to reason that you would use that widget. Creating a dedicated data container for every single item you drag is a complete waste of time and shouldn’t be necessary.
Well, I can guess the reason why that can’t be done. The people who designed UMG tied the trigger to an input event, so it stopped working if there was a 1-tick delay. That is why everything had to be handled within OnDetectDrag, and as a result, all flexibility was completely lost.
Put a print string in there. My guess is its called on tick so youre creating 1000s of duplicates. Or if that crashes as i recall print strings not working with slate. Put it on the visual construct.
