generating code:
(run in Play Solo with Player1)
creates this:
SurfaceGui.ToolPunchThroughDistance is 1000. clicking on the TextBox doesn’t do anything.
looks like TextBoxes only work in a SurfaceGui if they are in the PlayerGui and have the adornee of the part. Still, when doing that, it is not selectable unless you drop the tool.
found another bug: when putting the SurfaceGui into PlayerGui and setting the adornee, it doesn’t show up unless you manually set Enabled to false and then back to true.
You need to change SurfaceGui.ToolPunchThroughDistance to interact with surfaceguis while holding a tool.
In other words if the SurfaceGui is within 1000 studs then it should work.
Oops, didn’t see that 
Aren’t parts that are descendants of the character unclickable?
Same thing might happen here…
1 Like
There is code that specifically prevents this from working.
TextBoxes, as descendants of this instance, are locked if the SurfaceGui instance is a descendant of Workspace.
So what about when it’s in the playergui and the adornee is a part inside a tool? It still doesn’t work.
Not sure what you’re doing there, but I’ve just tested all the interactions between input, tools, and PunchThrough distance, and they seem to be working fine.
In order for SG to be able to receive input in a textbox with a tool selected, you need to have the SG under Player or StarterGui and you must be standing within ToolPunchThroughDistance studs from the part center.
I copy the code from local s=Instance.new("Tool")local h=Instance.new("Part",s)h.Name="Handle"h - Pastebin.com into the command bar in play solo, go into the PlayerGui and switch SurfaceGui.Enabled off and back on so it shows up, and then click on the TextBox and try to type things in it and it doesn’t work.
1 Like
Oh my… I think I know what’s going on there. It’s basically a conflict of two features.
The problem is that SGs on player were not originally intended to be interactive, because the raycasting code was set to ignore anything on the player, because otherwise if you’re in first person, and wearing an elaborate hat, the ray cast from the middle of the head would hit the hat… So you’d never get any input on such a SurfaceGUI. But then there’s this new ‘always on top’ stuff that bypasses the bypass and somehow delivers the input events through the 2D route…
Omg…
so I guess I’ll have to re-weld the part with the surfacegui to the handle every time it is selected and delete it every time the tool’s parent changes (and also the surfacegui so it doesn’t stay there after I remove the part.)
1 Like