On the image I have set up several widgets in a list which can be focused by navigating with the arrow keys. the setup is as basic as possible in a clean project.
As seen the bottom left button is focused and when I press the down arrow key I expect focus to shift to the row below it. However, this only works if I focus one button to the right first, else slate does not detect the button below what is currently focused.
Apparently it is “too far away” or maybe too far to the right… or whatever. I just want this directional detection to be a lot more sensitive and reliable because I will be disabling and enabling generated buttons and must ensure that all widgets are reachable through the keyboard. Can this be done?
edit * long distances work ok ish but diagonal seems to be an issue. I wouldn’t want to limit designers by telling them diagonal is unsupported now?
Each action is a separate widget with 2 key selectors inside. If secondary is focused and I press up or down, focus goes to primary. I guess it happens because it focuses the sub-widget, not a button in it, and so it goes to the first one.
I can confirm that nothing but the buttons is focusable or interactable.
I added another panel to the left on it, horizontal navigation goes OK as illustrated and moves from panel to panel without skipping buttons:
@Tuerer I figured out what causes buttons to skip. If you add Userwidgets containing buttons as rows to a scroll box this will happen. It will work correctly if you add a Vertical box as parent to all the rows directly within the scroll box. Sounds like another engine bug. Funny, this also solved a bug which allowed slate nav to focus disabled widgets which was impossible to debug.
What remains is that diagonal navigation sometimes fails depending on where buttons are positioned.
Hmm, this sounds exactly what I’ve been looking for, I’ll try that tomorrow, thank you!
While we’re at it, do you happen to know the way to focus on a button once the widget is open? I mean, to instantly have a selection frame active. I can SetFocus() to a button, but I can’t press in unless I move the selection away from it and then return it back.
Unsure, I ran into tons of trouble with Slate and replaced or hacked most of it to match my requirements. The moment I use SetFocus on a widget I know I can read key inputs from OnMouseDown / OnKeyDown without further action.
Yes, this does solve the focus issue; however, it creates another: the scrollbox does not scroll automatically when focus shifts to the elements out of the scrollbox bounds. I guess because the engine treats the added vertical box as the same element, and so the scrollbox does not shift.
I found it does scroll but at some point might decide to jump out. I think this can be avoided by handling the slate key as an input event before it leaves the scrollbox or it’s direct UserWidget parent. You can do so in response to the scrollbox offset (min / max). What a waste of time slate is…
This post solved half of the question as it turned out there were two things going on at once. The remaining problem (diagonal navigation) will be discussed in this post:
@Tuerer I figured something out possibly related to your problem. In some situations SetFocus won’t work and it will silently fail. Apparently (as a workaround?) engine code uses the following to delay SetFocus with 1 frame:
FLocalPlayerContext Context(InPlayerController);
if (ULocalPlayer* LocalPlayer = Context.GetLocalPlayer()) {
TOptional<int32> UserIndex = FSlateApplication::Get().GetUserIndexForController(LocalPlayer->GetControllerId());
if (UserIndex.IsSet()) {
LocalPlayer->GetSlateOperations().SetUserFocus(InWidget->GetCachedWidget().ToSharedRef());
}
}
It’s still fully fcked if you happen to have a vertical box containing UserWidgets, of which one UserWidget type is focusable and the other type contains focusable UWidgets. Focus will skip from uwidget to uwidget, ignoring hierarchy. Well it’s 9 months later UE5.1.1, anyone else? Sick of it
