Ask a questionA few people have asked me why the WPF builds that we’ve released don’t include support for MDI. On one hand, I still want to do this for V1. On the other, I can’t imagine making people wait any longer before we ship this thing, on account of adding “just one more feature.”
I do want to call out that the absence of MDI support in WPF does not at all imply that we don’t think this is important. Nor does it mean that we can’t add it in the next version if it doesn’t make it in for V1. There are a couple of factors influencing this decision:
- Shipping. As I’m sure you know, software projects are always a game of making tradeoffs. Tradeoffs between features and other features, between features and bug fixes, between features and ship dates, and so on. MDI will be a huge feature if we implement it right (and implementing it right in this case means making it a true first-class citizen of WPF, so that it integrates well with styling, the property system, etc.), and at some point we had to decide between adding this new large feature and shipping the product.
- Chocolate or vanilla? There are probably about 20 “flavors” of MDI. Word does MDI differently from Excel, Excel does MDI differently from Visual Studio, Visual Studio does MDI differently from Firefox (and yes, you might have caught on to my implication that I think tabbed browsing is just another flavor of MDI), Firefox does MDI differently from OneNote. In fact, a lot of apps use their own custom plumbing for MDI because the flavor provided by the API platform isn’t quite the right one. Before we go implement something as monolithic as MDI, we want to make sure that we choose the right flavor — or do it in a flexible enough way so that our developers can customize it to meet their needs. I don’t think any of us really knows the right way to do this yet — a big part of this needs to come from understanding the needs of customers who are actually building on WPF (that’s you, and hence the ask for feedback at the end of this post).
So what if you want to build an MDI app now? Not all is lost, because there are ways around the limitation. Here are the two that I expect to be most common:
- Use Windows Forms interop. Nick Kramer describes how to do this, with a quick code sample, in this blog post.
- Bake it yourself. This is not as impossible as it sounds. In fact, a lot of apps out there do this today, because they want a different “flavor” of MDI than what comes out of the box with Win32/MFC/WinForms. Chris Anderson’s AvPad makes use of a custom implementation of a child window manager, and Chris claims it wasn’t hard to do. <g>
If there is sufficient interest, I’d be very happy to write up a sample for current external bits showing #2 above — using Chris’s AvPad as a starting point, but really highlighting how to write the child window manager code. My only caveat is that this would happen after PDC.
I’d also love feedback from those of you who are hurting by not having this support now. In particular — what’s your scenario, and what “flavor” of MDI are you looking to produce? Is it more like Excel, Word, Visual Studio, or something else entirely?
