Close menu with same button as opening

Hello! I am new to blueprints and appreciate all help:)

I am currently working on a menu with the setup listed under. The menu opens when you push M on the keyboard. I was wondering if there is a easy way to close the menu with the same button? Thank you so much in advance!

thank you! can i ask what is the first node called? the one named SET is menu viable and NOT, and then again is menu visable.

thank you so much for your respons! i really appreciate it :smiley: i tried the second version, and this is how my blueprint looks like now. i will try your first method now. it did not work with the second, i dont think i did it right… the menu does not close. thank you again!

The most standard way goes like this:

The isMenuVisible keeps track of the menu status. You need to add it yourself. There are other ways of keeping track of it but this is generic / versatile.

1 Like

This way you create it only once, and then simply show / hide it instead. You can create the reference to a widget (here NewVar1) by right clicking the Return Value pin → Promote To Variable.

Technically, you could do this:

But this will create the menu from scratch every time it’s opened and could be unreliable. Best reference it properly like in the original suggestion.

1 Like

This is not working because you’re cutting Player Controller from input by setting UI mode only.

As above, it’s a new variable you need to add yourself:

Image from Gyazo

You can then Get (read) it or Set (write to) it. You can either drag & drop it into the graph or hold Ctrl / Alt as you drag to evoke get / set.

All the good stuff about variables:

Just in case.


Alternatively, you could do it like this:

343133-screenshot-10.png

ok thank you again! can i just cut the player controller? sorry for the stupid questions… :frowning:

Not stupid at all, actually. It’s just an input processing thing.

Set Input Mode UI Only prevents the Player Controller from processing input - pressing M while this mode is active does nothing, the PC ignores it, as instructed. The input is processed in the widget instead since we’ve given it to the UI exclusively - Set Input Mode UI Only

You can have it processed by both (widgets go first, though) with Set Input Mode Game and UI node but if you’re making a first person shooter kind of game (we don’t know it here) you may not want to do this.

In order to make the same key work seamlessly (the way I think you want it to work,) you’ll need the following:

In the player (or wherever you press M to open the menu):

  • the above either creates or shows the widget, it does not close it
  • the below is processed in the widget - this closes the menu:

  • the override is here:

  • and you need to make the widget keyboard focusable:

343184-screenshot-2.png

3 Likes

The above would work in an FPS where you do want input exclusivity:

Image from Gyazo

thank you so much for all your answers! i will try this out now :smiley:

Why is this unreliable? Removing widget from parent removes from memory, right? Isn’t it better that way?

This doesn’t work anymore if you click anywhere outside the widget, hence it looses focus.
Why aren’t widgets accepting key input?

How long do you think this reference is valid? 5s, 60s until GC kicks in, 5 minutes, entire session? And what if something else needs to access it, it cannot.

Did you forget to set the Input Mode to UI only? The focus can only go to a widget…

You can always onFocusLost → Focus.

And keyboard Focus is a thing, too.

Yep, UI only set in Player Controller. As soon as I click outside any visible component of the widget, it doesn’t fire the ‘onKeyDown’ function anymore. I assume it looses focus?

Refocus then, there is an override for that.

1 Like

Well, just used onFocusLost → SetFocus (self). This is on my main menu. All good except the Quit Game button doesn’t work anymore, lol.
Using some print strings, I can see that, when I press Quit, onFocusLost fires.
The onKeyDown for closing the menu still works though.

Edit:
Apparently, everytime a child component of the widget gets focused (clicked buttons, in my case), the widget itself loses focus. Why is that useful is a mistery?

All you have to do is uncheck this:
Capture (4)
on every child component. But I assume this will throw any keyboard/controller navigation of the UI out the window.

Another few good hours lost on figuring out something that should be trivial. I hope there’s good reasons for things to be designed like this.

Thanks for the help, once again.

Spoke too soon. Forcing focus back on the main widget prevents ComboBox from working. And who knows how many other things, unfortunately.