How do I find mouse pos on gui?

I’m making an inventory Gui and when you click on it an item a Gui pops up telling you info. I’m trying to get the Gui to go to the mouse but its not working.

1 Like

If the item that the player has to click on in the inventory gui happens to be a button (TextButton or ImageButton), you can use the GuiButton.Activated event and then connect it to a function.

The first parameter that’s returned by that event is an InputObject, which has a Position property. The first two values of that (the X and Y coordinates) refer to the horizonal and vertical positions on the screen that the player clicked on.

As long as the ScreenGui that is containing all of those GuiObjects has its IgnoreGuiInset property turned off, you can set the offset values of the GuiObject.Position for that “info” Frame / TextLabel / etc. to those X and Y coordinates.

Here’s a basic example which would work on an individual button (if you wanted it to work for multiple buttons, consider creating a loop that connects the Activated event for each button to the function. Further changes would need to be made to ensure that it displays the correct info based on the button that was pressed, but again, this is just an example):


-- Example LocalScript

local ScreenGui = script.Parent
local Frame = ScreenGui:WaitForChild("Frame")
local GuiButton = Frame:WaitForChild("TextButton")

local function createInfoFrame(inputObject)
	local position = inputObject.Position
	local touchPositionX = position.X
	local touchPositionY = position.Y
	local exampleInfoFrame ="Frame")
	exampleInfoFrame.AnchorPoint =, 0.5)
	exampleInfoFrame.Size =, 0, 0.05, 0)
	exampleInfoFrame.BackgroundColor3 =, 1, 0)
	exampleInfoFrame.Position =, touchPositionX, 0, touchPositionY)
	exampleInfoFrame.Parent = ScreenGui

1 Like

wouldn’t it just be simpler to do:

local Mouse = plr:GetMouse()

-- code code code
Button.Position = Mouse.Position

i don’t really see as to why this wouldn’t work, correct me if i’m wrong though

There isn’t a Position property for the Mouse but there are X and Y properties that reference its current position; there’s also UserInputService:GetMouseLocation() to retrieve the Vector2 that contains both of the coordinates simultaneously.

However, here’s what the documentation for the X and Y properties happens to recommend in adjacent situations where the mouse position needs to be referenced:

When detecting changes in the mouse’s position on-screen, it is recommended that you use ContextActionService:BindAction() with Enum.UserInputType.MouseMovement or UserInputService.InputChanged, which both describe the position of the mouse using the Position (a Vector3) of an InputObject, instead of using this and related properties.

(*I’m aware that is more in the context of detecting changes in the mouse position, which is not exactly the use case for OP, but notice how it’s referring to services, events, etc. that are more in line with supporting multiple input types instead of specifically a computer mouse.)

Although those are viable options, given that the InputObject and the on-screen position where the input occurred are already provided through the event, it seems a bit wasteful to make an additional call to get the mouse and reference its Position.


Either UserInputService:GetMouseLocation() or retrieving the first two axes of InputObject.Position would work for this use case at this current moment in time (even for other types of input, such as Touch on touch-screens), but the latter is recommended because:

  • The InputObject is already provided by the Activated event (so you might as well use it).

  • It’s much more likely to remain compatible into the future with multiple UserInputTypes, given that InputObjects were designed around that, versus the Mouse object being originally designed to support computer mice in particular.

Even if it might be unlikely for the mouse-related properties and methods to be deprecated in the future, relying on the InputObject better guarantees that work like this is future-proofed, given how the InputObject is more versatile for supporting different types of inputs.

1 Like

Sorry, but y’all came when I went to bed so I wasn’t able to reply. I found the issue though. I was setting the frames position whens its parent frame was only half of the screen.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.