Ability to check whether game client window is currently focused

Feature Requests Engine Features
#1

There are events and functions dedicated to many core input events, such as mouse movement and keyboard input and even getting the OSK (on-screen keyboard) size, position and visibility.
There are events that fire for when the client’s window is focused and released, but there doesn’t seem to be any function / property available for getting if the Roblox client is focused or not, which doesn’t make a lot of sense considering most inputs have both events and functions / properties for each case.

This function can be necessary to developers since it can be used to get the window focus upon initialization of localscripts, or checking each time if the window is focused rather than relying on a variable that toggles each time the WindowFocused and WindowFocusReleased event gets fired (though use-case A is more plausible)

15 Likes
#2

UserInputService has 2 events for tracking when a Roblox window is focused and released, but there is no way to check if the window is currently focused without connecting to these events as soon as the client starts.

In my game I want to show a message for x seconds if/when the window is in focus

local UserInputService = game:GetService("UserInputService")

if (not UserInputService:IsWindowFocused()) then --Make this method exist
    UserInputService.WindowFocused:Wait()
end

--The client is guaranteed to be focused now
8 Likes
#3

Why not just connect to UserInputService.WindowFocused so your code executes when the event fires? I am not sure why we need a method when we can easily just connect to the event, and set a variable to true and set it to false when the window is not focused anymore.

(this post loses a bit of context as the above reply was merged into this topic and this was a reply to the above, and bantech i’ll address that later, rn i dont have time)

#4

Does WindowFocused fire the first time (i.e. when you first join a game)? If not then it’s not a viable solution for the use case in the post.

Depending where this code is, there’s also the chance that even if it does fire at the start, it’s been missed before this code runs. I imagine if it did fire it would be ReplicatedFirst kind of timings - if this was in PlayerScripts then you’ve missed it.

I think it makes sense to be consistent with the other UIS methods that generally provide a start, end, and a way to check the current state.

5 Likes
#5

Running into this issue right now. WindowFocused/WindowFocusReleased does not fire at the beginning of the game.

#6

A bit late response but I think the best solution would be:

local UIS = game:GetService("UserInputService")

local IsWindowFocused = false
local Thread = coroutine.running()
local con1 = UIS.InputChanged:Connect(function()
	coroutine.resume(Thread)
end)
local con2 = UIS.WindowFocused:Connect(function()
	coroutine.resume(Thread)
end)
coroutine.yield()
con1:Disconnect()
con2:Disconnect()
IsWindowFocused = true
UIS.WindowFocused:Connect(function()
	IsWindowFocused = true
end)
UIS.WindowFocusReleased:Connect(function()
	IsWindowFocused = false
end)

At the start you wait for absolutely any input, that being mouse movement or anything else, since all that fires only when the window is focused, and then you are free to connect .WindowFocus and .WindowFocusReleased to change the variable which you use to track the value further in the game.

6 Likes