A 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?
I like the MDI version of Visual Studio best. Here are my reasons:
– It is easily possible to create a new horizontal or vertical window to see files side-by-side
– It is possible to drag-and-drop files from one window to the other
– It is even possible to have tool windows like the Solution Explorer behave like normal documents for those cases where you need LOTS of space in a tool window
Dirk
Some kind of child window management is something that we will find important as we embark on an Avalon app (a decision that is waiting until after next week to be finalized). One thing that we don’t want to see is the overlapping windows within a window. The designs we are playing with now feature an area where windows all “dock” to fill up the available space, but a window can be pulled out to float out of the main window. This is similar to the Visual Studio flavor, but with more than one “main” child window.
I would like to see any code that you come up with as a guide to managing windows.
Thanks for the post on explaining reasons for excluding MDI support (in Avalon). Would it possible to post a simple example of window management (as Robert mentions) or have (ChrisAn?) a version of AvPad posted that works with the latest bits (september CTP)?
For legacy apps that are planning (speaking from experience) to migrate to this new technology (and benifit from using .NET instead of unmanaged C++), this will be really helpful. In our case it’s a giant app with a backdrop of MDI windows. With the new Avalon framework MDI is the not the best of look/feel, but maintaining that support is really important.
– Keeron
Thanks for the feedback – and keep it coming if you have more. :) I’ll put together a sample and post it in the coming weeks.
Lauren,
is the example already flying around somewhere? I would love to see how you would implement this MDI functionality. Im am currently looking into it too. Especially I am interetested in how to implement the visual studio like behavior where you can “tear off” a docked client window and make it show outside the parent window (without winforms interop).
If you ever do revive MDI, please make it more multiple monitor friendly :)
That is, have it so that I can pull a window out of its container window. It’d be nice i I could read two pages of code on two monitors in the same instance of VS.NET.
“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 sure be interested in seeing something like you discussed above. Thanks!
I would really like to see some examples of a MDI interface particularly in the mould of a Visual Studio or Adobe Photoshop type interface (the latter in later versions is a particularly good example as it is multiple monitor friendly).
I can see your reasons for leaving it out, but really think that we can have the best of both worlds and it should be up to the developer to decided what is best for their applications.
Hello, this is one of the best post about MDI even nowadays.
Well best would be to allow the MDI to be so extensible that the developer could choose/implement the behavior like Firefox or Excel.
I’m not very big fan of interop, but I definitely would like to see real windows managed by OS as well.
The docking/floating part is separate story (at least for the interop way), and there should by styling available to adjust the look of the tool windows. Also as rei mentioned, multiple monitors scenario should be supported, although I don’t think MDI windows should be draggable out of the parent window (except the tool windows of course).
Jan
I’ve been thinking for weeks on how to covert a line-of-business application that is MDI to non-MDI. I can’t think of a good way.
I think this (http://laurenlavoie.com/avalon/70) post had only excuses you make when want to cover your bum. I didn’t see anything in it that was reasonable. It’s 2008 now and MS doesn’t have an example of MDI.
I think the WPF Team didn’t do MDI because they didn’t know how to do it well. The WPF framework/model is not great at everything. Fine Control of Windows is one example.
Of course the old Windows models weren’t that great either. You always had to do lots of API code and kludge arounds if you wanted to handle multiple monitors, figure out working areas when tool bars were involved, handle mulitple monitors position changes, handle changes in resolution, or center dialog boxes over a MDI window. You can kludge around with interop, but you still have the original MDI issues.
To make a MDI application with Windows Forms interiop. doesn’t work easy.
I made a simple Windows Forms MDI application, with the ElementHost control in each child windows. As soon as you scroll the bars on MDI host, you’ll get int serious refresh/repaint problems with ElementHost.
See my post on:
http://social.msdn.microsoft.com/Forums/en-US/wpf/thread/6f88715b-b9ca-4d4f-974b-97b334d26347/
I’m thinking about to convert my olds bussiness applications to WPF but are MDI applications. I don’t understand why Microsoft didn’t include the MDI concept that is commonly used by a lot of applications. They want the people use their new tecnologies but don’t help to an easy migration. I think WPF is for small applications by now.