Tracking close event of the main UE4 window when in standalone


I want to track the event of main window closing when running in windowed mode (i.e. when user clicks ‘x’ close button), is it possible? My goal is to prevent main window from closing and show a message box with “yes” and “no” buttons using Slate interface (perhaps should I delegate or override some event for that?).

I expect to use C++ for that task, but I don’t know where to start (has the experience coding with c++, but haven’t done anything for UE4 with it yet)?

I’m using Unreal Engine 4.9 Launcher version with code project.

Haven’t found anything about this around,

Thank you

1 Like

Yeah, I am looking for this too.

Did either of you work out how to do this?

I don’t know if there’s a better way, but worst case would be to override FWindowsApplication and write something there.

There are also several possible delegates listed in FCoreDelegates: OnExit, OnPreExit, OnEnginePreExit, maybe more. Not sure if those can prevent the exit from occurring, though.

I could’ve swore there was something somewhere called something like “RequestExit” but I can’t find it right now

Thank you for the response :slight_smile:

There is UGameViewportClient::OnWindowCloseRequested() where you can set a callback, and SEEMS to be the recommended way of doing this - but this only works if you try and exit the game from within the game. Any OS (in my case Windows) “close” method doesn’t result in this delegate being executed - so if you hit “X”, “Alt-F4”, or “Close program” from the task bar it just abruptly closes.

I’ve found those other delegates but as you suggested - my findings so far is that they all seem to be about adding your clean up process to the shut down, not actually providing an option to return to the game.

If you’re building engine from source, you could add some delegate to handling that in FWindowsApplication directly, or you should be able to override that somewhere in the INI files I think with your own subclass that intercepts the Windows Messages and does some work to avoid that.

1 Like

I’ve just used the conversation as a starting point and finally after some days epic approved the plugin I did for that (no worries it is free).
I hope this is what you meant :+1:
Wrote a documentation for the plugin and I recommend to use it.

PS: Only works in Standalone.


Thanks @Hibiikiii - this looks heaps like what I’m after, I’ll have a play with that and see how it goes.

1 Like

Sooooo I ended up looking at what you’ve done and it made a lot of sense though I was pretty sure that the base class should have already been honoring the “OnWindowCloseRequested” that I had already been binding to - you’ve effectively set up a similar callback but allowed it to be bound by a BluePrint (I’m using C++), which is very nice where BluePrints are involved.

What it DID do though is made me look back back through the code and discovered that actually there was another bug (in short, the assumption that a dialog box was blocking) and my found function WAS actually being called, the window was being popped up but then the function was dropping out and returning a result which indicated to Unreal that we were ok with it closing - so it was essentially a bug I’d not picked up on. The reason it was working when it was called from within my own “Exit” path is that when I called it I was relying on the dialog to shut the game down, so it was masking the issue.

So to confirm, if you’re doing this in C++ then just bind UGameViewportClient::OnWindowCloseRequested() and it DOES work fine, you just need to make sure the function you bind to it is actually working properly :crazy_face:

Thanks everyone :slight_smile:


Hey there!
Great to hear that you looked back in your code and found a bug ^^

Have a great day :smiley: