Function IsWindowHung

source/window.cpp:1288–1340

bool IsWindowHung(HWND aWnd)
{
	if (!aWnd) return false;

	// OLD, SLOWER METHOD:
	// Don't want to use a long delay because then our messages wouldn't get processed
	// in a timely fashion.  But I'm not entirely sure if the 10ms delay used below
	// is even used by the function in this case?  Also, the docs aren't clear on whether
	// the function returns success or failure if the window is hung (probably failure).
	// If failure, perhaps you have to call GetLastError() to determine whether it failed
	// due to being hung or some other reason?  Does the output param dwResult have any
	// useful info in this case?  I expect what will happen is that in most cases, the OS
	// will already know that the window is hung.  However, if the window just became hung
	// in the last 5 seconds, I think it may take the remainder of the 5 seconds for the OS
	// to notice it.  However, allowing it the option of sleeping up to 5 seconds seems
	// really bad, since keyboard and mouse input would probably be frozen (actually it
	// would just be really laggy because the OS would bypass the hook during that time).
	// So some compromise value seems in order.  500ms seems about right.  UPDATE: Some
	// windows might need longer than 500ms because their threads are engaged in
	// heavy operations.  Since this method is only used as a fallback method now,
	// it seems best to give them the full 5000ms default, which is what (all?) Windows
	// OSes use as a cutoff to determine whether a window is "not responding":
	DWORD_PTR dwResult;
	#define Slow_IsWindowHung !SendMessageTimeout(aWnd, WM_NULL, 0, 0, SMTO_ABORTIFHUNG, 5000, &dwResult)

	// NEW, FASTER METHOD:
	// This newer method's worst-case performance is at least 30x faster than the worst-case
	// performance of the old method that  uses SendMessageTimeout().
	// And an even worse case can be envisioned which makes the use of this method
	// even more compelling: If the OS considers a window NOT to be hung, but the
	// window's message pump is sluggish about responding to the SendMessageTimeout() (perhaps
	// taking 2000ms or more to respond due to heavy disk I/O or other activity), the old method
	// will take several seconds to return, causing mouse and keyboard lag if our hook(s)
	// are installed; not to mention making our app's windows, tray menu, and other GUI controls
	// unresponsive during that time).  But I believe in this case the new method will return
	// instantly, since the OS has been keeping track in the background, and can tell us
	// immediately that the window isn't hung.
	// Here are some seemingly contradictory statements uttered by MSDN.  Perhaps they're
	// not contradictory if the first sentence really means "by a different thread of the same
	// process":
	// "If the specified window was created by a different thread, the system switches to that
	// thread and calls the appropriate window procedure.  Messages sent between threads are
	// processed only when the receiving thread executes message retrieval code. The sending
	// thread is blocked until the receiving thread processes the message."

	// The use of IsHungAppWindow() (supported under Win2k+) is discouraged by MS,
	// but it's useful to prevent the script from getting hung when it tries to do something
	// to a hung window.
	typedef BOOL (WINAPI *MyIsHungAppWindow)(HWND);
	static MyIsHungAppWindow IsHungAppWindow = (MyIsHungAppWindow)GetProcAddress(GetModuleHandle(_T("user32"))
		, "IsHungAppWindow");
	return IsHungAppWindow ? IsHungAppWindow(aWnd) : Slow_IsWindowHung;
}