UMG button list keyboard focus lost after reaching last button

[fael097]

Hi, I have a simple widget with a few buttons, and I’ve set up keyboard focus so I can select them with my keyboard or gamepad. problem is, if I’m focusing on the last button from the list, and press down once again, focus won’t go back to the first button on top, but the buttons will lose focus all together and I won’t be able to focus with keyboard/gamepad again unless I open the widget again.

I thought the focus was supposed to go back to the first button by default? am I doing anything wrong?

[Everynone]

Note the icons on the first and last button in the list:

These are the navigation behaviours modified from the defaults. Below, when the last button receives a Down navigation request, you can tell it what to focus on next:

In this case Down leads to the Top button.

If you do the opposite for the top button, you should be able to navigate both ways without ever escaping that vertical box:

Using Explicit also works if the buttons are named. But a custom function allows to intercept the transition if necessary.

---

Now, if someone told me how to use Wrap there, that’d be swell!

[MostHost_LA]

Not sure what OP is exactly after.

But to be able to properly handle gamepad you need to code an override for key press and direct focus based on the input received.

I have it set up by creating a button widget I use for buttons that already includes the necessary override events/calls
Every UI element is its own customized widget with additional options - which enables a lot of other possible things on top of proper navigation…
Like changing the look/feel by just editing component’s default values, for instance.

Read as. Make your own wrap

[Everynone]

I think I got it right, fingers crossed.

@MostHost_LA

Read as. Make your own wrap

I simply do not know what Wrap is for and / or how to use it. I have no beef with passing focus between widgets manually.

To me it sounds as if Wrap was supposed automatically switch from 0 → Last child & Last → 0 when navigating with keys / gamepad but that does not seem to work.

Explicit works great if you want to pull off something uncanny, navigate to a specific part of the interface without using mouse pointer. And Custom calls a function where you can handle additional transition methods.

[fael097]

thanks a lot for the detailed instructions, that’s exactly what I needed!

[fael097]

“which enables a lot of other possible things on top of proper navigation…
Like changing the look/feel by just editing component’s default values, for instance.”

That sounds interesting, probably something I’ll need.

I’ve been trying to make buttons look as if they were being hovered when they have keyboard focus, instead of the dotted outline, but without any success so far.

I also wanted to be able to change button style for every single button I have in my game, without having to go through each one of them, but I’m not sure how can I store their style in a single variable or something like that

[Everynone]

I also wanted to be able to change button style for every single button

It’s this:

I’ll admit I abandoned buttons quite a long time ago. They’re good for basic clicking and absolutely horrible for doing anything else. As soon as you need a button to do something it was not explicitly designed for, you hit a brick wall.

Wrappers work wonders. You take whatever native UMG element and wrap it with a User Widget, add functionality, data, event dispatchers and whatnot. And if you ever need to maintain that widget in any way, you change that one widget rather than visit numerous menus and/or fiddle with styles.

[MostHost_LA]

@Everynone

I simply do not know what Wrap is for

My assumption for it was that it would allow full movement on all sides. Because left/right need special attention too when using a grid list or similar.

@op
Basically what @Everynone isn’t directly saying is that the default implementation of all widgets parts on their own as they are - flat out sucks.

This, however (for once), is by design.

By making the component as slender as possible you improve usability/programmability.

Whereas, always including every possible case scenario is bulky, unmanageable, and 90% if not 99.999% of the time isn’t needed.

Now to your issue at hand with the dotted stuff.

Step one is to disable auto focus stuff. Only way to truly remove the dotted line - if you search you’ll find specific answers.

Step 2, for an image hover, is to create a custom button that contains an Image, and assign an “hover” that gets swapped at runtime.

In my case, injust called this the wp_button (wp = widget part) and I use it as the “default”, because all of my UI buttons need some sort of a graphic.

In your case, or in someone else’s case, maybe the button really only needs text, and the default messy windows form look from the 90s is perfect for them. So they wouldn’t create a button with an image.

Anyway.
The process for handing custom input via BP is not an easy to implement thing. It’s not hard either, but you should probably set aside a week and only really try it after defining some standards / reading up on UI and UE4 best practices.

In the end, it’s really (like almost always, unless you are an engine developer, damnit!) “whatever works” if you are making just a one off… so trials and error does get you to accomplish the task (hence the arbitrary week time to figure it out).

[User OP had an unfortunate naming choice. Should probably ask the powers that be to change that tag to always refer to the post maker…]