OnBecameVisible and OnBecameInvisible are in the Unity docs as methods of the Renderer and MonoBehaviour classes. It turns out that they work for EditorWindows, too!

They get called when a docked window changes visibility; meaning that when a docked window is hidden by a sibling window within that dock, OnBecameInvisible gets called. Similarly, when the window becomes visible again, of course, OnBecameVisible is called.

using UnityEditor;
using UnityEngine;


public class OnBecameVisibleEditorWindow : EditorWindow
{
	private void OnBecameVisible()
	{
		Debug.Log("Window is visible");
	}

	private void OnBecameInvisible()
	{
		Debug.Log("Window is invisible");
	}


	[MenuItem("Tools/OnBecameVisible Window")]
	public static void Init_ToolsMenu()
	{
		EditorWindow window = EditorWindow.GetWindow<OnBecameVisibleEditorWindow>();
		window.title = "OnBecameVisible";
		window.Show();
	}
}

There is a little gotcha, though. It seems that both methods get called when docking and undocking the window. Not sure why, really. It’s just another Unity quirk!

The Inspector and Project windows both have lock icons beside their context menu buttons, like this:

I’m going to demonstrate how to make one for your own EditorWindow. Simply implement the method ShowButton(Rect rect), and handle a button in there. Some code:

using UnityEditor;
using UnityEngine;


public class ShowButtonEditorWindow : EditorWindow
{
	private GUIStyle m_IconStyle = new GUIStyle();


	private void OnEnable()
	{
		//NOTE: this is the little pac man from the game view tab
		Texture2D icon = EditorGUIUtility.FindTexture("UnityEditor.GameView");
		m_IconStyle.normal.background = icon;
	}

	private void ShowButton(Rect rect)
	{
		if (GUI.Button(rect, GUIContent.none, m_IconStyle))
		{
			Debug.Log("Icon clicked: " + rect);
		}

		//NOTE: you /could/ add extra buttons like this, but
		//		unity doesn't really make room for that, so
		//		there will be some anomalies
		//rect.x -= 16.0f;

		//if (GUI.Button(rect, GUIContent.none, m_IconStyle))
		//{
		//	Debug.Log("Icon clicked");
		//}
	}


	[MenuItem("Tools/Show Button Window")]
	public static void Init_ToolsMenu()
	{
		EditorWindow window = EditorWindow.GetWindow<ShowButtonEditorWindow>();
		window.title = "Show Button";
		window.Show();
	}
}

This will create a button that has the little Pac Man icon from the Game View window that, when clicked, simply spits out a debug log message.

The code that goes inside the body of ShowButton is completely up to you. It’s probably best to stick to the GUI functions and avoid all of the layout stuff.

I’d like to add some notes here about the Rect that is passed to ShowButton. It is created by the Unity Editor’s internal code, and is intended to be used as-is without modification. The x and y are automatically set for you and the dimensions are 16×16. You could technically change the values of the Rect to whatever you want. It’s not really advantageous to do so since it’s possible that the button will not fit correctly into the titlebar. The example code I’ve listed has a commented out section that demonstrates how to make a second button. If you are curious, uncomment that section and open the window. Resize the window to its smallest. Notice the overlap?

I can’t recommend doing this, especially if you’re making a tool that will go on the Asset Store. It’s your window, however, so if you need this for whatever reason, it’s available.

Context-clicking an EditorWindow tab shows the context menu for that window. The standard context menu has the items: Maximize, Close Tab, and Add Tab. Some of the built-in windows have extra items in their context menus, such as the Inspector which also has: Normal, Debug, and Lock.

I’m going to show you how to add your own custom menu items to your window’s context menu. It’s really simple. You just have to implement the IHasCustomMenu interface like so.

using UnityEditor;
using UnityEngine;


public class CustomMenuEditorWindow : EditorWindow, IHasCustomMenu
{
	private GUIContent m_MenuItem1 = new GUIContent("Menu Item 1");
	private GUIContent m_MenuItem2 = new GUIContent("Menu Item 2");

	private bool m_Item2On = false;


	//Implement IHasCustomMenu.AddItemsToMenu
	public void AddItemsToMenu(GenericMenu menu)
	{
		menu.AddItem(m_MenuItem1, false, MenuItem1Selected);
		menu.AddItem(m_MenuItem2, m_Item2On, MenuItem2Selected);

		//NOTE: do not show the menu after adding items,
		//		Unity will do that after adding the default
		//		items: maximize, close tab, add tab >
	}

	private void MenuItem1Selected()
	{
		Debug.Log("Menu Item 1 selected");
	}

	private void MenuItem2Selected()
	{
		m_Item2On = !m_Item2On;

		Debug.Log("Menu Item 2 is " + m_Item2On);
	}


	[MenuItem("Tools/Custom Menu Window")]
	public static void Init_ToolsMenu()
	{
		EditorWindow window = EditorWindow.GetWindow<CustomMenuEditorWindow>();
		window.title = "Custom Menu";
		window.Show();
	}
}

The method of note is AddItemsToMenu(GenericMenu menu). Inside the method body, add the menu items you need in order from top to bottom. If you need to, take a moment to read up on GenericMenu.

Here are the results of the code above.

Context-clicking the window’s tab will show the menu as will clicking the little icon on the right over there. If an item should be checked, just pass a value of true to menu.AddItem() as the on parameter. See Menu Item 2 in the example.

Unity does a weird thing with docked windows when using Maximize, then Unmaximize (uncheck Maximize). When a docked window is maximized, either through the context menu or the space bar, Unity calls OnFocus and OnLostFocus a few times in a row ending with the window focused. When the window is restored, a new instance of the window gets created but never actually becomes visible.

Using Debug logs, what I’m seeing is this sequence

1. OnEnable on new window
2. OnFocus on new window
3. OnLostFocus on old window
4. OnLostFocus on new window
5. OnFocus on old window
6. OnFocus on old window again
7. OnDisable on new window
8. OnDestroy on new window
9. OnFocus on old window

As far as I can tell, the UnityEditor.WindowLayout.Unmaximize() function is the culprit. It’s loading some kind of serialized copy of the window stored as an editor layout. I guess it was created when the window was maximized in order to preserve the window’s dimensions and docked position. Then, when it restores from the layout, it has to deserialize it from the layout file which essentially makes a new instance. It then has to destroy that new instance.

You might be asking, so what? Well, if you have a window that tries to preserve its data by using ScriptableObjects for when the window gets closed and reopened, it matters. Because when the new window instance is created in the background it “steals” the data references and then silently kills them by orphaning those references. So, the old window, the one you are left with has a bunch of dead ScriptableObject references that don’t actually point to your data.

I ran into this with JumpTo. Gonna have to refactor a good bit to work around it.