Method Destroy

source/script_gui.cpp:2134–2218

void GuiType::Destroy()
// Destroys the window and performs related cleanup which is only necessary for
// a successfully constructed Gui, then calls Dispose() for the remaining cleanup.
{
	if (!mHwnd)
		return; // We have already been destroyed.

	// First destroy any windows owned by this window, since they will be auto-destroyed
	// anyway due to their being owned.  By destroying them explicitly, the Destroy()
	// function is called recursively which keeps everything relatively neat.
	// Lexikos: I'm not really sure what Chris meant by "neat", since Destroy() is called
	// recursively via WM_DESTROY anyway.  It's currently left to WM_DESTROY because the
	// code below is actually broken in two ways (unique to the new object-oriented API):
	//  1) If there are no external references to gui, it will be deleted and gui->mNextGui
	//     will likely crash the program.
	//  2) Destroy() removes the gui from the list, which causes the loop to break at the
	//     first owned/child window.  Saving the next/previous link before-hand may not
	//     solve the problem since Destroy() could recursively destroy other windows.
	//for (GuiType* gui = g_firstGui; gui; gui = gui->mNextGui)
	//	if (gui->mOwner == mHwnd)
	//		gui->Destroy();

	// Testing shows that this must be done prior to calling DestroyWindow() later below, presumably
	// because the destruction immediately destroys the status bar, or prevents it from answering messages.
	// MSDN says "During the processing of [WM_DESTROY], it can be assumed that all child windows still exist".
	// However, for DestroyWindow() to have returned means that WM_DESTROY was already fully processed.
	if (mStatusBarHwnd) // IsWindow(gui.mStatusBarHwnd) isn't called because even if possible for it to have been destroyed, SendMessage below should return 0.
	{
		// This is done because the vast majority of people wouldn't want to have to worry about it.
		// They can always use DllCall() if they want to share the same HICON among multiple parts of
		// the same bar, or among different windows (fairly rare).
		HICON hicon;
		int part_count = (int)SendMessage(mStatusBarHwnd, SB_GETPARTS, 0, NULL); // MSDN: "This message always returns the number of parts in the status bar [regardless of how it is called]".
		for (int i = 0; i < part_count; ++i)
			if (hicon = (HICON)SendMessage(mStatusBarHwnd, SB_GETICON, i, 0))
				DestroyIcon(hicon);
	}

	if (IsWindow(mHwnd)) // If WM_DESTROY called us, the window might already be partially destroyed.
	{
		// If this window is using a menu bar but that menu is also used by some other window, first
		// detach the menu so that it doesn't get auto-destroyed with the window.  This is done
		// unconditionally since such a menu will be automatically destroyed when the script exits
		// or when the menu is destroyed explicitly via the Menu command.  It also prevents any
		// submenus attached to the menu bar from being destroyed, since those submenus might be
		// also used by other menus (however, this is not really an issue since menus destroyed
		// would be automatically re-created upon next use).  But in the case of a window that
		// is currently using a menu bar, destroying that bar in conjunction with the destruction
		// of some other window might cause bad side effects on some/all OSes.
		ShowWindow(mHwnd, SW_HIDE);  // Hide it to prevent re-drawing due to menu removal.
		::SetMenu(mHwnd, NULL);
		if (!mDestroyWindowHasBeenCalled)
		{
			mDestroyWindowHasBeenCalled = true;  // Signal the WM_DESTROY routine not to call us.
			DestroyWindow(mHwnd);  // The WindowProc is immediately called and it now destroys the window.
		}
		// else WM_DESTROY was called by a function other than this one (possibly auto-destruct due to
		// being owned by script's main window), so it would be bad to call DestroyWindow() again since