We have a issue where when debugging a blueprint breakpoint, mouse click + drag behaviour does not work as expected:
- Cannot Right Click+Mouse Drag to pan blueprint editor graph, cursor moves but no graph panning occurs
- Cannot Left Click+Mouse Drag to change window layout, cursor moves but editor panel does not change size
- Mouse click behaviour (pressing buttons in the Editor UI) works as expected
This occurs even on other editor windows, but does not occur on windows from other applications. Cannot reproduce on an empty project.
Is there a straightforward means to find what logic/slate window is eating the event? If not, where would I start debugging for the handling of a mouse-drag event?
Thanks!
I would suggest starting with the widget inspector and turning on mouse events tracking for the events you’re interested in. This should get you the widget that the mouse thinks it is interacting with, and breakpoints can be set from there.
Depending on the widget, there may be some wildly different areas to put breakpoints, so determining the SWidget in the path is probably the best place to start.
FMouseDeltaTracker is where the viewport inputs should eventually go through for drag operations (your first case)
Window layout should eventually hit SDockTab::OnMouseButtonDown (your second case)
Mouse clicks generally operate off of mouse up events, not mouse down, so I suspect the culprit widget has an implementation for mouse down that is causing the drag operations not to start, but the mouse up to process as you expect.
Thanks for the fast reply!
To confirm, this is what you’re talking about when you refer to “widget inspector and turning on mouse events tracking for the events you’re interested in.”?
[Image Removed]
If so, I can confirm it’s still the SGraphPanel (SGraphEditorImpl.cpp) that’s getting the event both in default “Correct” case (Editing graphs outside of PIE) and the “Bad” case (attempting to Pan the graph in PIE while a blueprint breakpoint is being hit)
That’s the one. It’s good news the right SWidget is getting it - you can start debugging through from there to see if there’s something unexpected taking the mouse down and handling it where you wouldn’t anticipate.
I realized the mouse delta tracker examples is more for the viewport based widgets than graph editor. SNodePanel::OnMouseMove I think should be the spot.
Ah, we got to the bottom of it. We had custom logic that implemented IInputProcessor and was returning true for HandleMouseMoveEvent in certain cases. I have to confer with my colleagues if this is intended behaviour.
Thank you for your help.