I’m trying to have a gui not respond to events when it is blocked by another gui. I have this set up to go green on MouseEnter, red on MouseLeave. I did the same experiment with InputBegan/InputEnded on the Button with MouseMovement.
How do I make guis not sink input when they’re blocked? Or do I have to manually close windows and ensure buttons never overlap? Here’s an example of this in our game where we have to write custom code to patch it (we do this in many places):
I’ve been dealing with the same issue for a long time. The best solution I know of is to use a TextButton/ImageButton to block the GUIs since they absorb all input.
Currently the button solution is the best you can do. We actually tried to fix this behavior some time ago, but it broke many games input. We do plan to refactor a lot of little ui bugs like this, figuring out the best strategy to roll it out without breaking many games.
I find it hard to believe there are thousands of users across games that will be affected by this, so it must be a top game refusing to update their codebase. Otherwise I don’t see the reason to force all new games going forward to fight this broken functionality.
We will switch over World // Zero’s UI to be entirely built out of buttons and frames until GuiLabels are supported again! I’ll update this post if there are any significant performance dips from doing this.
This is expected behaviour in my opinion. We have a lot of UI covering other UI like notifications, messages and descriptions. If you want this to not happen, you should do something like:
function ButtonHover()
if HaveMessageOpen() then return end
--Rest of your code
end)
We also sometimes put the button behind a ImageLabel because we want a larger image than the button itself. This could be red dots on it or some kind of clicked or hovered effect.
Yeah, no. If I have a completely opaque frame visible and yet somehow the buttons behind it are sinking input, I would be confused. There’s no reason they should sink input.
I do stuff like this, but I just add a TextButton that’s almost completely transparent over the area that needs to be clicked. So edge use cases like this would still be possible if this bug were fixed.
As for fixing the glitch with code, it’s possible but painful and time-consuming, especially if you have tons of elements.
Buttons whose parents / ancestors aren’t visible will sink input when selecting with a gamepad. It’s think it’s related to the same core issue that should definently be fixed.
Perhaps with a StarterGui or ScreenGui bool that toggles the fix, this could be alleviated, without the risk of breaking existing games.
One solution I can think of would be to add a Boolean property to all GuiObject values called “SinkInput.” The default value for this property per class can maintain old behaviour but allow developers to not only prevent unwanted input sinking but also force input sinking in cases where it is needed but is not default behaviour.
A second solution could be to add an “InputIndex” which is hidden/shown by “UseInputIndex” (or possibly InputPriority) property which functions similarly to ZIndex. This property sets the priority of mouse events for an input object relative to the object’s ZIndex allowing developers to make buttons clickable even if GUIObjects are layered over them.
Personally I would prefer the second idea as I feel it has more use cases and I can remember times where this would have sped up GUI development and debugging.
This solution doesn’t seem to work, I tried layering two buttons but they still fire MouseEnter and MouseLeave when blocked.
Is there any way to fix this?
Sorry to bump this old thread, but I’m currently experiencing the same problem where I want to temporarily disable mouse events to imagebuttons underneath an active GUI element. The imagebutton masking solution didn’t work for me either.
Have you managed to find a workaround?
Is this solution still recommended? Did those refractions take place?
I’m currently developing a 2D experience where modals occurs throughout the design to promote confirmation of design. The current status quo creates a rather frustrating mobile experience especially.
I would like to be able to press outside of the modal and that not interfere by something pressing somewhere in the body text for example. Or even than pressing middle in the wrong place leads to me pressing the button below the modal.
With the workaround recommended, it does help at least for the button UI misclick and create another button below the modal to exclude that area, it does somewhat bother me that now the mouse click icon will always shown and not based on what’s actually visibly on top.
Even if it’s a special property that just ignores everything below that zindex, it would be a strong fix to a rather annoying bug.
Please just add a SinkInput boolean on GUIObject, if left enabled by default on all UI elements created before the change, no legacy codebase will be broken
Maybe you meant “disabled by default” - depends on how you define “sink”, but I second this, completely agreed, this shouldn’t break anything - if it also takes into account ImageButtons, TextButtons, ScrollingFrames and so on, everything that does sink input right now.
