Sent this email to Scott Guthrie today...
-
And which particular MDI implementation would you like? The Excel version? The Word version? The Visual Studio version? The plain old vanilla Win Forms version? You may want to take a look at these posts here[^] and here[^] for the current MDI position.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith
As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
Pete O'Hanlon wrote:
The plain old vanilla Win Forms version
Ehm, the plain old vanilla is the Win32 version[^].
-
Hi Scott, I’ve tried the MSDN support phone #’s, forums, etc, and the standard line I get from the support-types is that ‘we don’t have access to our developers’. What I have is a few comments to make regarding WPF that would just never reach the ears of anyone with the authority to make any difference unless I write you personally. Please forgive me for taking this liberty with you. First, my qualifications to make these remarks: I’ve been a developer for thirty years now, 28 of those under Microsoft platforms using Microsoft tools and API’s. I came up through assembly language to C to C++ to C#, and a bunch of other stuff as side trips. I’ve written everything from kernel-mode drivers to web applications. In short, I’ve more than earned my spurs, and the right to raise an issue with a Microsoft developer product or API. Now I’ll get right to the point. Is WPF clever, perhaps even revolutionary, a major jump forward in UI development? Yeah, I suppose so. But in order for a “new thing” to replace an “old thing”, it first needs to provide all the functionality of the “old thing”, and then some! What I’m talking about is MDI support, and I do not mean ElementHost or its’ WPF counterpart. Hybrids present a whole host of issues; no need to belabor them here, no doubt you’re more conversant in them than I am. I’ve found old discussions regarding the lack of MDI support in WPF from three years ago (discussion dropped, never updated), and I’ve found some ‘roll-your-own’ “solutions” on forums here and there that at best stop-gap measures. I’ve even found posts and articles over on CodeProject.com where folks have tried to FAKE an MDI using Tab controls! I give these folks enormous credit for making the best of a bad situation, but honestly, why should they have to? I really used to enjoy the bleeding edge, all-night voyages of discovery, but these days, I find I actually need to sleep now and then… I don’t want to fake or roll-my-own support for something that clearly belongs in WPF, regardless of the clear disdain Microsoft seems to be showing for MDI these days. Believe it or not, there remain some programming problems for which there is still no better solution! Add to the above that the WPF tools, be they Blend or VS are not a lot of help, and WPF documentation is, to my mind, pretty sparse. So what gives, Scott? Is MDI going to be implemented as a first-class citizen of WPF, or is it now ‘deprecated’? Bottom line for me, WPF is a long way from being capable of supplanting WinForms anytime soon; it’s a
I totally agree. Even in Office 2010 Excel is still an MDI application. They've converted Access from MDI to SDI interface with Office 2007, and there is no benefit, usability has gotten worse. Multimonitor support isn't any better with tabs than with MDI client windows and I can't even watch tables side by side anymore. So if they want to get rid of MDI they have to provide something better. But they are providing nothing. I also think that it's typical for Microsoft these days to say "we are looking into this for vNext" and then do nothing. They don't care about their customers. Microsoft doesn't get anything done these days. The VC++ team had a "slow chat" over at Codeguru before VS2005 and VS2008, don't think they have fixed any of the issues or implemented any of the request from 5 years ago. Don't know how many years they are talking about a native replacement for MFC, but I wouldn't bet on it before 2030.
-
And which particular MDI implementation would you like? The Excel version? The Word version? The Visual Studio version? The plain old vanilla Win Forms version? You may want to take a look at these posts here[^] and here[^] for the current MDI position.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith
As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
Pete, I don't want to be argumentative, but I'd hardly call those current; both were posted in '05... I'd just like to have good ol' child windows in a main frame, ala WPF. No tabs; I need to be able to constrain the children to free-floating columns in the frame, with perhaps a DockPanel + children in them, nothing fancy; I know Tony Gordon has done this. But unless I'm mistaken (a VERY distinct possibility), it's not a 'complete' implementation. Look, compared to you guys, I know very little about WPF. I had in mind a project as something worth doing/fun to do to help me get up to speed, and I'm finding after a good bit of looking at it that it won't suit the project, which kinda defeats the purpose. In fact, I think you may have been one of the ones who convinced me I should take another look at it in a thread I started here a few weeks ago. ;) Regards, Duane
modified on Wednesday, May 27, 2009 5:30 PM
-
If you get a response, please post it here.
It is a truth universally acknowledged that a zombie in possession of brains must be in want of more brains. -- Pride and Prejudice and Zombies
-
I agree about your point on MDI support. It's a nightmare trying to host a WPF Window in a Windows Forms Form; I can't even get it to be constrained by the bounds of the MDI client properly
Computafreak wrote:
I agree about your point on MDI support. It's a nightmare trying to host a WPF Window in a Windows Forms Form; I can't even get it to be constrained by the bounds of the MDI client properly
That's odd; I've not had problems with that part of it...
-
Pete, I don't want to be argumentative, but I'd hardly call those current; both were posted in '05... I'd just like to have good ol' child windows in a main frame, ala WPF. No tabs; I need to be able to constrain the children to free-floating columns in the frame, with perhaps a DockPanel + children in them, nothing fancy; I know Tony Gordon has done this. But unless I'm mistaken (a VERY distinct possibility), it's not a 'complete' implementation. Look, compared to you guys, I know very little about WPF. I had in mind a project as something worth doing/fun to do to help me get up to speed, and I'm finding after a good bit of looking at it that it won't suit the project, which kinda defeats the purpose. In fact, I think you may have been one of the ones who convinced me I should take another look at it in a thread I started here a few weeks ago. ;) Regards, Duane
modified on Wednesday, May 27, 2009 5:30 PM
ddoutel wrote:
both were posted in '05...
Yup - but their thinking hasn't changed on this issue since then. It's handy knowing people in the WPF teams.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith
As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
-
ddoutel wrote:
both were posted in '05...
Yup - but their thinking hasn't changed on this issue since then. It's handy knowing people in the WPF teams.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith
As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
Someone vote you a 1. I had to compensate. This thinking about the MDI applications has been there since I started developing MDI applications 12 years back. As WPF is not based on Win32 windowing it was the right time to drop the feature. There might still be some rare circumstance or two where MDI (classic) applications will be useful but it does not warrant to spend time and effort on it. I would rather have the WPF team fix the major issues with WPF rather than work on MDI.
-
Hi Scott, I’ve tried the MSDN support phone #’s, forums, etc, and the standard line I get from the support-types is that ‘we don’t have access to our developers’. What I have is a few comments to make regarding WPF that would just never reach the ears of anyone with the authority to make any difference unless I write you personally. Please forgive me for taking this liberty with you. First, my qualifications to make these remarks: I’ve been a developer for thirty years now, 28 of those under Microsoft platforms using Microsoft tools and API’s. I came up through assembly language to C to C++ to C#, and a bunch of other stuff as side trips. I’ve written everything from kernel-mode drivers to web applications. In short, I’ve more than earned my spurs, and the right to raise an issue with a Microsoft developer product or API. Now I’ll get right to the point. Is WPF clever, perhaps even revolutionary, a major jump forward in UI development? Yeah, I suppose so. But in order for a “new thing” to replace an “old thing”, it first needs to provide all the functionality of the “old thing”, and then some! What I’m talking about is MDI support, and I do not mean ElementHost or its’ WPF counterpart. Hybrids present a whole host of issues; no need to belabor them here, no doubt you’re more conversant in them than I am. I’ve found old discussions regarding the lack of MDI support in WPF from three years ago (discussion dropped, never updated), and I’ve found some ‘roll-your-own’ “solutions” on forums here and there that at best stop-gap measures. I’ve even found posts and articles over on CodeProject.com where folks have tried to FAKE an MDI using Tab controls! I give these folks enormous credit for making the best of a bad situation, but honestly, why should they have to? I really used to enjoy the bleeding edge, all-night voyages of discovery, but these days, I find I actually need to sleep now and then… I don’t want to fake or roll-my-own support for something that clearly belongs in WPF, regardless of the clear disdain Microsoft seems to be showing for MDI these days. Believe it or not, there remain some programming problems for which there is still no better solution! Add to the above that the WPF tools, be they Blend or VS are not a lot of help, and WPF documentation is, to my mind, pretty sparse. So what gives, Scott? Is MDI going to be implemented as a first-class citizen of WPF, or is it now ‘deprecated’? Bottom line for me, WPF is a long way from being capable of supplanting WinForms anytime soon; it’s a
-
Someone vote you a 1. I had to compensate. This thinking about the MDI applications has been there since I started developing MDI applications 12 years back. As WPF is not based on Win32 windowing it was the right time to drop the feature. There might still be some rare circumstance or two where MDI (classic) applications will be useful but it does not warrant to spend time and effort on it. I would rather have the WPF team fix the major issues with WPF rather than work on MDI.
I couldn't agree more. At some point, I may pull together an MDI framework for WPF, but it's not high on my priority list - and the simple fact is, if I needed to do it right now, I'd just host the WPF inside a Win Forms app.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith
As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
-
Hi Scott, I’ve tried the MSDN support phone #’s, forums, etc, and the standard line I get from the support-types is that ‘we don’t have access to our developers’. What I have is a few comments to make regarding WPF that would just never reach the ears of anyone with the authority to make any difference unless I write you personally. Please forgive me for taking this liberty with you. First, my qualifications to make these remarks: I’ve been a developer for thirty years now, 28 of those under Microsoft platforms using Microsoft tools and API’s. I came up through assembly language to C to C++ to C#, and a bunch of other stuff as side trips. I’ve written everything from kernel-mode drivers to web applications. In short, I’ve more than earned my spurs, and the right to raise an issue with a Microsoft developer product or API. Now I’ll get right to the point. Is WPF clever, perhaps even revolutionary, a major jump forward in UI development? Yeah, I suppose so. But in order for a “new thing” to replace an “old thing”, it first needs to provide all the functionality of the “old thing”, and then some! What I’m talking about is MDI support, and I do not mean ElementHost or its’ WPF counterpart. Hybrids present a whole host of issues; no need to belabor them here, no doubt you’re more conversant in them than I am. I’ve found old discussions regarding the lack of MDI support in WPF from three years ago (discussion dropped, never updated), and I’ve found some ‘roll-your-own’ “solutions” on forums here and there that at best stop-gap measures. I’ve even found posts and articles over on CodeProject.com where folks have tried to FAKE an MDI using Tab controls! I give these folks enormous credit for making the best of a bad situation, but honestly, why should they have to? I really used to enjoy the bleeding edge, all-night voyages of discovery, but these days, I find I actually need to sleep now and then… I don’t want to fake or roll-my-own support for something that clearly belongs in WPF, regardless of the clear disdain Microsoft seems to be showing for MDI these days. Believe it or not, there remain some programming problems for which there is still no better solution! Add to the above that the WPF tools, be they Blend or VS are not a lot of help, and WPF documentation is, to my mind, pretty sparse. So what gives, Scott? Is MDI going to be implemented as a first-class citizen of WPF, or is it now ‘deprecated’? Bottom line for me, WPF is a long way from being capable of supplanting WinForms anytime soon; it’s a
I bet I can guess the response you'll get. Something like: "WPF is a new tool that is better than WinForms at solving many UI problems. However, WinForms is still a viable alternative. Microsoft will be supporting WinForms for the foreseable future." It doesn't feel right to keep using WinForms for new projects though, does it? You get this creepy feeling that all of a sudden you'll be faced with what VB6 developers faced when Visual Studio no longer supported it. I hope that MDI does get support in WPF. Not because I particularly like it per se, but because as developers we need as many tools in our arsenal as possible to solve the problems we face. Andrew Goldie http://www.cyberfuel.co.nz
-
Hi Scott, I’ve tried the MSDN support phone #’s, forums, etc, and the standard line I get from the support-types is that ‘we don’t have access to our developers’. What I have is a few comments to make regarding WPF that would just never reach the ears of anyone with the authority to make any difference unless I write you personally. Please forgive me for taking this liberty with you. First, my qualifications to make these remarks: I’ve been a developer for thirty years now, 28 of those under Microsoft platforms using Microsoft tools and API’s. I came up through assembly language to C to C++ to C#, and a bunch of other stuff as side trips. I’ve written everything from kernel-mode drivers to web applications. In short, I’ve more than earned my spurs, and the right to raise an issue with a Microsoft developer product or API. Now I’ll get right to the point. Is WPF clever, perhaps even revolutionary, a major jump forward in UI development? Yeah, I suppose so. But in order for a “new thing” to replace an “old thing”, it first needs to provide all the functionality of the “old thing”, and then some! What I’m talking about is MDI support, and I do not mean ElementHost or its’ WPF counterpart. Hybrids present a whole host of issues; no need to belabor them here, no doubt you’re more conversant in them than I am. I’ve found old discussions regarding the lack of MDI support in WPF from three years ago (discussion dropped, never updated), and I’ve found some ‘roll-your-own’ “solutions” on forums here and there that at best stop-gap measures. I’ve even found posts and articles over on CodeProject.com where folks have tried to FAKE an MDI using Tab controls! I give these folks enormous credit for making the best of a bad situation, but honestly, why should they have to? I really used to enjoy the bleeding edge, all-night voyages of discovery, but these days, I find I actually need to sleep now and then… I don’t want to fake or roll-my-own support for something that clearly belongs in WPF, regardless of the clear disdain Microsoft seems to be showing for MDI these days. Believe it or not, there remain some programming problems for which there is still no better solution! Add to the above that the WPF tools, be they Blend or VS are not a lot of help, and WPF documentation is, to my mind, pretty sparse. So what gives, Scott? Is MDI going to be implemented as a first-class citizen of WPF, or is it now ‘deprecated’? Bottom line for me, WPF is a long way from being capable of supplanting WinForms anytime soon; it’s a
You could have asked him yourself... http://weblogs.asp.net/scottgu/archive/2009/05/27/lidnug-free-online-virtual-chat-with-me-today.aspx[^]
Mike Lasseter
-
I bet I can guess the response you'll get. Something like: "WPF is a new tool that is better than WinForms at solving many UI problems. However, WinForms is still a viable alternative. Microsoft will be supporting WinForms for the foreseable future." It doesn't feel right to keep using WinForms for new projects though, does it? You get this creepy feeling that all of a sudden you'll be faced with what VB6 developers faced when Visual Studio no longer supported it. I hope that MDI does get support in WPF. Not because I particularly like it per se, but because as developers we need as many tools in our arsenal as possible to solve the problems we face. Andrew Goldie http://www.cyberfuel.co.nz
Actually, Andrew, I'm betting I don't get a response at all! MS actually talks a good game when it comes to saying they want input from the trenches, but from what I've seen, if your name is not known to them...well, you get my point. Yes; completely agree with you regarding the "we'll support it until we won't". Also agree with you regarding the reason for wanting MDI support in WPF; it's not that I like MDI (that would be a strange fetish, indeed), but when you need it, you need it, and anything else is gonna be awkward in a sense that it'll leave your users scratching their heads and wondering what the developer was thinking, at best. Appreciate all the replies, gentlemen! I have a feeling it more than I'll get from ScottGu, busy guy that he must be. Best, Duane Doutel
-
You could have asked him yourself... http://weblogs.asp.net/scottgu/archive/2009/05/27/lidnug-free-online-virtual-chat-with-me-today.aspx[^]
Mike Lasseter
-
Hi Scott, I’ve tried the MSDN support phone #’s, forums, etc, and the standard line I get from the support-types is that ‘we don’t have access to our developers’. What I have is a few comments to make regarding WPF that would just never reach the ears of anyone with the authority to make any difference unless I write you personally. Please forgive me for taking this liberty with you. First, my qualifications to make these remarks: I’ve been a developer for thirty years now, 28 of those under Microsoft platforms using Microsoft tools and API’s. I came up through assembly language to C to C++ to C#, and a bunch of other stuff as side trips. I’ve written everything from kernel-mode drivers to web applications. In short, I’ve more than earned my spurs, and the right to raise an issue with a Microsoft developer product or API. Now I’ll get right to the point. Is WPF clever, perhaps even revolutionary, a major jump forward in UI development? Yeah, I suppose so. But in order for a “new thing” to replace an “old thing”, it first needs to provide all the functionality of the “old thing”, and then some! What I’m talking about is MDI support, and I do not mean ElementHost or its’ WPF counterpart. Hybrids present a whole host of issues; no need to belabor them here, no doubt you’re more conversant in them than I am. I’ve found old discussions regarding the lack of MDI support in WPF from three years ago (discussion dropped, never updated), and I’ve found some ‘roll-your-own’ “solutions” on forums here and there that at best stop-gap measures. I’ve even found posts and articles over on CodeProject.com where folks have tried to FAKE an MDI using Tab controls! I give these folks enormous credit for making the best of a bad situation, but honestly, why should they have to? I really used to enjoy the bleeding edge, all-night voyages of discovery, but these days, I find I actually need to sleep now and then… I don’t want to fake or roll-my-own support for something that clearly belongs in WPF, regardless of the clear disdain Microsoft seems to be showing for MDI these days. Believe it or not, there remain some programming problems for which there is still no better solution! Add to the above that the WPF tools, be they Blend or VS are not a lot of help, and WPF documentation is, to my mind, pretty sparse. So what gives, Scott? Is MDI going to be implemented as a first-class citizen of WPF, or is it now ‘deprecated’? Bottom line for me, WPF is a long way from being capable of supplanting WinForms anytime soon; it’s a
-
Hi Scott, I’ve tried the MSDN support phone #’s, forums, etc, and the standard line I get from the support-types is that ‘we don’t have access to our developers’. What I have is a few comments to make regarding WPF that would just never reach the ears of anyone with the authority to make any difference unless I write you personally. Please forgive me for taking this liberty with you. First, my qualifications to make these remarks: I’ve been a developer for thirty years now, 28 of those under Microsoft platforms using Microsoft tools and API’s. I came up through assembly language to C to C++ to C#, and a bunch of other stuff as side trips. I’ve written everything from kernel-mode drivers to web applications. In short, I’ve more than earned my spurs, and the right to raise an issue with a Microsoft developer product or API. Now I’ll get right to the point. Is WPF clever, perhaps even revolutionary, a major jump forward in UI development? Yeah, I suppose so. But in order for a “new thing” to replace an “old thing”, it first needs to provide all the functionality of the “old thing”, and then some! What I’m talking about is MDI support, and I do not mean ElementHost or its’ WPF counterpart. Hybrids present a whole host of issues; no need to belabor them here, no doubt you’re more conversant in them than I am. I’ve found old discussions regarding the lack of MDI support in WPF from three years ago (discussion dropped, never updated), and I’ve found some ‘roll-your-own’ “solutions” on forums here and there that at best stop-gap measures. I’ve even found posts and articles over on CodeProject.com where folks have tried to FAKE an MDI using Tab controls! I give these folks enormous credit for making the best of a bad situation, but honestly, why should they have to? I really used to enjoy the bleeding edge, all-night voyages of discovery, but these days, I find I actually need to sleep now and then… I don’t want to fake or roll-my-own support for something that clearly belongs in WPF, regardless of the clear disdain Microsoft seems to be showing for MDI these days. Believe it or not, there remain some programming problems for which there is still no better solution! Add to the above that the WPF tools, be they Blend or VS are not a lot of help, and WPF documentation is, to my mind, pretty sparse. So what gives, Scott? Is MDI going to be implemented as a first-class citizen of WPF, or is it now ‘deprecated’? Bottom line for me, WPF is a long way from being capable of supplanting WinForms anytime soon; it’s a
Coincidentally, a friend of mine emailed Scott yesterday morning and got a reply within hours. Scott forwarded the question to Karen Liu and she gave him a detailed response. So there is some hope for you. :-)
Kevin
-
Hi Scott, I’ve tried the MSDN support phone #’s, forums, etc, and the standard line I get from the support-types is that ‘we don’t have access to our developers’. What I have is a few comments to make regarding WPF that would just never reach the ears of anyone with the authority to make any difference unless I write you personally. Please forgive me for taking this liberty with you. First, my qualifications to make these remarks: I’ve been a developer for thirty years now, 28 of those under Microsoft platforms using Microsoft tools and API’s. I came up through assembly language to C to C++ to C#, and a bunch of other stuff as side trips. I’ve written everything from kernel-mode drivers to web applications. In short, I’ve more than earned my spurs, and the right to raise an issue with a Microsoft developer product or API. Now I’ll get right to the point. Is WPF clever, perhaps even revolutionary, a major jump forward in UI development? Yeah, I suppose so. But in order for a “new thing” to replace an “old thing”, it first needs to provide all the functionality of the “old thing”, and then some! What I’m talking about is MDI support, and I do not mean ElementHost or its’ WPF counterpart. Hybrids present a whole host of issues; no need to belabor them here, no doubt you’re more conversant in them than I am. I’ve found old discussions regarding the lack of MDI support in WPF from three years ago (discussion dropped, never updated), and I’ve found some ‘roll-your-own’ “solutions” on forums here and there that at best stop-gap measures. I’ve even found posts and articles over on CodeProject.com where folks have tried to FAKE an MDI using Tab controls! I give these folks enormous credit for making the best of a bad situation, but honestly, why should they have to? I really used to enjoy the bleeding edge, all-night voyages of discovery, but these days, I find I actually need to sleep now and then… I don’t want to fake or roll-my-own support for something that clearly belongs in WPF, regardless of the clear disdain Microsoft seems to be showing for MDI these days. Believe it or not, there remain some programming problems for which there is still no better solution! Add to the above that the WPF tools, be they Blend or VS are not a lot of help, and WPF documentation is, to my mind, pretty sparse. So what gives, Scott? Is MDI going to be implemented as a first-class citizen of WPF, or is it now ‘deprecated’? Bottom line for me, WPF is a long way from being capable of supplanting WinForms anytime soon; it’s a
Matt MacDonald has a Pro WPF book that addresses how to do MDI in WPF. http://www.apress.com/book/view/9781590599556[^] Wanna say it's in Ch 3 or 4. I was able to try it out and see it work, but then I'm not an MDI guru so maybe it has limitations I'm unaware of.
-
Matt MacDonald has a Pro WPF book that addresses how to do MDI in WPF. http://www.apress.com/book/view/9781590599556[^] Wanna say it's in Ch 3 or 4. I was able to try it out and see it work, but then I'm not an MDI guru so maybe it has limitations I'm unaware of.
-
You could have asked him yourself... http://weblogs.asp.net/scottgu/archive/2009/05/27/lidnug-free-online-virtual-chat-with-me-today.aspx[^]
Mike Lasseter
Lidnug (Linked-in Dot Net User Group) is planning to host ScottGu again in a couple of months or so. Keep a lookout on http://www.lidnug.org/[^] for details. The previous session was good fun. Had about 600 people logged in the live meeting. --- Adar Wesley
-
Hi Scott, I’ve tried the MSDN support phone #’s, forums, etc, and the standard line I get from the support-types is that ‘we don’t have access to our developers’. What I have is a few comments to make regarding WPF that would just never reach the ears of anyone with the authority to make any difference unless I write you personally. Please forgive me for taking this liberty with you. First, my qualifications to make these remarks: I’ve been a developer for thirty years now, 28 of those under Microsoft platforms using Microsoft tools and API’s. I came up through assembly language to C to C++ to C#, and a bunch of other stuff as side trips. I’ve written everything from kernel-mode drivers to web applications. In short, I’ve more than earned my spurs, and the right to raise an issue with a Microsoft developer product or API. Now I’ll get right to the point. Is WPF clever, perhaps even revolutionary, a major jump forward in UI development? Yeah, I suppose so. But in order for a “new thing” to replace an “old thing”, it first needs to provide all the functionality of the “old thing”, and then some! What I’m talking about is MDI support, and I do not mean ElementHost or its’ WPF counterpart. Hybrids present a whole host of issues; no need to belabor them here, no doubt you’re more conversant in them than I am. I’ve found old discussions regarding the lack of MDI support in WPF from three years ago (discussion dropped, never updated), and I’ve found some ‘roll-your-own’ “solutions” on forums here and there that at best stop-gap measures. I’ve even found posts and articles over on CodeProject.com where folks have tried to FAKE an MDI using Tab controls! I give these folks enormous credit for making the best of a bad situation, but honestly, why should they have to? I really used to enjoy the bleeding edge, all-night voyages of discovery, but these days, I find I actually need to sleep now and then… I don’t want to fake or roll-my-own support for something that clearly belongs in WPF, regardless of the clear disdain Microsoft seems to be showing for MDI these days. Believe it or not, there remain some programming problems for which there is still no better solution! Add to the above that the WPF tools, be they Blend or VS are not a lot of help, and WPF documentation is, to my mind, pretty sparse. So what gives, Scott? Is MDI going to be implemented as a first-class citizen of WPF, or is it now ‘deprecated’? Bottom line for me, WPF is a long way from being capable of supplanting WinForms anytime soon; it’s a
Sending a random e-mail to someone at MS will get you nowhere. That's equivalent to forcing your way to the front of the line just because you think you'll get somewhere. In the unlikely event he even reads it (given spam filters, junk e-mail and sheer # of e-mails received) he'll probably tell you the same thing everybody else will. Use proper channels or you won't be heard. That's just the way it is. Have you bothered posting to the MSDN Forums? They are the only forums that MS will officially react to. However for all suggestions and bug reports you should post to the Connect site (http://connect.microsoft.com). This is where all future features come from. Scott, while in management and having some control over what goes into releases, isn't ultimately the determinator for what features get added to the product. The feature list is based upon demand, ease of implementation and general usefulness. Most of that information is encapsulated on the Connect item. Management (and there are many of them) sit down and go through the feature lists to determine what is and isn't doable. An e-mail from you isn't going to make that list. Submit your single request (a separate request is needed for each suggestion) and then get your friends to vote on it. Note that it is well beyond too late for anything in VS2010 but enough people vote then you might see something in VS.Next.
-
Hi Scott, I’ve tried the MSDN support phone #’s, forums, etc, and the standard line I get from the support-types is that ‘we don’t have access to our developers’. What I have is a few comments to make regarding WPF that would just never reach the ears of anyone with the authority to make any difference unless I write you personally. Please forgive me for taking this liberty with you. First, my qualifications to make these remarks: I’ve been a developer for thirty years now, 28 of those under Microsoft platforms using Microsoft tools and API’s. I came up through assembly language to C to C++ to C#, and a bunch of other stuff as side trips. I’ve written everything from kernel-mode drivers to web applications. In short, I’ve more than earned my spurs, and the right to raise an issue with a Microsoft developer product or API. Now I’ll get right to the point. Is WPF clever, perhaps even revolutionary, a major jump forward in UI development? Yeah, I suppose so. But in order for a “new thing” to replace an “old thing”, it first needs to provide all the functionality of the “old thing”, and then some! What I’m talking about is MDI support, and I do not mean ElementHost or its’ WPF counterpart. Hybrids present a whole host of issues; no need to belabor them here, no doubt you’re more conversant in them than I am. I’ve found old discussions regarding the lack of MDI support in WPF from three years ago (discussion dropped, never updated), and I’ve found some ‘roll-your-own’ “solutions” on forums here and there that at best stop-gap measures. I’ve even found posts and articles over on CodeProject.com where folks have tried to FAKE an MDI using Tab controls! I give these folks enormous credit for making the best of a bad situation, but honestly, why should they have to? I really used to enjoy the bleeding edge, all-night voyages of discovery, but these days, I find I actually need to sleep now and then… I don’t want to fake or roll-my-own support for something that clearly belongs in WPF, regardless of the clear disdain Microsoft seems to be showing for MDI these days. Believe it or not, there remain some programming problems for which there is still no better solution! Add to the above that the WPF tools, be they Blend or VS are not a lot of help, and WPF documentation is, to my mind, pretty sparse. So what gives, Scott? Is MDI going to be implemented as a first-class citizen of WPF, or is it now ‘deprecated’? Bottom line for me, WPF is a long way from being capable of supplanting WinForms anytime soon; it’s a
To whomever it was that recommended to me in this thread the book Pro WPF in C# 2008 by Matthew MacDonald, I owe you a debt of gratitude; many thanks! Edit: this gentleman turns out to be JHubSharp; dude, this Bud's for you! ;) Best regards, D. T. Doutel