i have a question about Input between UMG and ViewClient

Development Programming & Scripting UI
, , ,
1

Hello.

​Once we’ve looked at the engine debugging and the various references,

Input priority

  1. Widget

  2. ViewClient (PlayerController)

​

If Input is processed in No.1, it will not come down to ViewClient.

So I did a test.

​I made a button with an empty Widget, and addedToViewport.

And by overloading OnKeyDown from UMG, we implemented it.

Put BreakPoint on OnKeyDown and run it.

​1. Click the button to be normal
2. OnKeyDown is not interrupted.

​

To solve this problem,

APlayerController::SetInputGameAndUIMode
APlayerController::SetInputUIMode

​I tested these two functions.

​First test: SetInputGameAndUIMode

  1. When playing, the input to the UMG is not entered (OnKeyDown)
  2. Press the mouse button to focus on the widget and press Input to enter OnKeyDown.
  3. However, even though Widget has processed the Input (Consume), ViewClient on the Game side is also processed.

​

Through this test, i realized that even with SetInputGameAndUIMode, the starting focus is not Widget.

​

Second test: SetInputUIMode

  1. When playing, the UMG will have an Input (OnKeyDown)
  2. The Input of ViewClient is filtered and not operated by the check of the boolean.

​

​

And the question is,

  1. Even though Input has been processed in Widget from SetInputGameAndUIMode, why is it descending to the ViewClient (PlayerController)? Can’t i stop this?

​2) Is it only by calling SetInputUIMode to process the input of the UMG? What if multiple UIs try to open at the same time, and all UIs try to operate the input?

​3) It is said in UE4 that if the input is Consumer in Widget, it does not go down to ViewClient. In UMG, there is no check to see if the input is actually Consume. Is there no way to do this?

  1. Why does OnKeyDown enter the Widget only when you click on a button in the widget even though you are in SetGameAndUIMode? Can’t you get both sides right in when you start playing?

Can I hear the answer to the above four?

Have a nice day.

Thank you.

2
  1. Even though Input has been
    processed in Widget from
    SetInputGameAndUIMode, why is it
    descending to the ViewClient
    (PlayerController)? Can’t i stop this?

In SetInputGameAndUIMode both Widgets and the Player Controller get a chance to process input with widgets receiving priority.

You can stop it be passing in Handled. This indicates that the input has been processed and will terminate to tunnel to other widgets that may be underneath and will not reach the Player Controller.

If I grant the widget keyboard focus:

276204-focus.png
276204-focus.png937×219 50.1 KB

And pass Handled when pressing Q:

276205-qumg.png
276205-qumg.png1136×345 65.8 KB

The Player Controller will not receive the call. The widget handled it, consuming the input. Passing Unhandled here, on the other hand, would process the input in the widget and in the controller.

​2) Is it only by calling
SetInputUIMode to process the input of
the UMG?

No, for as long as the widget has Focus, it will try to process inputs - for mouse inputs there needs to be at least one Visible element present. For keyboard, the widget can be Hit Test Invisible but needs the isFocusable flag to be true.

What if multiple UIs try to
open at the same time, and all UIs try
to operate the input?

You can’t have 2 widgets in focus so keyboard input goes to the one with Focus. For mouse it will depend on Handled / Unhandled - whoever is higher in the Z order and is Visible gets to act first and can consume it or let it tunnel to any visible UI layer below, potentially reaching the controller.

  1. It is said in UE4 that if the input
    is Consumer in Widget, it does not go
    down to ViewClient. In UMG, there is
    no check to see if the input is
    actually Consume. Is there no way to
    do this?

Handled / Unhandled, as above.

  1. Why does OnKeyDown enter the Widget only when you click on a button in the widget even though you are in SetGameAndUIMode?

Because the widget does not have focus yet, clicking a button shifts the focus onto the widget.

Can’t you get both sides right in when
you start playing?

You absolutely can - grant widget focus when it’s constructed:

276206-construct.png

3

Thank you for your answer.

4

May i have one question more?

I intend to make UI Mode and Game Mode.

If i press a key, UI Mode is toggled.

If UI Mode is on, Game Logic can’t receive Input.

for example,

When I click on the mouse or enter a key, No input is passed to GameLogic (PlayerController) even if no Widget is in AddToViewport. (maybe input will be just consumed)

if a Widget addToViewport, the widget will consume input.

If UI Mode is off, GameLogic(PlayerController) will be received input, even if widget is in AddToViewport.

Can i do that?

5

If i press a key, UI Mode is toggled.

If UI Mode is on, Game Logic can’t
receive Input.

tl;dr: Yes. Switching back to Game Mode input should be done in the widget since it’s the only entity processing input.

Let’s say you’re in the Game Mode input and press {M} (Player Controller) to open the Game Map and switch to UI Only Mode input. Now you can’t close the Map with {M} (Player Controller) because we switched to UI Mode.

The solution is to have the widget switch back to Game Mode. Essentially, make the widgets responsible for closing themselves.

6

Well, I see. You’re right.
If i switched from GameMode to UIMode, there’s no way get back to GameMode.

If UE4 is processing boolean variables for bIgnoreInput at the top of SlateApplication(the process of turning off the editor), if i do that, i might be able to process the input for both modes.

7

However there is currently a major bug in UE5 (be aware): If you set root Canvas to Visible, even if it by default stretched out to the Screen, it will let Clicks “go through”. Same happens with Borders. One must have non-transparency in order to take the click, and that means you will have to adapt your Game UI to this UMG Limitation. I am not sure, but I think, thats the reason why in many games Hit-Invisible Areas are actually blurred in order to prevent any Click Go Through.