Annoying bugs with UMG focus (with Is Focusable? on all widgets false)
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.
User simply cannot bind Tab or Arrow Keys because UMG uses them for stuff
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 with arrow keys. But I'm not even sure if it will work, and still... what about Tab?
Should future versions of the engine have a global runtime setting that will completely disable UMG keyboard navigation (tab, arrow keys)?
Follow this question
Once you sign in you will be able to subscribe for any updates here