Heya,
After upgrading to 4.8, we are no longer getting ReceivedFocus and LostFocus being called in our GameViewportClient. I tested in ContentExamples on the release branch of vanilla unreal and it appears to be a problem with Unreal.
Repro steps:
Set Breakpoints in ReceivedFocus and LostFocus in GameViewportClient.cpp
Launch as Standalone Game
Alt-tab into/out of the window
No breakpoints hit
It seems to work as intended when I run in single process and tab between unreal windows.
I think we don’t get ReceivedFocus events is because in SlateApplication.cpp in SetUserFocus we hit this line:
if (WidgetToFocus.Widget == OldFocusedWidget)
But when we go to another process/switch back from another process the OldFocusedWidget is the last widget we focused inside our process instead of being set to some invalid value when we leave the window entirely. I’m guessing that’s just because we never fire any sort of LostFocus/SetUserFocus stuff when the window is deactivated.
Bumping again. This is a major issue for us since we use the ReceivedFocus and LostFocus functions to trigger muting game audio in WWise, and our audio can’t be demoed easily without them.
Thank you for reporting this issue. I’ll be looking into this issue and I’ll get back to you when I have it reported or if I need more information. Also, I moved this post to Bug Reports due to it being a bug report. When it comes to bumping threads, please don’t bump without extra information of some sort more frequently than 3 days at a time.
After looking into this, can I assume that you’re using alt-tab or something of the sort to simulate losing focus on the window? For me, if I use alt-tab, the breakpoint doesn’t trigger but if I use Shift+F1 (Which will lose focus and bring up the hardware cursor) the breakpoint triggers immediately. Can you give this a try? In this case, I’m not quite sure if that is intended to work that way with standalone applications so I’ll be looking into that point.
Something to add, please be sure that you’re attaching the debugger to the standalone game’s process when debugging. The reason why is that it is counted as a separate process which means it’ll never be picked up by the debugger if you’re launching the editor in debug without also attaching to the standalone application.
Heya,
Yep that’s pretty much what I’m doing. Any idea why alt-tab wouldn’t do that? If someone’s running my game windowed alt tab is usually the most common way to go to other windows.
Anyway, let me know what you hear about the intended functionality or where else I would do this kind of stuff if this function is working as intended.
Also, totally sorry I posted this in the wrong spot. I didn’t know there was another spot for it Probably would have gotten a reply a lot faster over there too <_<
Have a good holiday!
edit: Just to follow up because I forgot to mention something. I made a thread on the forums a while ago also on the same topic, but it includes a potential workaround that I’m unsure about.
Just wanted to mention it in case it’s relevant to you.
I haven’t had a chance to test it myself but have you tested to see if losing focus with alt-tab works for a packaged game? There are a few things different about a standalone app than a packaged version which could explain it.
As far as the workaround you mentioned, it looks like it involves editing source code. In this case, if it is something that seems like it’d be helpful for everyone, please feel free to make a pull request on Github and we could take a look to see if it should be integrated into the engine itself.
Since the weekend just ended I’ll be getting back to looking into the original problem right now (Alt-tab not working for standalone) and I’ll get back to you soon about that.
Aloha,
It seemed to not get called in a packaged build either.
For the source change, I’m not 100% certain if the fix is actually the best solution, or if it’s just a solution that happened to work with some unintended knock on effects. Would it still be an ok idea to submit it as a pull request and then it can just be denied if it’s not the way it should actually be fixed?
Yes, all pull requests are reviewed for their compatibility and how they’ll affect other things before being approved, so there is no harm in submitting a pull request that may not be perfect.
I’ve placed a bug into our system for alt-tab not calling these functions. For your reference, the bug number is UE-20926. As I’m not 100% sure if this is intended functionality I can’t promise that there will be a fix, but I’ll be sure to update you here if there are any updates to the bug’s status.
I’d like to let you know that this bug report was just verified as fixed in one of our latest internal builds and the fix should be coming soon. It’s too early to say if it’ll be in 4.11, but it should be shortly after if not.
Awesome. I think we’re locked into our current version, but do you know where I might be able to find the change on github so I can just put it into our version? Thanks for following up. Really appreciate it
I can give you the Github commit, but please be aware that we just discovered that there was an issue that this change introduced that causes the editor to crash when opening the Level Blueprint, so use it at your own risk. It’s currently been backed out and will need to receive another fix.
Probably would have gotten a reply a lot faster over there too <_<
