Ignore keypresses while typing in UMG widget

I have a UMG widget with a TextBox so the player can enter text. But while I’m typing characters, other events that execute while those characters are being pressed fire. For example, when I type a “1”, it activates an ability on my hotbar (in the first slot). It’s a little weird that this doesn’t occur with “space” though since that makes me jump. Seems to only affect actual characters.

Is there any way to prevent events from firing from key events when the user is typing in a TextBox?

On your player controller you need to set input mode to UI only. That should stop your game functions from firing at all. So wherever the script is that creates the textbox widget, set input mode UI only, pass it the widget to focus.

Passing *Handled *in the widget’s *onKeyDown *should also work well enough.

make a boolen and call it “Is Typing” and hook it up in the player controller inputs with a branch if true “Is Typing” do nothing if false executes the skills or whatever.

and in the Widget, find an event called “on widget focus” and hook up cast to controller and set “is typing” to true and find another event called “on event focus lost” and also cast to controller and set to false.

This seems like it will work, just gotta add a UI button to close the widget (and set the input mode back). I thought I tried that before without success… weird.

I really wanted this to work - I prefer this to setting the input modes. But it didn’t work. Maybe because that widget is not the one I had set as focus in my original “Set input mode game and UI”? I’m not sure. It seems the onKeyDown is never called in my widget.

Seems like the same problem as above - On Focus Received and On Focus Lost are never executed. Having a boolean to handle this on the character seems a little messy as well, though I appreciate the suggestion.

Is the input for this in another widget? When typing in Editable Box, the keystrokes are not sent to the PC, for example. I’d assume other widget do not get them either. Or is this all in the same widget? As in, the 1 input widget houses the text box as well.

The input is in the Character actually - does that make a difference?

It shouldn’t but I’m trying to understand your setup so I can reproduce it on my end. And here’s the thing, on my end the Editable Box consumes input as expected, the key events in the player character do not trigger. I can either punch in 1s into the box or print a string from the player controller / character.

So what is unique about your setup? You pass *Unhandled *in your widget making text input tunnel through and reach other blueprints?

No, I wasn’t using any overrides at all. I created an empty project and replicated my setup, though I must have missed something because I can’t reproduce the issue there. The context is

In Character: Pressing “1” activates an ability on the hotbar
Pressing “Z” sets an initially “Hidden” menu to be “Self Hit Test Invisible” (or reversed if the menu was already visible)
The menu contains many child widgets with lots of combo boxes and text boxes. Clicking the first text box and typing a “1” both types a “1” and activates the ability.

If I put an “OnKeyDown” override in the main menu, the function only executes when I am not typing in a TextBox. But even when it does function (if I just click anywhere in the menu and type a “1”) and I pass “Handled”, it still activates the ability. Its like this response is being ignored.

If I put an “OnKeyDown” override in one of the child widgets containing an input box, it is never called.

Have you tried passing focus directly to the text box rather than the widget that owns it?

Yeah, doesn’t seem to change anything. Not that I should have to do that anyway.

It’s ok - I’m willing to ignore the problem for now. The menu in question is used for development and wouldn’t make it into the actual game anyway. Just hope I can figure this out when I have REAL menus to deal with

Do consider posting an update if / once you figure out what was causing it, a bit baffling to be honest.