I have a scroll box full of dynamically created buttons (User Widgets with a Button and Text).
I am using gamepad and keyboard to navigate the list of buttons with up/down.
When the user selects/clicks a button they can then use left/right to increase/decrease the value associated with the button.
This works fine as long as the action input for left and right is not keyboard arrow keys or the d-pad on the gamepad.
I have tried getting all widgets of class user widget and setting is focusable to false, and also setting the navigation rule for the selected button to Stop.
How can I work out what is consuming the left and right input and prevent this from happening ?
It’s probably the slate system still trying to navigate away from the focused widget to another by using the default directional keys. I’ve seen this question a few times but I don’t remember myself what exactly causes it (I modified the slate system on my project to fix things). What method are you using / overriding to detect the input key?
I think you are right considering it works with any other key/s, I am using an input action I have just called Value_Change_Left for now and using the InputAction Value_Change_Left event on the button itself.
I think I have a workaround, in that upon initially selecting the button I can use ‘Set Focus to Game View Port’. This seems to take the focus off all widgets and left and right arrow keys work again. It does mean I need to handle the reselecting of the button (on value commit) elsewhere with a reference to the selected button.
Would love to know if there is a way to still receive left and right arrow key input events when a widget has focus.
Can you try overriding the OnKeyDown method on the widget instead of using the input action event?
This seems to still suffer from the same trouble if the button is focused.
However will mark as answer, as this does open up for the workaround of setting the button to not focused (when initially clicked) and then handling input via OnKeyDown within the same blueprint, which is a much neater workaround for me. Thank you for you help.
Also considered using a menu manager that handled all the input and setting the current focused button here, then when left or right pressed could call its on value changed function from here. This has the benefit of the input action not being called on every button that exists. I had avoided this as not all buttons share the same functionality, but I guess could use an interface. I couldn’t work out how to force a function to exist in a child widget via abstract function to do it that way.