Disabled GUI entries still getting input (SOLVED)

Questions
#1

I’m creating my in game UI and have a “stats” screen that is initially disabled. on the init script for the GUI is this:

local node = gui.get_node(“stats_box”)
gui.set_enabled(node, false)

This was based off the code in the http://www.defold.com/manuals/input/#_on_input page for the pause menu.

Now, the enabling works fine, but when I want to close the window, I’m just having the user click on it.

One thing I’ve noticed is that if the GUI is disabled, it still receives input events. I put in a print statement indicating when an event handler is called to determine this is happening. Is this by design? If so, why would a disabled element still receive input?

One other thing, I am still seeing the print statement output even if the GUI was never opened. using the “show” message in the on_input tutorial above, I do msg.post(".", “acquire_input_focus”) only when responding to that message, so I’m expecting that GUI to not have input focus.

In my collection, I do have the “stats” gui as an element of the collection, so it does get instantiated, however shouldn’t it NOT have input focus until I tell it to get input focus?

I’m just a little confused on why my UI is getting input.

Thanks.

#2

Hi. What do you mean when you say “if the GUI is disabled, it still receives input events”? Do you mean a GUI node or the whole GUI scene?

on_input() is called for .script and .gui_scripts that have successfully called acquire_input_focus. If you use gui.pick_node() and pass in different gui nodes to determine if the action was made on top of the node then you must also check if the node is enabled or not using gui.is_enabled(). When you use gui.is_enabled() you probably want to recursively check all parent nodes as well to make sure that all of them are enabled. Have a look at the is_enabled() function in Dirty Larry: https://github.com/andsve/dirtylarry/blob/master/dirtylarry/dirtylarry.lua#L21

1 Like
#3

by disabled, I mean this from the init function of the gui_script:

local node = gui.get_node(“stats_box”)
gui.set_enabled(node, false)

stats_box is the container for the rest of the GUI. But now that I think about it, that’s just disabling that portion of the UI and not the whole object, that has no effect on the messages.

Now, I never call acquire_input_focus on the GUI until it gets a message to show, and it’s still receiving on_input right away. Could this be due to it being a child object of the main game object?

#4

Do you acquire_input_focus from another script attached to the game object? Since you do msg.post(".", “acquire_input_focus”) the “.” means “this game object” and it is the whole game object that acquires input focus, not the script. But if it’s a child game object in the collection it should not get input events just because the parent has acquired input focus, or am I wrong here @sicher?

#5

I have resolved this by moving the gui outside of the main game object, which is probably what I should have done in the first place. It was a part of the ‘.’ game object, and was not in a child game object.

#6

Hm…

Ok. I got the same “problem”. I thought / understood disabling in the same way: disabled is DISABLED :wink: so its simply not accessable for inputs.

After searching the problem for a day I found this thread. Now I know: I am clicking on a “invisible” disabled GUI :frowning:

I already move unused GUIs outside of the view area in the past, I removed this part of the script to clean up a bit…
but now… seems to be the better way to move it away or -like @britzl worte - check if a gui is enabled.

#7

Yes, that can be unexpected. The reasoning is that the gui.pick_node function is purely geometrical and not based on user input (although it gets fed user input 99% of the time), it would seem wrong to have it return false - a disabled node still has the same position and size, etc.
Checking if the node is enabled or not is a lot better than moving it around.

2 Likes
#8

Thanks @Ragnar_Svensson for your answer.

Size and pos is clear, but already active ?

But never mind, now I know where the “problem” was. I’ve moving unused gui out of view to be sure.

Maybe I’ll change the code and check if enabled also or/and dont move in the future.

Why is it no good idea to move ?

#9

A node that is off-screen but not disabled will still be rendered and thus have an impact on performance (although often ever so slightly). Also, a single gui.set_enabled(true|false) feels like a much cleaner solution than moving nodes/objects back and forth. It’s also easier to look at the code and understand it’s purpose. And what if there’s code added at a later time that moves the whole UI (for instance some slide in/out transition) that all of a sudden reveals the things that were moved offscreen in an attempt to hide them?

#10

Hi @britzl.

Just to be clear: I already disable the GUIs. I additionally move them out of view :slight_smile:

Maybe I’ll change that in my code to check for if enabled instead of moving. I quess thats faster.

1 Like
#11

Ah, sorry, I misunderstood! Well, then it’s a tradeoff in having to do an additional check when doing gui.pick_node() or moving nodes back and forth.

1 Like
#12

Just more work with 0 benefits. :slight_smile:

1 Like
#13

Very good answer :smiley: @Ragnar_Svensson

2 Likes
#14

Ran into this myself – the dirty larry approach helped a lot - thanks!. I ended up copying it, but adding a check to stop the recursion if any parent was itself disabled so I could show hide sub-sections.

1 Like