Allow to easily prevent clicks from passing through Guis

If I’m understanding this post correctly:

In the click event in your button, you can add an if statement to check if the modal GUI is visible, or another property, and if it is, just don’t run the code.

For example:

TextButton = game.Players.LocalPlayer.PlayerGui.ScreenGui:WaitForChild("TextButton")
TextButton.MouseButton1Click:Connect(function()
	if ModalGui.Visible == true then
	else
		print('click')
	end
end)

Hope this helps, and correct me if I didn’t understand this post.


1 Like

You can create overlay frame by setting its Active property to true and moving it to a different ScreenGui

2 Likes

Could you show a video or submit a project that works within what you are arguing?

i might be able to upload .rbxl file here in my spare time

Also @V_ladzec from the docs:

This property determines whether a GuiObject will sink input to 3D space, such as underlying models with a ClickDetector. In other words, if the player attempts to click a ClickDetector with the mouse hovering over an Active UI element, the UI will block the input from reaching the ClickDetector.

I’ve tested for myself and this only applies to things in the 3D space (in the world). For example, it blocks camera movement.


This feature doesn’t seem to exist even in a hacky/unintended form as far as I can tell, I do think it’d be very good to have.

Read the script inside StarterGui before changing anything

OverlayFrame.rbxl (38.0 KB)

Does setting the frame’s active property to true not block the sinking of the input?

image

This is already answered here. Please read before posting.

1 Like

I appreciate your effort, but looking at your example, there are two points:

  1. What you put in the script has absolutely nothing to do with what you said before about the Active property (which is already clarified in other posts here).
  2. As I’ve said before in this thread, I know I can do a lot of additional controls via script, but my request is for “easily prevent clicks from passing through Guis”, so I’m opening an ENGINE FEATURE REQUEST, not a script support request.

answering to your points:

    1. the script inside StarterGui was supposed to help better understand how do you test the thing i made, and two other local scripts were created for better visualization
    1. you cant click through that frame even if you remove the scripts

what i did is created a separate ScreenGui and Frame for it, where i set the Active property to true

change the zindex of it, it should fix

Please, test and confirm before posting.

What I find interesting is that when the /console (and the ESC menu) is open in the engine, buttons are not able to be clicked through it. They must have a setting enabled where buttons cannot be clicked when the frame is over it. Why isn’t this a setting in frame properties in Studio?

1 Like

I remember looking through the chat scripts and noticed they have a TextButton called “InputBlocker” with no text and fully transparent to block inputs for some chat windows, think this is what they do with the Roblox menu. Looking through, they have a TextButton called “SettingsShield” which is sized at 1, 0, 1, 0 and has modal enabled.


image
image

I’m not sure what OP considers a custom controller but you can use this to sink input assuming your ScreenGui has ZIndexBehavior Sibling. Just set the TextButton’s ZIndex very low (-999). Only thing is that it probably won’t work well with ZIndex global, and it doesn’t block MouseEnter, and if you’re Instance.new’ing a frame you will have to create an additional GuiObject.

input thing.rbxl (43.3 KB)

I do have to say though, it should absolutely be possible to do this without a workaround.

2 Likes

I’m in support of this; its really annoying that interfaces allow this.

6 Likes

You are correct that a TextButton blocks clicks from going down. Mouse enter/leave still happens unfortunately like you say, which means any buttons/whatever you have under a transparent frame still look clickable even though they aren’t.

Would be nice to have a way to block all input from going further down in the engine.

3 Likes

How is this not yet a thing :sob:

Why does one have to use a TextButton just to block stuff in the same ScreenGui

And why did I start realizing this now… :neutral_face:

7 Likes

Bumping…

Still very much a necessary feature.

3 Likes

I recently encountered an issue while creating a UI with tabs for navigation that pop up when hovered over. During testing, I realized that the tabs can still be interacted with when the mouse is over them, despite a frame covering them. This seems to be an inherent limitation of the .Active property, whose usefulness appears to best suited for scenarios as such.

I was convinced this feature must exist as an essential function, but here I am, mistaken. I found a thread dating back to 2018, along with many others, discussing the same problem. I find it surprising that even after six years, this still hasn’t been implemented.

Workarounds should not be mandatory. Please consider adding this feature!