WPF and the reinvention of MDI | The Coffeehouse

DCMonkey
Monkey see, monkey do, monkey will destroy you!

MS has been trying to kill off the Multiple Document Interface (MDI) since Windows 95. Most (all?) of its apps have moved away from it, and while Windows Forms has good support for it, there haven't been any improvements to how it works since Windows 95.

Still, it remains popular for certain kinds of applications with many independent windows, though not so much for its original use with multiple documents. But MS has encouraged developers to move to other designs such as SDI (like traditional browser windows), tabbed workspaces (like modern browsers and IDEs), or navigational models (like web or WPF apps).

Because MDI is discouraged, WPF doesn't support it. So why am I seeing custom MDI implementations in WPF apps? Two examples I can think of are a Fabrikam demo app that I think was used in a Sparkle video here on c9, and more recently, the WPF My Yahoo demo at the end of the keynote at Mix 06.

Should we really be holding these up as examples of good design using WPF, thus encouraging other devs to follow suit? Can we expect to have to deal with numerous differing implementations of MDI in future WPF apps?

Or is MDI perhaps so useful that the usability downsides are worth the utility? Should MS then be supporting and improving MDI and providing a modern consistent implementation for WPF devs to use?

kettch

I could be wrong, but I thought I saw something in a video, or a post somewhere on c9 that talked about MDI in Ava...WPF. The gist that I could see was that when they looked at how various developers were implementing MDI, they saw huge number of variations. Everybody has their own way of doing MDI. So rather than lock everybody into whatever it was that they could come up with, they were going to hold off until a future version until they could come up with a more flexible framework for building MDI apps.

Again, I could be wrong. I really wish I could remember where I saw that... Perplexed *wanders off looking bemused*

keeron
Obsessive Geek

Chris Anderson's AvPad (the one before the XamlPad) did have some MDI - like windows. I think he wrote his own window manager, and basically the child windows were just a bunch of avalon windows that he was managing (showing as child) on the main window.

There is no true MDI support (atleast from the recent builds and blogs, newsgroups)... though I could be wrong (and I really want to be wrong Smiley )

Another option if you truly need a MDI based app (when working Avalon) is to use winform interop and host your "child" windows inside of an Winforms based app... I know this may not be pretty, pure avalon, and can cause tons of other problems... The lack of MDI support from the outset was one of the reasons we are working on our next generation application (earlier ones were in old c++ legacy codebase) using Windows Forms (.net 2.0) and not Avalon. Hopefully WPF V2.0 will be better .....

John Galt

As Tabbed browsing in firefox demonstrates (and now copied in IE) people HATE having 50 browser windows showing up in their Start bar.

MDI is here to stay. The advance of using a tab control to switch between items has eliminated the deficiencies in it and the upside is huge. Especially for advanced users that need to do multiple things at the same time. (i.e. one of the great failures of the web)

yman

John Galt wrote:
As Tabbed browsing in firefox demonstrates (and now copied in IE) people HATE having 50 browser windows showing up in their Start bar.

MDI is here to stay. The advance of using a tab control to switch between items has eliminated the deficiencies in it and the upside is huge. Especially for advanced users that need to do multiple things at the same time. (i.e. one of the great failures of the web)

FF copied Opera Wink

andokai

John Galt wrote:
As Tabbed browsing in firefox demonstrates (and now copied in IE) people HATE having 50 browser windows showing up in their Start bar.

MDI is here to stay. The advance of using a tab control to switch between items has eliminated the deficiencies in it and the upside is huge. Especially for advanced users that need to do multiple things at the same time. (i.e. one of the great failures of the web)

Huh? What exactly is the difference between having 50 pages showing as tabs or on the start bar? And what has tabs got to do with MDI? Tabs != MDI.

To the OP, yeah WPF is missing quite a bit. One thing is there's a distinct lack of common dialogs such as a colour picker. However it's so extensible and the fact that existing controls can be aggregated means that anything not available out of the box will be in short order. Of course the big concern then is consistent look and feel.

reinux

I'm a tad glad that MDI is gone for the time being... working with multiple monitors, it just doesn't make sense to have everything confined to one rectangle. Things have to be able to float out + dock in or it's just really inconvenient. So I'll wait 'til they get that down.

Would be nice if I could have some code on one monitor and some more code on another in the same instance of VS.NET, or if I could just undock a tab from IE7 into its own window.

kettch wrote:

I could be wrong, but I thought I saw something in a video, or a post somewhere on c9 that talked about MDI in Ava...WPF. The gist that I could see was that when they looked at how various developers were implementing MDI, they saw huge number of variations. Everybody has their own way of doing MDI. So rather than lock everybody into whatever it was that they could come up with, they were going to hold off until a future version until they could come up with a more flexible framework for building MDI apps.

Again, I could be wrong. I really wish I could remember where I saw that... *wanders off looking bemused*

http://laurenlavoie.com/avalon/80

CannotResolveSymbol
{insert caption here}

kettch wrote:
I could be wrong, but I thought I saw something in a video, or a post somewhere on c9 that talked about MDI in Ava...WPF. The gist that I could see was that when they looked at how various developers were implementing MDI, they saw huge number of variations. Everybody has their own way of doing MDI. So rather than lock everybody into whatever it was that they could come up with, they were going to hold off until a future version until they could come up with a more flexible framework for building MDI apps.

Again, I could be wrong. I really wish I could remember where I saw that... *wanders off looking bemused*

Nick Kramer's blog: "We don't plan to have a native Avalon implementation of MDI in version 1, mainly because MDI is so easy to do using Windows Forms and Windows Forms interop."

[edit] http://laurenlavoie.com/avalon/80: So there's the other one!! I thought I remembered a second with more detail...

reinux

MDI is a lot harder to do get right than it looks... I started a thread on C9 a while ago (before I heard WPF doesn't support MDI I think) about how MDI is sorta obsolete now that screens are becoming so much bigger and diverse in shape (not even rectangular).

Then I tried rolling my own MDI-ish thing in WinForms but I ran into the question of how the main menu's going to pop up when you "undock" a child window...

So yah, I'm not too surprised Microsoft's stepping away from MDI for the time being. I think it's a good albeit unfortunate decision.

Tom Servo
W-hat?

I have done some MDI myself in Avalon, by deriving the base Window class and overriding all functionality that controls layout and feeding the child element of the actual window class to the window manager, which will use it in the real MDI parent window. Was quite some hackery but it worked.

Tom Servo
W-hat?

CannotResolveSymbol wrote:
Nick Kramer's blog: "We don't plan to have a native Avalon implementation of MDI in version 1, mainly because MDI is so easy to do using Windows Forms and Windows Forms interop."

What a load of crap. Why should I resort Winforms if I want MDI in Avalon? This is the sort of reasoning that annoys me.

reinux

Tom Servo wrote:
I have done some MDI myself in Avalon, by deriving the base Window class and overriding all functionality that controls layout and feeding the child element of the actual window class to the window manager, which will use it in the real MDI parent window. Was quite some hackery but it worked.

Ouch... I just started playing with WPF so I don't really know what all of that involves, but it sounds bad.

I guess there'll be a few MDI libraries out there for us to use. though honestly it's a shame users don't get a platform standard MDI look-and-feel... sorta goes against Windows' UI philosophy.

I wonder if there's any sample MDI code out there? That AvPad thing from the March (2005) CTP doesn't compile.

DCMonkey
Monkey see, monkey do, monkey will destroy you!

Tom Servo wrote:

CannotResolveSymbol wrote: Nick Kramer's blog: "We don't plan to have a native Avalon implementation of MDI in version 1, mainly because MDI is so easy to do using Windows Forms and Windows Forms interop."

What a load of crap. Why should I resort Winforms if I want MDI in Avalon? This is the sort of reasoning that annoys me.

Agreed. If it's so easy, why don't MS's sample apps like the ones I mentioned in the OP use it instead of rolling thier own MDI?

I think WPF navigation style apps could provide alot of what MDI gets used for these days (keeping database front end apps with lots of different screens manageable), and I'd like to see examples from MS guiding us towards that model.

Tom Servo
W-hat?

reinux wrote:
Ouch... I just started playing with WPF so I don't really know what all of that involves, but it sounds bad.

Only if you want an universal implementation.

Since I coded my own stuff specifically for the application itself, I just override what I'm actually using. I didn't do an universal implementation because I keep hoping that they churn out their own implementation.

The idea itself is to have a derived Window class delegate everything to the window manager, who puts the child element of the window into a user control with a 3x3 grid, where the center is what would go into the real window and the remaining fields in the grid are window decoration.

chuck p

In reply to Tom Servo

#Apr 15th, 2006 @ 3:15 AM

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 the MS blog (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.

VB Man
Year of the Linux MCE.

IMO, a tabbed interface looks much more clean than MDI.

I don't think MDI is dead, but its getting there.

JChung2006

In reply to VB Man

#Jun 29th, 2008 @ 6:58 PM

Tabs are MDI. And this thread is ancient.

DCMonkey
Monkey see, monkey do, monkey will destroy you!

In reply to JChung2006

#Jun 29th, 2008 @ 8:17 PM

Tabs are a replacement for MDI. One of many possible replacements.

The MDI being discussed refers to the actual Win32 mechanism called MDI, where you have multiple resizable child windows that act like top level windows but are contained within a parent window. There are a number of Win32 APIs that specifically support this mechanism. I was also referring to any implementations that substantially replicate that behavior. Tabbed interfaces don't. They provide a different behavior that can, in many cases, replace MDI.

And yeah this thread is old. It's also the top Google result for MDI WPF. Kinda scary.

kainhart

In reply to CannotResolveSymbol

#Apr 13th, 2006 @ 9:05 PM

Nick Kramer's blog: "We don't plan to have a native Avalon implementation of MDI in version 1, mainly because MDI is so easy to do using Windows Forms and Windows Forms interop."

Unfortunately for the case of Introp between WPF and Windows Forms MDI, I've run into some basic focus issues that I haven't been able to resolve yet. If this is really the default answer that we use Windows Forms for MDI and embed WPF user controls, we should at least expect for basic things like focus control to work properly.

Issue with setting focus within a WPF UserControl hosted within an ElementHost in a WindowsForms child MDI form
http://social.msdn.microsoft.com/Forums/en-US/wpf/thread/7d41218e-c2bb-4957-b0b4-aa24efc4d8c2

https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=426904