Intercepting application close signal

[Tsukihime]

Is there a way to intercept any attempts to press the X button, alt+F4, explicit process killing, or other means of trying to close the game that can be intercepted at an application level?


I don't care if they want to pull the plug or toss their machines into a pool.


This can be done as an external application that is constantly monitoring the process; I am not limited to RGSS solutions.

 

[??????]

Also been wondering this...

 

[Zalerinian]

In C++ I tried this. While atexit is apparently evil, it appeared to work fine. I had a constant hold a Win32API reference and it had an atexit function that seemed to work.

I'm not sure if it was my coding or not, but making Win32 objects not constants seemed to create crash issues.

 

[Tsukihime]

Basically I want to capture attempts to close the game and popup an in-game window that asks "are you sure you want to exit?"


Would your approach work?

 

[Zalerinian]

No, atexit would be run when the object is being deleted. I don't know of any way you can intercept the message and then display that warning.
 
EDIT: Perhaps you would like to look into making a hook? WH_CALLWNDPROC looks promising.

 

[Mouser]

I would be very hesitant to disable Alt-F4.

That's not just there as a convenience: it's a failsafe to kill a runaway process.

Without it, you may need to hard reboot your machine - and your users are not going to love you for that.

 

[BigEd781]

To do this properly you need to hook into the Windows message loop from Ruby. Looks like someone did something similar here: 

You should be able to handle a WM_CLOSE and suppress it or do something and then forward it.  Depends on exactly how the Ruby hook works and I've never tried.

 

[Tsukihime]

I would be very hesitant to disable Alt-F4.


That's not just there as a convenience: it's a failsafe to kill a runaway process.


Without it, you may need to hard reboot your machine - and your users are not going to love you for that.

Some people accidentally hit X or their friends goes and alt+F4's them.


Some game engines automatically prompt whether you want to quit the game upon alt+F4'ing.


However, if you go through task manager and kill the process, it doesn't get trapped.

 

[Mouser]

To do this properly you need to hook into the Windows message loop from Ruby. Looks like someone did something similar here: 

You should be able to handle a WM_CLOSE and suppress it or do something and then forward it.  Depends on exactly how the Ruby hook works and I've never tried.

I don't know that it's possible with RGSS. I was having this discussion with Shaz in the mouse script thread - the event listeners aren't out in 'script land', they're buried deep in the engine code. By the time any script gets access to a keypress, the engine has already handled it in one way or another.

 

[cremnophobia]

Here's a simple example that can (or even should) be improved.

#define WIN32_LEAN_AND_MEAN#define UNICODE#define _UNICODE#define STRICT#include <windows.h>static WNDPROC wndproc;static LRESULT CALLBACKexample_wndproc(HWND hwnd, UINT msg, WPARAM wparam, LPARAM lparam){ switch (msg) { case WM_CLOSE: if (MessageBoxW(hwnd, L"are you sure you want to exit?", L"some title", MB_YESNO | MB_ICONQUESTION) != IDYES) { return 0; } break; default: break; } return CallWindowProc(wndproc, hwnd, msg, wparam, lparam);}BOOL WINAPIDllMain(HANDLE handle, DWORD reason, LPVOID reserved){ if (reason == DLL_PROCESS_ATTACH) { HWND hwnd; if (!(hwnd = GetForegroundWindow())) { // unreliable return FALSE; } if (!(wndproc = (WNDPROC)GetWindowLongPtr(hwnd, GWLP_WNDPROC))) { return FALSE; } if (!SetWindowLongPtr(hwnd, GWLP_WNDPROC, (LONG_PTR)example_wndproc)) { return FALSE; } } return TRUE;}Create a DLL and then load it. You can use DL or the good old Win32API for that. (You probably can write the C code above in Ruby and DL too, but that'd be a bit harder.):

EXAMPLE_DLL = DL.dlopen('System/example')

 

[Zeriab]

By wrapping a begin structure around the relevant code (possible main loop) you may be able to handle the exit gracefully by utilizing a rescue SystemExit or ensure clause.

*hugs*
 

P.s. actually interrupting the exit process requesting user input is usually bad design. Consider whether you really do require user input.

 

[Tsukihime]

By wrapping a begin structure around the relevant code (possible main loop) you may be able to handle the exit gracefully by utilizing a rescue SystemExit or ensure clause.


*hugs*


P.s. actually interrupting the exit process requesting user input is usually bad design. Consider whether you really do require user input.

Bad design in what sense?


For example, you're writing a document but then you hit close and then it prompts you that there are unsaved changed.


From a user-experience point of view it would be good design, cause preventing someone from accidentally making a mistake and then lose everything is something devs should be taking care of.

 

[cremnophobia]

That only works with RGSS 1 and 2. They both call Kernel#exit internally. RGSS3 doesn't.

 

[Zeriab]

RGSS3 doesn't? That's a shame.

Thanks for the info. What about using an ensure block. Would that work for Ace?

@Tsu:

Word processing != playing a game.

Transparantly saving the game state and then asking the player whether to start from there next time is a better option.

Btw. explicit process killing is different from a normal shutdown.

 

[Tsukihime]

Word processing != playing a game.


Transparantly saving the game state and then asking the player whether to start from there next time is a better option.


Btw. explicit process killing is different from a normal shutdown.

No, but accidentally closing an application is something no one likes to do.


Some people like to be able to alt+F4 and immediately close it without having to deal with extra pop-ups. This is why there is usually now an option to "Don't ask me next time" or "Remember my choice"


This design would cater to both types of users.


I'd probably just limit this to normal shutdowns, like alt+F4 or the close button.

 

[Mithran]

@zeriab

rescue/ensure don't seem to work in ACE if you just close the window directly, it just immediately terminates the process. They will only trap exiting through normal means (eg., the in game shutdown through the menu or calling 'exit').

@tsukihime

I suppose you could make a compromise by disabling the 'x' from the window (and with it, the ability to Alt+F4 the window) by using SetClassLong.

FindWindow = Win32API.new('user32', 'FindWindow', 'pp', 'l')SetClassLong = Win32API.new('user32', 'SetClassLong', 'lil', 'i')buf = " " * 256GetPrivateProfileString.call('Game','Title','',buf,256,".\\Game.ini")buf.strip!HWND = FindWindow.call('RGSS Player', buf)SetClassLong.call(HWND, -26, 0x0200) #no exit buttonThen, you could handle exit processing internally (use an input script to trap an ALT-F4 press and perform your own display and/or combined with a mouse script and adding your own 'exit' button permanently in game). The game can also still be exited quickly or if unresponsive by right clicking the item in the task bar and choosing exit, or by just closing it in Applications tab of task manager (again, it won't give any additional messages here unless the task is completely unresponsive), and the right click menu of the program icon also still works as an explicit exit.Personally I find F12 reset much more problematic here. Sure, you can rescue that one and last minute save some data, but the damage has already been done at that point. ALT-F4 and pressing the program window X and pretty universally recognized and not really all that easy to miskey, but F12 is used by many games as a screenshot key.

 

[Tsukihime]

Alt+F4 is tied to the close button?


Tried it out, though it got pretty annoying quickly when I couldn't just hit the close button lol


If I implement proper alt+F4 trap it would be a little better, but I think losing the close button would raise a number of questions.

 

[Zeriab]

Having an in-game message when exiting through the in-game menu can make sense. It is different from catching the external exit signal. After all, you can simply press Alt+F4 to quit easily in that case.

@Mithran:

That's a bummer. Thought they only messed up F12.

Thanks for the information.

*hugs*

 - Zeriab

 

[Ellie Jane]

I would strongly advise against doing this. It should be a user's right to terminate a program whenever they wish to. Doing something when the process is explicitly killed, or lesser when X is pressed (other than a quick "do you want to save Y/N?") should never happen. Other than online applications where a connection to a server needs to be closed, I'd question any situation where it's necessary.

 

[Engr. Adiktuzmiko]

@Amy - that's exactly what she wanna do:

Basically I want to capture attempts to close the game and popup an in-game window that asks "are you sure you want to exit?"