It’s published here: http://winrt.codeplex.com
Your name/this blog post is referenced in the readme.txt for credits.

It will take your window back to normal state when it gets maximized. Otherwise make the window state normal before you do the DragMove()

First off, I am extremely humbled and grateful for you taking the time to read and respond to my post. I mean it’s not everyday you get “The Man” to comment on a post of yours. In response to your comments, you, obviously, are correct about how to subclass existing view controllers, etc. However, what I was trying to do was exactly what you stated about rolling your own UITabBar control from scratch. Also, I was trying to create reusable components which, like you said, storyboards are not really suited for. I didn’t want to subclass the existing UITabBar and just draw or add a view on top of it as most posts around the net suggest. That, to me, seems ghetto. I wanted a real control that behaves like a control and is developed in a clean reusable manner. I believe, ultimately, that we’ve come to the same conclusion that storyboards are nifty but they are not suited for complex applications that want to create custom, reusable controls. MonoTouch itself isn’t the issue, it was the use of storyboards that I was trying to shed some light on. Once again, thank you for your response, it is much appreciated!

PS: MonoTouch is freaking awesome, keep up the amazing work!

Thanks,
Bret

The trick to be able to use Xcode to define your storyboard with your controls is to change the “Class” for the UITabBarController in Xcode to a custom name. When you save this, MonoDevelop will automatically create a stub class for you that will contain the proper constructors, like this:

http://tirania.org/s/3f85bf15.png

In this case, I changed the default which was “UITabBarController” to “MyViewController”, and I repeated that with the UITabBar, and renamed that to “MyTabBar”, this is what MonoDevelop generated for me:

http://tirania.org/s/b164e48e.png

I added the “Console.WriteLine (“foo”);” just to show the constructor being invoked.

You are right in saying that storyboards do not have a great pipeline to develop with, in particular for reusable component. They tend to be a grab bag of all the stuff that you will need in your application. The good news is that behind the scenes Xcode or MonoDevelop will generate XIB files out of the main storyboard file.

Now my sample has a problem, it reuses the default TabBarController sample, and although I can change the UITabBar class to a subclass, I can not really replace it with another class that does not implement the same interface as a UITabBar, and this is where things break.

If you wanted to roll your own UI, with your own model that merely happens to look like a UITabBar, you would need to implement UIViewController Containment. It would work, but you would not get much in the way of designer support for it. You could lay the controllers on the screen as UIViewControllers and change the “Class” to your own, but you would not get any visual feedback on what it would actually look like.

Hope this helps,
Miguel