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.
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.
Select node? Addicted.
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:
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:
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 You sure this cannot be simplified / macroed in a way?