really interesting, I should give this a go some time. thanks for the details!
1 Like
So I’m considering using borders right now and was wondering, how do you trigger border hovering when they don’t have that event?
I override onMouseEnter / Leave for the base widget class.
1 Like
oh, neat.
may I ask how about keyboard navigation, since borders aren’t focusable?
The root of the widget is focusable.
1 Like
oh snap, of course!
thank you again 
So I was trying to use borders instead of buttons to fix this issue I’m having, where I want to be able to, while in a menu, detect input mode as keyboard or gamepad to show the appropriate button icon
(described here: Arrow keys don't trigger any key event when input mode is set to game + ui (or just ui) - #10 by Seda145)
but it turns out that if any sort of widget is capable of being focused, as soon as it’s focused it will automatically change the game mode to UI, and disable any default UI navigation key (keyboard arrows, gamepad d-pad, etc) from triggering key input events in any blueprint, so any attempt at detecting input doesn’t work while I’m navigating a menu.
do you have any form of input method detection to change button icons in your custom ui?
1 Like
Never did anything with keyboard navigation in mind. Not as a main goal.
but it turns out that if any sort of widget is capable of being focused, as soon as it’s focused it will automatically change the game mode to UI
The input mode is not changing. If you’re in the Input Mode Game & UI, the focused widget gets the priority to process the input. If unhandled there, the Player Controller will have a go. Standard stuff.
That’s how it has always worked. I took it for a spin and something must have changed recently. It seems that widgets lose focus in a weird way.
- in the controller:
- in the widget:
This will Print both messages only if I force the widget to keep focus:
But the widget stops processing stuff due to focus lost. I mean, technically speaking, getting the attention of the controller should make the widget lose focus.
This is something that the regular buttons are really good at - stealing and keeping focus. I developed my UI in order to avoid that. You’re doing the opposite thing.
do you have any form of input method detection to change button icons in your custom ui?
That should be happening in the onFocusReceived.
Not sure if that would work in your case, but you can always fall back on dictating an explicit behaviour:
Above, the icon is changing during onFocusLost / Received in the customBorder.
This also gives you direct control over where the focus goes:
Never fully understood how Escape and Wrap rules are supposed to work outside of containers. 
I have suggested using an Input Processor (“FSlateApplication::RegisterInputPreProcessor”) in the related post. Because if you want to update the entire UI and not just the focused widget, you need this.
Wasn’t Unreal 5 going to improve this?
I’ve also rolled my own entire input handling and menu navigation, but in one case it seems I had to use a built-in button and I managed to work around it, but now I’ve ended up with a reproducible bug that’s just a showstopper for me… guess I’ll try to remove the button widget entirely, but I’m trying to stick with 100% blueprints here…