There are two annoying bugs I am having associated with UMG:
Focusing TextEdit Input sometimes stops character movement
When I press Enter, I focus my chat window TextEdit input control. If I am just moving with WASD, I can focus the control and it doesn’t interrupt my W key from running me forward (this is as InputModeGameAndUI). I have a mouselook feature, where the only way to get it to work properly was to set InputModeGameOnly on RightMouseDown and then revert back to InputModeGameAndUI on RightMouseUp. If I mouselook at all, pressing Enter to focus chat will stop my character dead in its tracks. It stops processing the W key which is down. I’ve thought of a hack in Tick that would poll if W is down and apply movement, but really don’t want to go that route.
Tab and Arrow Keys
I am unable to bind Tab and Arrow Keys in my game, as UMG uses them to steal focus. If I use these keys to run, and press Enter I have the stop dead in tracks bug mentioned above. But then pressing Enter again to lose focus on chat and pressing Up key starts cycling through other TextEdit Widgets on the screen.
I have set “Is Focusable?” to False on every Widget. Things like TextEdit do not have this property, and still steal focus. I have set other properties, such as not drawing the focus dashed borders around selected widgets.
In my tab binding, I tried setting InputMode to focus a nullptr Widget, but it didn’t work as I’d hoped. I read about bEnableKeyboardNavigation or something, and am considering patching the engine to always return false if I have a global setting to disable UI navigation.
Should future versions of the engine have a global runtime setting that will completely disable UMG keyboard navigation (tab, arrow keys)?
Movement should always be interrupted if you focus a text edit widget. It’s going to eat all the text keyboard keys until you’ve shifted focus elsewhere. That’s the behavior I would expect on any game.
As for the ‘default navigation’ rules, you can override the behavior by providing a new navigation config.
Though it looks like we don’t give you the option to disable Tab for Next/Shift+Tab for Previous. Will make a note to fix that for 4.12.
To get around it now - You could pre-process the input, by registering a FSlateApplication::Get().SetInputPreProcessor(), you can use that to access any key before slate looks at it and do something else with it and prevent further handling of the key if you wish.
Thanks I will look into those two APIs. I hope you do address the Tab in SetNavigationConfig for 4.12, shouldn’t be too big to patch I’d imagine.
As far as movement being interrupted when text widget is focused, I can inform you it does not, it has the inconsistency I mentioned. A lot of games have weird UI quirks though. I know in EverQuest if you run and press / you’ll start autorunning.
Here is code for anyone else that may run into this issue. It works for me in 4.11.0 and doesn’t seem to have broken any of my functionality.
In the Editor, Create New C++ Class -> None, FTabInputProcessor