Sent this email to Scott Guthrie today...
-
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
IMHO MDI is deprecated from years and I personally strongly prefer SDI interfaces, though you have a point that this is not a reason to exclude it from the new technologies.
The narrow specialist in the broad sense of the word is a complete idiot in the narrow sense of the word. Advertise here – minimum three posts per day are guaranteed.
-
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
-
IMHO MDI is deprecated from years and I personally strongly prefer SDI interfaces, though you have a point that this is not a reason to exclude it from the new technologies.
The narrow specialist in the broad sense of the word is a complete idiot in the narrow sense of the word. Advertise here – minimum three posts per day are guaranteed.
I disagree. While SDI/Tabbed UIS are often better, there are times that MDI makes much more sense. Popup's in a web browser are the most prominent example at present. It doesn't matter in SDI, but there's no good way to handle popups in a tabbed browser. You can make them a tab and forcibly resize them. This trashes the html layout. Or you can spawn them as a separate top level object and have them floating separately on the task bar. This breaks the entire everything as a tab paradigm by making some windows behave differently. If you want to switch from the main page to the tab instead of the tab bar you have to use the task bar, if you're trying to switch between two tabs and the popup it's even worse since you have to constantly move you mouse from the top to the bottom of the monitor and back. X| Opera gets this right by using MDI to fake tabs. Popups just open as nonmaximized "tabs", and function identically to any other page in your browser. It's also trivial to compare two pages side by side by just unmaximizing them and adjusting their positions. In a tabbed interface you have to create a new top level instance and copy the URL over, which only works if all the state is encoded in either the URL or a cookie. If you're browsing a site that uses frames (or etc) to hide internal structure from the url bar, or a flash heavy site, or a page with significant amounts of changes done via user input (only) you can't even do all of that. In IE7 you're SOL. FF supports some, but not all of this via tab dragging (user input yes, CP's pinned posts no, others not tested).
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
-
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
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.
-
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