We all have our favourite IDE, and they all provide pretty advanced docking features. Many control libraries in WinForms, WPF, Swing etc have provided this functionality over the years. But are docking suites – which can be complex, fiddly beasts – designed by and for developers what other users really want?
Remember when Google first released Chrome? Tearing tabs out immediately felt so easy and natural I wondered why no-one had done it before. It was one of those UX paradigms that just works. So in designing the docking library for Dragablz I wanted to reduce the complexity of what we have come to expect and provide a UX experience that is much more easy and free flowing. I’ve tried this before on an enterprise application I have been working on and it’s pretty successful with the user base.
The gif below illustrates the simplicity of having quick, easy access dock “zones” that are easy to throw a tab into, instead of having more, smaller, fiddly areas which are harder to hit in traditional setups.
There’s still a little way to go to polish up the code but the basics can be seen in the demo project in the main solution in GitHub.
Assuming you have a reference to the Dragablz assembly, getting tear-able tabs from the TabablzControl is a doddle. The TabablzControl inherits from the standard TabControl so it should be pretty familiar. The first thing you have to look out for is the InterTabController property. You will need to provide an InterTabController instance to inform the tab that you are going to let the user tear out tabs:
That’s all you have place in your XAML Window to achieve this:
I am the master!
OK, so now I imagine you have some questions…such as, how does this work with bound data sources and MVVM? Can I manage the window creation myself?
Well, jumping in and seizing some control for yourself is easy.
The key is setting the InterTabClient property on your InterTabController instance.
You’ll quickly see there are two interfaces involved:
IInterTabClient – let’s you intercept the requirement to create a new window (and tab control) when the user tears out a tab.
INewTabHost – the result of IInterTabClient.GetNewHost. A simple implementation is provided: Dragablz.NewTabHost
The simplest implementation of IInterTabClient will look something like this:
public class MyInterTabClient : IInterTabClient
public INewTabHost GetNewHost(IInterTabClient interTabClient, object partition, TabablzControl source)
var view = new MyWindow();
return new NewTabHost(view, view.TabablzControl); //TabablzControl is a names control in the XAML
public TabEmptiedResponse TabEmptiedHandler(TabablzControl tabControl, Window window)
If you expose an instance of your MyInterTabClient class from you view model, you can bind it into the TabablzControl, via the InterTabController:
After some fiddling with Git, TeamCity and NuGet, a package for Dragablz is now published. Straight off the bat I must apologise for this only being a .Net 4.5 version; I know there is plenty of enterprise out there still on .Net 4.0. A .Net 4.0 version will follow in due course…
Even the web is old hat these days. If you aren’t writing some sort of touch device software you might as well be coding in COBOL. Right?
There are still plenty of desktop requirements out there. I do a lot of work in the enterprise, and – in the enterprise at least – there is still demand for the full richness of desktop software.
A lot of my work is in C# and WPF these days. But WPF is dead, right?
WPF is a great, powerful framework (if it comes with a steep learning curve), but every project I work on I keep banging my head against a couple of core problems. After improving/fixing/retro-fitted some other apps I am now writing a new open source library to solve the main problem. That of fully drag-able (is that a word?) tabs. Chrome/IE style.
There’s plenty of people asking the question on the web, and a few solutions, but I think I have a pretty good mechanism for doing this, so watch this space for what’s coming soon…