Dangerous NSTabViews...

I recently had quite some fun figuring out the source of a bug in the Moose. See, since I like to be flexible in re-arranging my GUI elements and e.g. move them to another window, I usually show the window for a GUI element using [[theUIElement window] makeKeyAndOrderFront: self]. This works just fine, right until your UI element lives in a tab view. Because as soon as the tab view changes to another tab, it removes the view of the previous tab from the window, to prevent it from being displayed. This in turn causes the -window method to return nil, which means your -makeKeyAndOrderFront: message isn't sent.

Now, you might be wondering why NSTabView removes its tab views and doesn't just use setHidden:? Well, the problem is that setHidden: was introduced in Mac OS X 10.3. Before that, the only way to hide a view was to take it out of its superview (or, if you don't happen to be NSTabView, you could just use a tabless and borderless NSTabView with your item on one tab and an empty second tab and switch between those).

So, watch out for this if you want to do the smart thing and allow for moving UI items.

Oh, and thanks to my trusty beta tester William M. Smith for not only reporting this bug, but also unknowingly pointing me at the solution. You rock!