so many different links of events… […]if there’s a way to approach this in a simpler fashion
Let me clarify; what I originally suggested is suitable for a situation where you want both - dragging a widget and dragging an actor around simultaneously.
Spawning and dragging after an interface click is easier as we don’t care about widget position:
The above should be in the Player Controller. Here the button was set to Mouse Down so it releases focus even though its Up never happens and the controller can take over:
So,. the whole reason we needed a separate Drag Operation Blueprint is to get the ‘dragging position’ from them? Because we can’t get the current position from mouse because of the UI / Player Controller ‘fighting’ issue?
It’s somewhat convoluted how input bubbles between widgets but yeah, pretty much. Most of the time, we’re in this mode:
Interact with a widget and choose what happens with the input next (here, a click):
Pass Handled to consume input & terminate. Pass Unhandled so another widget may process it (if they’re underneath, for example). If no other widget Handles it, the Player Controller will get it. So yes, you can click through widgets and get both the PC and the UI to manage the very same input.
However, the problem with dragging is that it does not let you return such reply.
Technically, you could fill the entire screen with another transparent widget, override onMouseMove and reply with Unhandled but that’s even a bigger hack than the original solution.
And it would make working with other UI elements awkward.