I have a problem where clicking while my game is running causes my UMG widget (the only one onscreen) to stop handling inputs properly. OnKeyDown stops firing, although it works just fine if I never click the mouse. I presume this is because when I click, something that isn’t my widget is taking focus away from my widget.
I can’t use the Widget Reflector to debug this because clicking anywhere on the game in PIE causes the editor viewport to take focus. As far as I can tell, this doesn’t happen in Standalone/Shipping, so it’s not really relevant, but it also prevents me from using the Widget Reflector to diagnose the issue.
I’ve used the “showdebug Input” command to see what’s at the top of my input stack, and there are two InputComponents (I would expect one since I’m only adding one widget). One of them might be causing the issue, but they don’t have names, so I can’t track down what owns those input components.
I tried cranking my widget’s input priority up to 1000, but that didn’t help.
Input Actions seem to work just fine for my widget, even when OnKeyDown stops working. However, I have to use OnKeyDown to take advantage of the event routing system (there seems to be no way to determine priority when multiple widgets listen to the same input action).
I’d prefer to avoid debugging the engine code to figure out what’s happening when I click my mouse that makes my UI become unresponsive to keyboard inputs. If anyone knows of any additional debug or logging tools to diagnose issues like this, I’d really appreciate it!
Overriding those mouse events and returning Handled fixed me up, thanks! My widget doesn’t take up the entire screen, so I also had give it a fullscreen canvas panel marked Visible, otherwise the mouse events wouldn’t fire if I clicked on the game and my widget would still lose focus. For what it’s worth, I do call SetUserFocus, but I don’t call SetKeyboardFocus anywhere.
Fortunately, I didn’t need to override onFocusLost. It seems like my widget retains focus even when alt tabbing out of the window and back again.
It also seems like I was mistaken in my original post – listening for input actions seems to respect the widget’s Input Priority. I find this makes listening for input actions a far more robust way of handling input since they still fire if the widget doesn’t have focus.
listening for input actions seems to
respect the widget’s Input Priority
Afair setting input priority is a must when you work with user widgets embedded in a master container. The parent widget can set input priority for any of its children so they act orderly. Widget input priority has little (nothing?) to do with input priority you see on actors.
It’s either the PC or the widget in focus that has the input. Each of those two entities can then manage input priority between either actors or widgets accordingly.
is the widget’s root element’s isFocusable flag true?
I presume this is because when I
click, something that isn’t my widget
is taking focus away from my widget.
You could override onMouseButtonUp/Down in the widget and pass Handled - this should prevent tunnelling to the Player Controller and losing focus. Essentially, for as long as the click registers with any Visible elements, the widget stays in focus. Any unhandled clicks are passed on to the player controller. You can also fire SetKeyboardFocus here just in case.
You could also override onFocusLost in the widget and fire SetKeyboardFocus - this is pretty brute force but can help when the application loses focus, as in alt-tab, for example.
That finally solved my problem!! Thanks a lot. I did the same thing - Override mouse up and down function and returned handled. I also changed the canvas to visible.