I tried to implement a drag event using the Common Button, but mouse events are not firing, so I cannot trigger the drag operation.
The button event does not fire, but the cursor event does. So, events like OnMouseMove will occur.
However, even among those events, On Mouse Button Down and isPressed do not function, and the OnMouseMove event is suspended while the button is pressed.
This shouldn’t happen with standard UMG. Does anyone know a solution?
Wait a minute…Right Click seems to be working. But what I want to use is Left Click. I can’t understand.
Hello @SemanticRain619 ,
Could you share some screenshots of your widget setup and the Blueprint/code you’re using? That might help identify where the issue is coming from. Also, an example of the behavior you’re trying to achieve could help provide additional context.
I will be waiting for your response!
I’m stuck at the stage before I even start making anything…
For now, what I want is for PrintString to work from this event. By using the left mouse button.
Hello again @SemanticRain619,
I did some research on this and found that one possible workaround is to add an invisible Border behind the Button and use it to capture the mouse event. To make sure the Border remains invisible, you can set the A (Alpha) value of its Brush Color to 0.
I also found that, according to comments from the developers,the recommended approach is to use OnPreviewMouseButtonDown instead of OnMouseButtonDown. The main difference is that OnPreviewMouseButtonDown uses tunneling, while OnMouseButtonDown uses bubbling.
In simple terms, tunneling means the event travels from parent widgets down to child widgets, while bubbling means the event starts at the widget that received the input and then propagates back up through its parent widgets.
I also came across several older community posts discussing the same behavior, which I’ll leave below in case you’d like to take a look. While some of them are a few years old, they all point to the same solutions mentioned above.
Hope it helps!
Thank you for the detailed information. It is disappointing that the same issue has persisted for years without being fixed.
I addressed this issue by creating a dedicated user widget to trigger drag events. However, it’s a relief to know that the approach of capturing mouse events outside of the button itself wasn’t wrong.
