Widget Input Key

Hey, is there any way to add different input key events to ui?

Widgets can override onKeyDown and onKeyUp and you can Get Key from its in Key Event.

1 Like

i tried to looking for how can i use onKeyDown but i didn’t found anything. can you give me some information about this function using?

You can fire the code where the Print String is or create a Custom Event in the widget and fire that.

Beat me to it. I like the select use and I can tell you love using them. :slight_smile:

Select node? Addicted. :slight_smile:

I made the same function like yours but when i press the selected key nothing happens.

Make sure the widget has focus (click on it first). Good question and answers, I learned something new. Wonder if there is a way to do this in a Select Case kind of way to handle more than one key press.

Make sure the widget has focus (click
on it first).

That’s one way to do it, yes. But it can be given to a target widget when the user opens the menu, or completely automated when the cursor enters / leaves the menu:

279064-capture.png

The above will switch the focus between the Player Controller and the widget. Mouse cursor entering the menu will now force the widget to respect key-presses, and the focus is released when the cursor leaves any of the Visible elements of the widget. This is great for a UI that is always visible, like a control panel that you only want to key-operate when the user is mousing it (like an interactive keypad / calculator, perhaps). Otherwise, the world gets to play and the Player Controller has priority.


Wonder if there is a way to do this in
a Select Case kind of way to handle
more than one key press.

Many, starting with this ham-fisted approach (with less messed up letter order ;P):

Upgrading it to an int keymap:

Or, ideally, an enumerator as this makes it easier to maintain and more readable:

2 Likes

Oh wow! Thanks so much, I actually tried doing a lot of that, switch on, get key, enums, structs, but always got connection errors. I think I’m just bombarded with all these possibilities, including arrays, loops, and data-tables, and never really used them and so don’t know the best way to handle something like this. But I will look this over for sure. This is exactly what I need for the fun little project I’m working on which currently uses all the key events in the level blueprint. Getting the transfer communication of buttons, texts, and background color to work between the widget and level blueprint was a monster in itself and after quite some time I miraculously created a loop within a loop to do a select case function involving a widget and two arrays, haha. Don’t want to be over-complicating things. It’s been a few days and now I’m looking in at like what? No comprehende.

Thank your reply! You helped a lot with it but I have a few more questions:

  • on the third image the variable type is “Widget Key Action”. I can’t find this. What could be the problem?
  • What the switcher default execution does? What happens when i remove it?
  • What the handled and unhandled functions does?

“Widget Key Action”. I can’t find
this.

It’s an enumerator I created myself - you can do it in the Content Browser. It’s a new data type you can then use anywhere in your project.

What the switcher default execution
does?

‘Find’ returns an int which switch is using; in the event of the ‘Find’ returning an int the switch cannot handle, it will fire the Default pin. In this very case, the Default pin will fire if the player presses something else than Q,E,R. The switch here defines 0,1,2 - if it receives anything else, it will fire Default.

What happens when i remove it?

You will be unable to pass Handled / Unhandled correctly (see below). I think it will compile but may throw errors at run-time)

What the handled and unhandled
functions does?

When the widget is in focus, it gets the chance to interpret input first. Handled / Unhandled lets you choose what to do with that input next:

  • Handled means nothing else gets to process this input - you want to consume it here and now. Even though there might be other elements using the same input, they will not have the chance to act on it. The widget handled that input and no other widgets / actors will receive it.

  • Unhandled - it will let the input bubble and other elements will get the chance to act on it.

Getting the transfer communication of
buttons, texts, and background color
to work between the widget and level
blueprint was a monster in itself and
after quite some time I miraculously
created a loop within a loop to do a
select case function involving a
widget and two arrays, haha.

Yeah, LB is notoriously annoying to communicate with. You’ve yet to qualify here:

… but you’re getting there :slight_smile: You sure this cannot be simplified / macroed in a way?