top of page

One time widget clicking

Whenever a UMG widget is exposed after being hidden, it's nice to be able to click on its buttons and they get an immediate click event response. This isn't the default behaviour of Unreal's input however. The pitfall is that the game designer has to do some work to point the game's mouse input to the exposed widget. Otherwise, the mouse has to expend a click to detect the widget before the widget buttons will execute their On Clicked events. For the player, this creates an odd feeling of having to click twice to do one thing. This can be extremely derailing when you notice that 'hovered' events seem to be a lot more well-handled by default.


Reading through docs, there's terms like widget captures mouse input and mouse focuses on widget. On top of that, the unreal client may not even be where the cursor is (if you last clicked on Chrome for instance in Windowed mode, your game may not be registering the mouse at all). A seemingly simple problem gets complicated fast ... not to even mentioning setting the mouse position to the exposed widget.


Confusingly, there are some blueprint nodes for widgets such as Set Focus and Set User Focus ... but they are a bit mysterious (to me). If you use those nodes, buttons will give warnings if they are not set to be focusable in their properties. On the safe side, set your widget (or button in it) to have its property Is Focusable = true.

You can do this on either an individual button, or on the widget's root in the Hierarchy, then nestle down to a specific element.

Does setting this Focusable value even matter? I'd argue, not at all, unless you use Set Focus or Set User Focus.

Luckily, we don't need to. Those nodes don't appear to make a freshly unhidden widget respond to clicking immediately. Maybe they can, but I didn't find a way.


What appears to work is to set the widget itself to respond to changes in its Visibility state, using the nodes "Set Input Mode UI Only" and "Set Input Mode Game Only".


The trick though, is to know when to do so. In the tangled strings of multiple blueprints, knowing where to insert a change in input mode can be a headache, so why not just do it once?


Below is a very generic setup you can paste into your widget from UE Pastebin:


Notice that the OnVisibilityChanged_Event is bound to the widget's Event Construct. This is just a way to create a "listener" event that'll be active after the widget is created. Then, whenever the widget's Visibility (enumerator) changes, the event fires. In the case above, I'm checking "Is Not Hidden" with a branch that sets input as UI Only if we can see the widget, and input as Game Only if we cannot see the widget.


Small notes:

  • The player controller (base) has to be assigned. Don't use your extended one because it's not necessary and works more generally using the base player controller. Any project will accept this.

  • Self is the Widget to Focus. You can assign a specific Button in the widget (because Buttons are widgets).

  • Does Lock Always makes much difference? That might depend on the larger game design. it will keep your cursor in the game's viewport until you do something with the focused widget. This is more important when playing in Windowed mode. It doesn't affect the single mouse-click problem we're aiming to solve, but it's good to know.

This setup seems sufficient for cases where a widget contains a button you'll click on to set some value somewhere, then you want set the widget hidden again in order to keep playing.


Featured Posts
Recent Posts
Search By Tags
Follow Us
  • Facebook Basic Square
  • Twitter Basic Square
  • Google+ Basic Square
bottom of page