So, this is a weird bug.
Basically, if you have a ScreenGui inside of a ScreenGui and have any interactive element in it (e.g. a TextBox or a TextButton) - the interactivity of the element is disabled.
This means that Click events, Focusing and similar is disabled.
Why would you ever even go so far as to do such a thing?
I’m surprised that the sub-screen-gui items show up at all.
[quote] Why would you ever even go so far as to do such a thing?
I’m surprised that the sub-screen-gui items show up at all. [/quote]
Like I said in the OP, I was testing and moved a ScreenGui into another ScreenGui. Without noticing (because the Guis still rendered) I tested the place, and found out that my interactive features weren’t working, with no output messages. I found out by looking at the hierarchy when going to open the scripts that I had done that, and did some tests to make sure it actually was a bug.
Not a bug, that’s intended behavior. Otherwise the UI element processing would get exponential time complexity.
Oh, okay.
It was just some unexpected behaviour which I had come across. If it does that, then wouldn’t it be a better idea to prevent it from rendering at all?
[quote] Why would you ever even go so far as to do such a thing?
I’m surprised that the sub-screen-gui items show up at all. [/quote]
Surface gui inside a frame with clipsdecendants?
It’d be nice if we disable this kind of behavior, it may break some places though. Maybe I’ll take a look at it.
bump, even 11 years later this is still a thing and i highly recommend it isn’t or at least a toggle to disable this behavior
While trying to figure out what this post means.
Could it be that it is asking for something like this?
Ah not quite, basically if you have a ScreenGui inside of ANOTHER ScreenGui, then the buttons in the sub ScreenGui cannot be clicked whatsoever, making the parent ScreenGui disabled doesn’t hide the sub ScreenGui’s, it’s purely for organization, though it’s just slightly annoying sometimes.