local UDimNew = UDim2.new
local Gui = script.Parent
local F = Gui.Frame
local FacebookBtn = F.FacebookBtn
local FacebookF = FacebookBtn.FacebookF
local DevForumBtn = F.DevForumBtn
local TwitterBtn = F.TwitterBtn
local YoutubeBtn = F.YoutubeBtn
local EnlargeFSize = UDimNew(1, 0,.9, 0)
local EnlargeFPos = UDimNew(.5, 0,.55, 0)
local Table = {
[FacebookBtn.MouseButton1Down] = function()
FacebookF.Parent = F
FacebookF.Visible = true
FacebookF:TweenSizeAndPosition(EnlargeFSize,EnlargeFPos)
print('FacebookBtn')
end,
[DevForumBtn.MouseButton1Down] = function()
print('DevForumBtn')
end,
[TwitterBtn.MouseButton1Down] = function()
print('TwitterBtn')
end,
[YoutubeBtn.MouseButton1Down] = function()
print('YoutubeBtn')
end,
}
for i,v in pairs(Table) do
i:Connect(v)
end
I have tried setting the Active property on the FaceBookFrame but it didn’t make any differences, maybe I’m doing it wrong.
I also made the Buttons Visible = false and it did work but I don’t like it.
Why?
Answer: It’s not very efficient isn’t it? Toggling all the Buttons’s Visibility every time I show/hide a Menu Frame. (I’m using this method for now, until there’s a better method)
Another method is to use a Button (TextButton,ImageButton) instead of a Frame but I don’t like it either
Why?
Answer: It’s not what they are designed for.
I can think of a few methods but they are’t efficient.
You said that you set the active property, what did you set it on? The frame or the buttons? It should be set on the frame. Although, it has been awhile since I’ve used it. From the page you linked to:
Right… something is wrong. I’ve tried all 4 combinations of a button and frame being active both with the frame as a child of the button, and as siblings. Here is what I used:
local sounds = {'Ouch, 'Hey', Watch it', 'Stop that'}
local s = Instance.new 'ScreenGui'
local f = Instance.new 'Frame'
f.Active = true
f.Size = UDim2.new(0, 100, 0, 100)
f.Position = UDim2.new(0, 50, 0, 50)
local b = Instance.new 'TextButton'
b.Size = UDim2.new(0, 100, 0, 100)
b.Active = false
b.MouseButton1Click:Connect(function()
print(sounds[math.random(1, #sounds)] .. '!')
end)
b.Parent = s
f.Parent = s
s.Parent = script.Parent.Parent.PlayerGui
I’m not aware of any changes and this doesn’t seem like the behavior defined by the wiki. I do know that there have been some huge gui/input optimizations so I wouldn’t be surprised if something was removed for the sake of speed or is currently not working.
I think I recall this being broken a long time ago as well (if I was doing it correctly back then). I’m not sure if it just broke again, isn’t being supported anymore, or lacks proper documentation.
Try making the buttons unresponsive when the menu frame is visible. For that, you’ll need to track of whether or not the menu is visible somewhere in your script.
I usually create an ImageButton to serve as the backing for the popup… We’re going to look into the Active property, because it sounds like it doesn’t work as intended, but we’re not sure if games are relying on its current behavior. I believe right now setting Active to true on a Frame only prevents it from passing input through to the camera controls, not preventing buttons underneath from being clicked.
The Active property only blocks input from 2D-world to 3D-world. You can prevent 2D-to-2D fallthrough by using a GuiButton, since they always absorb input.
Look into fixing the documentation so that it matches the behavior, because that’s been the cause of all the confusion.
I am pretty sure people are relying on the active behavior to block input from going through 2D objects, but since it never worked we all had to use a work around.
I’m not quite sure where you get the impression that toggling visibility isn’t efficient. If anything, if you organize your object hierarchy, it’s a better method. Any frame or tab based work I do is normally contained in switching out the visibility of frames or using a tween for a frame within a ClipDescendants frame. I haven’t opened the repro yet so maybe I misunderstand something here.
For now, as a band-aid solution, like Anaminus said, I would use a GuiButton instead of a Frame. Alternatively, you can hold the underlying buttons to a bool (recommended the tab’s visibility) and only allow them to be pressed if it is true. The bool is set to true when the tab is opened and false when closed. Your objects will still be able to be clicked but they won’t perform any kind of actions.
button.MouseButton1Click
if frameRelatedToButton.Visible
performActions()
By toggling the Visibility of n amount of Buttons will require work from the Script.
Where as if it does that automatically without a script it doesn’t require (as much) work.
That’s why it’s inefficient.
Anything that requires a script to do an action is work, more work is less efficient with an equal amount of Result.
So in this case the Result that I want is the Frame to block Input going through it, if it does block input then I wouldn’t have to toggle Visibility of any Buttons which is efficient.
…it’s not less efficient to toggle frame visibility over trying to have everything visible immediately. You’re simply adding a few lines of code to your work, the script doesn’t over or under work. Same process, better practice, less problems. You could avoid the entire issue of misclicking buttons.
Calling frame visibility inefficient means you’re also labelling a majority of games that use visibility over all-visible frames “inefficient”, regardless of their performance. It’s not inefficient in any way. You wouldn’t have this issue if you switched over to that.
Would you rather prefer more lines with less headaches over less lines with more headaches? There is no efficiency or performance difference, it’s the practice that’s bad (in my opinion).
EDIT: While I stand by the point I made above, I crossed it out because I checked the repro and saw what you were trying to do. In this instance, it also changes my perspective over you trying to do X thing while it’s actually you trying to to do Y thing, hence
I made a repro in about 15 seconds that fixes your problem. Repro for RuizuKun.rbxl (18.6 KB)
using a blank image button or text button as the menu’s background frame will stop anything underneath from being clicked. don’t know if that was mentioned already, but it’s a simple workaround
If all else fails, move the hidden content off screen after the pop-up, then back on screen before dismissing the pop-up. This should make the experience invisible to the user while preventing issues with underlying GUIs processing input.
Reviving this thread because I believe this feature still needs to be implemented. Currently the Active property on 2d-2d interactions does not do what the docs specify. Using the ImageButton hack stated above still works but is definitely not optimal.
