Comment Feed for WPF and the reinvention of MDI (Coffeehouse on Channel 9)

Re: Re: WPF and the reinvention of MDI

kainhart — Thu, 26 Mar 2009 16:14:42 GMT

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

Re: Re: Re: WPF and the reinvention of MDI

DCMonkey — Mon, 30 Jun 2008 04:35:46 GMT

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.

Re: Re: WPF and the reinvention of MDI

JChung2006 — Mon, 30 Jun 2008 03:17:16 GMT

Tabs are MDI. And this thread is ancient.

Re: WPF and the reinvention of MDI

VB Man — Mon, 30 Jun 2008 01:58:23 GMT

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

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

Re: Re: WPF and the reinvention of MDI

chuck p — Sun, 29 Jun 2008 22:21:11 GMT

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.

Re: WPF and the reinvention of MDI

Tom Servo — Sat, 15 Apr 2006 10:15:16 GMT

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.

Re: WPF and the reinvention of MDI

DCMonkey — Sat, 15 Apr 2006 07:52:55 GMT

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.

Re: WPF and the reinvention of MDI

reinux — Sat, 15 Apr 2006 06:35:25 GMT

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.

Re: WPF and the reinvention of MDI

Tom Servo — Fri, 14 Apr 2006 11:01:05 GMT

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.

Re: WPF and the reinvention of MDI

Tom Servo — Fri, 14 Apr 2006 10:59:28 GMT

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.

Re: WPF and the reinvention of MDI

reinux — Fri, 14 Apr 2006 04:45:04 GMT

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.

Re: WPF and the reinvention of MDI

JonathonW — Fri, 14 Apr 2006 04:05:36 GMT

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...

Re: WPF and the reinvention of MDI

reinux — Fri, 14 Apr 2006 03:31:56 GMT

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

Re: WPF and the reinvention of MDI

andokai — Wed, 22 Mar 2006 15:53:35 GMT

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.

Re: WPF and the reinvention of MDI

yman — Wed, 22 Mar 2006 15:11:51 GMT

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 ;)

Re: WPF and the reinvention of MDI

John Galt — Wed, 22 Mar 2006 14:44:53 GMT

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)

Re: WPF and the reinvention of MDI

keeron — Wed, 22 Mar 2006 00:08:52 GMT

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 :-) )

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 .....

Re: WPF and the reinvention of MDI

kettch — Tue, 21 Mar 2006 21:44:47 GMT

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... :s *wanders off looking bemused*