Well....after reviewing the MFC beta here is my opinion, for any one who cares.
As every one knows, First of all this is not a MS native library. Some third party library being decorated in MFC dress. Given that there should ideally be a lot of color and convenience for the customers - but my expectations were proved to be too optimistic. Here is why.
1. Most of this MFC beta covers what most people consider as just "skin deep", if you know what I mean. If you remove the "theme" part - the new enterprise controls introduced to MFC are the Dockers and the property grid.
2. The "theme"/coloring/window style/visualization/ribbon, you name it, is just a "painting effect" and not the original ribbon code of MS Office. Given that, the prime question posed by many is why MS should release a library that "mimics" the Office theme when they could port the Office theme code to MFC and release it. Well I do not want to talk about it - may be some licensing issues.
3. Since the theme portion is a "mimic" effect, can the user define and create new themes with this so called Visualization Manager of MFC beta? Nope !! You only get few "hard coded" themes - and like a big teddy bear you have to select only among those four or five themes. You cannot extend or override the predefined themes - at least I could not find any provision for that in the code. And who really cares about that weird Ribbon menus? What extra enterprise functionality your customers would gain if you modify your tool bar to look like a huge horizontal bar with extra large icons?
4. Coming to Source code, well...its a poor job too. Take a look at any of the MFC beta new controls' source code and you would know what I am talking about. The first prominent thing you can find is the abundant misuse of "friend class" feature, followed by the next misuse of "public data members". Not to mention about the global data structures without a namespace or accessor functions.
5. As for the controls themselves, are they efficient? Well...I am not sure - at least I was not impressed. May be I was wrong with this one - but many times I came across unnecessary flickering with controls when resized or re-layed out. May be there are functions inside that we can override to optimize this - but I could not easily find them.
6. And are the controls extensible? Well, take a look at the property gird - it has hard coded property editors for spin control, combo box. Beyond that you cannot have your own in-place editors, such as check boxes (for true/false) or slider control (for integers). Nor could I find much support for extending the stock editors !!
7. The BCGSoft website has offered samples demonstrating the use of few Grid controls such as report grid and multi-column tree view controls etc... But I could not find any Grid control at all inside the MFC beta !! Wondering if MFC beta is kind of "trial" version of BCGSoft control libray, where if you like the MFC then you should go and buy the full BCG Soft Control bar library.
All in all - the only real useful feature I can find in this version (for enterprise level software) is - the docking ability for windows. Beyond that the controls do not stand upto the level of MFC, nor the code does.
Now having cribbed enough about this - lets put few points that could make the VC++ robust. Lets think about What we really want from VC++.
The answer is simple: Lets have VC++ give all that the .Net is providing to its developers. In otherwords,
1. We need the ability to generate, compile and build VC++/Win32/COM dlls on the fly. We have been using VC++ compiler for so many years, they never had the thought of making it re-usable API or component, where as the .Net had this feature built in right from the startup. Why dont we have our cl.exe (and all other apps that are responsible for compiling and generating the dlls) exposed as API? Note that the major power .net has is because of its meta data and its usage in reflection. We DO have metadata for native dlls too - in the form of type-libraries for COM. But we are limited in our reflection ability - we cannot dynamically create a COM dll in memory and load its types from another App. We NEED this ability. This could bring a huge leap for VC++ developers. After all, today they talk about ASP.Net with code behind .net assemblies. If those bloated .net assemblies can bring ASP.net so much power, then imagine how much power c++ native dlls could bring to the web applications.
2. We need all the latest controls the .Net is offering to its developers: Right from the layout panels to the Property Gird UI editors, Form design surfaces, Tray Icon notifiers, Visual Studio debug visualizers...all accessible as WTL controls or MFC/Win32 controls. (Note that once we have the ability to generate C++ dlls on the fly this should become possible and easy.) We need all the sleek looking Grid controls, report controls, mult- column tree controls, property grid controls, HTML surface controls (to bring the effect of styles/themes to our native applications, just like those website styles/themes) ...
3. More importantly - stop pushing managed C++. This alone could be a very big boon for all of us. Give us native XML parsers and do not deprecate the SOAP tool kit.
These should be enough for now.
PS: These are my personal opinions. You may or may not agree with them.
I think the new controls from BCGSoft are only the ribbon and skinning controls. The skinning controls include the toolbar, menu, etc. The treelist (report) grid is not included (I asked) and some other BCGSoft controls like the date, editor, etc. are not included.
I think this will improve the average user's out of the box experience and I'm glad Microsoft was willing to get the controls they did. Many people have asked for this sort of functionality over the years. Perhaps they will extend it as time goes on and requests for more tools comes in from users.
Tom
<NightHawkMail...@googlemail.com> wrote in message
> Well....after reviewing the MFC beta here is my opinion, for any one > who cares.
> As every one knows, First of all this is not a MS native library. Some > third party library being decorated in MFC dress. Given that there > should ideally be a lot of color and convenience for the customers - > but my expectations were proved to be too optimistic. Here is why.
> 1. Most of this MFC beta covers what most people consider as just > "skin deep", if you know what I mean. If you remove the "theme" part - > the new enterprise controls introduced to MFC are the Dockers and the > property grid.
> 2. The "theme"/coloring/window style/visualization/ribbon, you name > it, is just a "painting effect" and not the original ribbon code of MS > Office. Given that, the prime question posed by many is why MS should > release a library that "mimics" the Office theme when they could port > the Office theme code to MFC and release it. Well I do not want to > talk about it - may be some licensing issues.
> 3. Since the theme portion is a "mimic" effect, can the user define > and create new themes with this so called Visualization Manager of MFC > beta? Nope !! You only get few "hard coded" themes - and like a big > teddy bear you have to select only among those four or five themes. > You cannot extend or override the predefined themes - at least I could > not find any provision for that in the code. And who really cares > about that weird Ribbon menus? What extra enterprise functionality > your customers would gain if you modify your tool bar to look like a > huge horizontal bar with extra large icons?
> 4. Coming to Source code, well...its a poor job too. Take a look at > any of the MFC beta new controls' source code and you would know what > I am talking about. The first prominent thing you can find is the > abundant misuse of "friend class" feature, followed by the next misuse > of "public data members". Not to mention about the global data > structures without a namespace or accessor functions.
> 5. As for the controls themselves, are they efficient? Well...I am not > sure - at least I was not impressed. May be I was wrong with this one > - but many times I came across unnecessary flickering with controls > when resized or re-layed out. May be there are functions inside that > we can override to optimize this - but I could not easily find them.
> 6. And are the controls extensible? Well, take a look at the property > gird - it has hard coded property editors for spin control, combo box. > Beyond that you cannot have your own in-place editors, such as check > boxes (for true/false) or slider control (for integers). Nor could I > find much support for extending the stock editors !!
> 7. The BCGSoft website has offered samples demonstrating the use of > few Grid controls such as report grid and multi-column tree view > controls etc... But I could not find any Grid control at all inside > the MFC beta !! Wondering if MFC beta is kind of "trial" version of > BCGSoft control libray, where if you like the MFC then you should go > and buy the full BCG Soft Control bar library.
> All in all - the only real useful feature I can find in this version > (for enterprise level software) is - the docking ability for windows. > Beyond that the controls do not stand upto the level of MFC, nor the > code does.
> Now having cribbed enough about this - lets put few points that could > make the VC++ robust. Lets think about What we really want from VC++.
> The answer is simple: Lets have VC++ give all that the .Net is > providing to its developers. In otherwords,
> 1. We need the ability to generate, compile and build VC++/Win32/COM > dlls on the fly. We have been using VC++ compiler for so many years, > they never had the thought of making it re-usable API or component, > where as the .Net had this feature built in right from the startup. > Why dont we have our cl.exe (and all other apps that are > responsible for compiling and generating the dlls) exposed as API? > Note that the major power .net has is because of its meta data and its > usage in reflection. We DO have metadata for native dlls too - in the > form of type-libraries for COM. But we are limited in our reflection > ability - we cannot dynamically create a COM dll in memory and load > its types from another App. We NEED this ability. > This could bring a huge leap for VC++ developers. After all, today > they talk about ASP.Net with code behind .net assemblies. If those > bloated .net assemblies can bring ASP.net so much power, then imagine > how much power c++ native dlls could bring to the web applications.
> 2. We need all the latest controls the .Net is offering to its > developers: Right from the layout panels to the Property Gird UI > editors, Form design surfaces, Tray Icon notifiers, Visual Studio > debug visualizers...all accessible as WTL controls or MFC/Win32 > controls. (Note that once we have the ability to generate C++ dlls on > the fly this should become possible and easy.) > We need all the sleek looking Grid controls, report controls, mult- > column tree controls, property grid controls, HTML surface controls > (to bring the effect of styles/themes to our native applications, just > like those website styles/themes) ...
> 3. More importantly - stop pushing managed C++. This alone could be a > very big boon for all of us. Give us native XML parsers and do not > deprecate the SOAP tool kit.
> These should be enough for now.
> PS: These are my personal opinions. You may or may not agree with them.
> Well....after reviewing the MFC beta here is my opinion, for any one > who cares.
> As every one knows, First of all this is not a MS native library. Some > third party library being decorated in MFC dress. Given that there > should ideally be a lot of color and convenience for the customers - > but my expectations were proved to be too optimistic. Here is why.
> 1. Most of this MFC beta covers what most people consider as just > "skin deep", if you know what I mean. If you remove the "theme" part - > the new enterprise controls introduced to MFC are the Dockers and the > property grid.
Do you not find this extra benefit attractive? Several months ago, I used a property grid from CodeProject but it would have been more convenient if this had been available to me, as it will be now.
> 2. The "theme"/coloring/window style/visualization/ribbon, you name > it, is just a "painting effect" and not the original ribbon code of MS > Office. Given that, the prime question posed by many is why MS should > release a library that "mimics" the Office theme when they could port > the Office theme code to MFC and release it. Well I do not want to > talk about it - may be some licensing issues.
Well, to be blunt, so what? What do we care whether it is the same code that is running in Office 2007 or not? Actually, I'm glad it's not the same, as the first one is bound to be hacked up and not well factored; first attempts often are. By completely rewriting the API to achieve the same goal, I'm sure it is much cleaner than the original.
> 3. Since the theme portion is a "mimic" effect, can the user define > and create new themes with this so called Visualization Manager of MFC > beta? Nope !! You only get few "hard coded" themes - and like a big > teddy bear you have to select only among those four or five themes. > You cannot extend or override the predefined themes - at least I could > not find any provision for that in the code.
Surely if they support several hard-coded themes, how hard is it to create another hard-coded theme if you have access to the source code? I mean, if they support several themes already, it must be somewhat generic, right?
> And who really cares > about that weird Ribbon menus? What extra enterprise functionality > your customers would gain if you modify your tool bar to look like a > huge horizontal bar with extra large icons?
If you have to ask, then you would not use the ribbon anyway. Users will determine the success of the ribbon; from what I've seen, they are evenly split between loving it and not liking it. You can't argue that a ribbon makes your app look modern, which depending on your audience, is the entire battle (productivity is not a concern to some people).
> 4. Coming to Source code, well...its a poor job too. Take a look at > any of the MFC beta new controls' source code and you would know what > I am talking about. The first prominent thing you can find is the > abundant misuse of "friend class" feature, followed by the next misuse > of "public data members". Not to mention about the global data > structures without a namespace or accessor functions.
That's too bad; Microsoft started this effort months ago, I would have hoped they would have cleaned up the code during that time. No doubt with the proliferation of 3rd party frameworks, the code in the core MFC is (or was) much better than the what is in the 3rd party frameworks.
> 5. As for the controls themselves, are they efficient? Well...I am not > sure - at least I was not impressed. May be I was wrong with this one > - but many times I came across unnecessary flickering with controls > when resized or re-layed out. May be there are functions inside that > we can override to optimize this - but I could not easily find them.
Yup, the performance of BCGSoft is sadly lacking. That's why I chose CodeJock instead. Again, I would have thought MS would have spent all these months improving it to be at least as good as CodeJock, but it doesn't sound like they did.
> 6. And are the controls extensible? Well, take a look at the property > gird - it has hard coded property editors for spin control, combo box. > Beyond that you cannot have your own in-place editors, such as check > boxes (for true/false) or slider control (for integers). Nor could I > find much support for extending the stock editors !!
Same as for the ribbon themes - they must support adding additional editor controls in the same manner as they created the original ones.
> 7. The BCGSoft website has offered samples demonstrating the use of > few Grid controls such as report grid and multi-column tree view > controls etc... But I could not find any Grid control at all inside > the MFC beta !! Wondering if MFC beta is kind of "trial" version of > BCGSoft control libray, where if you like the MFC then you should go > and buy the full BCG Soft Control bar library.
Yes, Microsoft has clearly stated they did not license the entire library, and if you want the whole thing you need to buy the BCGSoft separately.
> All in all - the only real useful feature I can find in this version > (for enterprise level software) is - the docking ability for windows. > Beyond that the controls do not stand upto the level of MFC, nor the > code does.
> Now having cribbed enough about this - lets put few points that could > make the VC++ robust. Lets think about What we really want from VC++.
> The answer is simple: Lets have VC++ give all that the .Net is > providing to its developers. In otherwords,
> 1. We need the ability to generate, compile and build VC++/Win32/COM > dlls on the fly. We have been using VC++ compiler for so many years, > they never had the thought of making it re-usable API or component, > where as the .Net had this feature built in right from the startup. > Why dont we have our cl.exe (and all other apps that are > responsible for compiling and generating the dlls) exposed as API? > Note that the major power .net has is because of its meta data and its > usage in reflection. We DO have metadata for native dlls too - in the > form of type-libraries for COM. But we are limited in our reflection > ability - we cannot dynamically create a COM dll in memory and load > its types from another App. We NEED this ability. > This could bring a huge leap for VC++ developers. After all, today > they talk about ASP.Net with code behind .net assemblies. If those > bloated .net assemblies can bring ASP.net so much power, then imagine > how much power c++ native dlls could bring to the web applications.
> 2. We need all the latest controls the .Net is offering to its > developers: Right from the layout panels to the Property Gird UI > editors, Form design surfaces, Tray Icon notifiers, Visual Studio > debug visualizers...all accessible as WTL controls or MFC/Win32 > controls. (Note that once we have the ability to generate C++ dlls on > the fly this should become possible and easy.) > We need all the sleek looking Grid controls, report controls, mult- > column tree controls, property grid controls, HTML surface controls > (to bring the effect of styles/themes to our native applications, just > like those website styles/themes) ...
> 3. More importantly - stop pushing managed C++. This alone could be a > very big boon for all of us. Give us native XML parsers and do not > deprecate the SOAP tool kit.
> These should be enough for now.
Heh, we sing the same song, you and I. But I've stopped singing it. The reason is there's no way Microsoft will invest in bringing .NET features into native C++, as native C++ is a shrinking market and they really want Windows apps to be managed anyway, as security is better.
I really appreciate your time in writing these opinions. I've referenced them on a private VC++ newsgroup for MVP's, so the dev team at MS can see it.
> The reason is there's no way Microsoft will invest in bringing .NET > features into native C++, as native C++ is a shrinking market and they > really want Windows apps to be managed anyway, as security is better.
>> The reason is there's no way Microsoft will invest in bringing .NET >> features into native C++, as native C++ is a shrinking market and they >> really want Windows apps to be managed anyway, as security is better.
> Ditto.
> --- > Ajay
I've was one of those C++/MFC die-hards. A couple of months ago or so, I started dabbling with C#/WPF GUIs. It's a night/day comparison - C#/WPF being the day.
Instead of hoping for an MFC miracle, I'll be working towards a general model for creating apps with a .Net GUI and a C++ backend for performance sensitive processing.
I agree that the big drive from MS is to get everything into managed apps in the near- and medium-term.
<crystal ball>
IMO, the long-term goal will be web apps as much as possible. .Net will provide the platform security, web-centric applications will fight piracy and simplify distribution.
Web-centric apps will also move the world to a subscription model instead of the current purchase/support subscription model. Properly packaged by marketing gurus, this will look like (and could very well be) a savings by removing the one-time up front charge.
</crystal ball>
I think the recent MFC update makes it pretty clear that there won't be a lot out there for MFC in the future.
"BobF" <rNfOrSePeA...@charter.net> ha scritto nel messaggio A couple of months ago or so, I
> started dabbling with C#/WPF GUIs. It's a night/day comparison - C#/WPF > being the day.
Yes, I also think that C#/WPF is great technology for presentation layer.
However, there are some reasons to still use MFC, like supporting and evolving old code base (which works well, so why rewrite to C#?). Another reason is the fact that - in general - MFC native apps tend to be faster (and smaller) than managed ones, at least on current hardware (for example, at startup, no need for JIT compiling is required, and no need to load the .NET framework "monster").
And C++ is still a very important player in the game, for example, to use multiplatform libraries (scientific libraries like Blitz++, several graphics engines - also open-source, like Coin3D or OpenSceneGraph, etc.). And also for some specific Windows-only stuff, like developing shell-extensions, I think that C++ is the way to go.
BTW: I also would like to congratulate to the OP who started this thread: his post is very interesting reading.
> >> The reason is there's no way Microsoft will invest in bringing .NET > >> features into native C++, as native C++ is a shrinking market and > they > >> really want Windows apps to be managed anyway, as security is better.
> > Ditto.
> > --- > > Ajay
> I've was one of those C++/MFC die-hards. A couple of months ago or so, > I > started dabbling with C#/WPF GUIs. It's a night/day comparison - C#/WPF > being the day.
> Instead of hoping for an MFC miracle, I'll be working towards a general > model for creating apps with a .Net GUI and a C++ backend for > performance > sensitive processing.
> I agree that the big drive from MS is to get everything into managed > apps in > the near- and medium-term.
> <crystal ball>
> IMO, the long-term goal will be web apps as much as possible. .Net will > provide the platform security, web-centric applications will fight > piracy > and simplify distribution.
> Web-centric apps will also move the world to a subscription model > instead of > the current purchase/support subscription model. Properly packaged by > marketing gurus, this will look like (and could very well be) a savings > by > removing the one-time up front charge.
> </crystal ball>
> I think the recent MFC update makes it pretty clear that there won't be > a > lot out there for MFC in the future.
Yes, I agree with you. Once you get into C# and .net it sort of hooks you and doing mfc stuff feels like you are stepping back.
Knowing both mfc and .net is a great advantage as native code systems will be around for a long time (decades). It is easier to go mfc -> .net than the other way around in my opinion.
I think like so many things the application dictates the tools. It's nice having options. The way things stand now I don't think a lot of people would use C++ to do managed code. So, the only place it really shines is in total native, or mixed mode. So, the C++ guys need to continue to improve that experience to keep C++ in the game. I don't think it's going away any time soon.
Tom
"Ian Semmel" <any...@rocketcomp.com.au> wrote in message
> Yes, I agree with you. Once you get into C# and .net it sort of hooks you > and doing mfc stuff feels like you are stepping back.
> Knowing both mfc and .net is a great advantage as native code systems will > be around for a long time (decades). It is easier to go mfc -> .net than > the other way around in my opinion.
> "Ajay Kalra" <ajayka...@yahoo.com> wrote in message > news:230012A9-9AAD-4D59-93C1-D969592381ED@microsoft.com... >>> The reason is there's no way Microsoft will invest in bringing .NET >>> features into native C++, as native C++ is a shrinking market and they >>> really want Windows apps to be managed anyway, as security is better.
>> Ditto.
>> --- >> Ajay
> I've was one of those C++/MFC die-hards. A couple of months ago or so, I > started dabbling with C#/WPF GUIs. It's a night/day comparison - C#/WPF > being the day.
> Instead of hoping for an MFC miracle, I'll be working towards a general > model for creating apps with a .Net GUI and a C++ backend for performance > sensitive processing.
> I agree that the big drive from MS is to get everything into managed apps > in the near- and medium-term.
> <crystal ball>
> IMO, the long-term goal will be web apps as much as possible. .Net will > provide the platform security, web-centric applications will fight piracy > and simplify distribution.
> Web-centric apps will also move the world to a subscription model instead > of the current purchase/support subscription model. Properly packaged by > marketing gurus, this will look like (and could very well be) a savings by > removing the one-time up front charge.
> </crystal ball>
> I think the recent MFC update makes it pretty clear that there won't be a > lot out there for MFC in the future.
G and Ian ... I should've been more clear on this last point. I was referring to updates and new functionality when I said (typed) "there won't be a lot out there for MFC in the future".
Of course there will be plenty of MFC-oriented work for a very, very long time. I just don't believe there will be much evolution for MFC as a technology.
> I think the recent MFC update makes it pretty clear that there won't be a > lot out there for MFC in the future.
It was clear to me many years ago. It made no sense for MSFT to invest any resources in VC++. It still doesnt. MC++ was really not needed. CLI is good but its usefulness is limited to current unmanged C++ environement, which by definition would not want to use .Net.
>> >> The reason is there's no way Microsoft will invest in bringing .NET >> >> features into native C++, as native C++ is a shrinking market and >> they >> >> really want Windows apps to be managed anyway, as security is better.
>> > Ditto.
>> > --- >> > Ajay
>> I've was one of those C++/MFC die-hards. A couple of months ago or so, >> I >> started dabbling with C#/WPF GUIs. It's a night/day comparison - C#/WPF >> being the day.
>> Instead of hoping for an MFC miracle, I'll be working towards a general >> model for creating apps with a .Net GUI and a C++ backend for >> performance >> sensitive processing.
>> I agree that the big drive from MS is to get everything into managed >> apps in >> the near- and medium-term.
>> <crystal ball>
>> IMO, the long-term goal will be web apps as much as possible. .Net will >> provide the platform security, web-centric applications will fight >> piracy >> and simplify distribution.
>> Web-centric apps will also move the world to a subscription model >> instead of >> the current purchase/support subscription model. Properly packaged by >> marketing gurus, this will look like (and could very well be) a savings >> by >> removing the one-time up front charge.
>> </crystal ball>
>> I think the recent MFC update makes it pretty clear that there won't be >> a >> lot out there for MFC in the future.
> Yes, I agree with you. Once you get into C# and .net it sort of hooks you > and doing mfc stuff feels like you are stepping back.
Its a huge step back. And its not just the GUI part. As you traverse thru the framework classes, things like threading, asynchronous constructs make it very appealing. MFC provides an insignifant subset of the framework.
> Knowing both mfc and .net is a great advantage as native code systems will > be around for a long time (decades). It is easier to go mfc -> .net than > the other way around in my opinion.
I felt the same but its not true. Going from MFC, its easy to pick up UI stuff but UI stuff alone is not enough. Its a new way and a much easier way and it doesnt care about Win32 in general(I havent had to use PInvoke so far).
>I think like so many things the application dictates the tools. It's nice >having options. The way things stand now I don't think a lot of people >would use C++ to do managed code.
That is the right decision.
>So, the only place it really shines is in total native, or mixed mode. >So, the C++ guys need to continue to improve that experience to keep C++ in >the game. I don't think it's going away any time soon.
It certainly wont go away but its that specilazed environment now where developers are dwindling in C++.
>> "Ajay Kalra" <ajayka...@yahoo.com> wrote in message >> news:230012A9-9AAD-4D59-93C1-D969592381ED@microsoft.com... >>>> The reason is there's no way Microsoft will invest in bringing .NET >>>> features into native C++, as native C++ is a shrinking market and they >>>> really want Windows apps to be managed anyway, as security is better.
>>> Ditto.
>>> --- >>> Ajay
>> I've was one of those C++/MFC die-hards. A couple of months ago or so, I >> started dabbling with C#/WPF GUIs. It's a night/day comparison - C#/WPF >> being the day.
>> Instead of hoping for an MFC miracle, I'll be working towards a general >> model for creating apps with a .Net GUI and a C++ backend for performance >> sensitive processing.
>> I agree that the big drive from MS is to get everything into managed apps >> in the near- and medium-term.
>> <crystal ball>
>> IMO, the long-term goal will be web apps as much as possible. .Net will >> provide the platform security, web-centric applications will fight piracy >> and simplify distribution.
>> Web-centric apps will also move the world to a subscription model instead >> of the current purchase/support subscription model. Properly packaged by >> marketing gurus, this will look like (and could very well be) a savings >> by removing the one-time up front charge.
>> </crystal ball>
>> I think the recent MFC update makes it pretty clear that there won't be a >> lot out there for MFC in the future.
> G and Ian ... I should've been more clear on this last point. I was > referring to updates and new functionality when I said (typed) "there > won't be a lot out there for MFC in the future".
> Of course there will be plenty of MFC-oriented work for a very, very long > time. I just don't believe there will be much evolution for MFC as a > technology.
Thats how I feel. Its just wasted resources in part of MSFT to even think about it. Keep in mind MSFT has already retired WinForms in favor of WPF.
That could be true. It's hard to predict where it will go, but I think we're talking about many years before the functionality of .NET makes it THAT much better than C++. The only thing that really makes .NET a little better for me, in some cases, is the libraries that are included. There is something to do just about everything. I also think the IDE (including Intellisense) works better with C# code making the coding experience that much nicer. However, I don't think C# desktop applications are easier than MFC. Of course, I have a lot of MFC experience so that helps me be biased. If I were starting a new desktop application today I'd have a difficult time trying to figure out which paradigm to use. The new MFC controls that come in the box might help, but typically the cost of these ltypes of libraries is not a big barrier to purchase. I have a lot of time invested in using MFC and some 3rd party libraries. I've been learning C# and .NET while working on an ASP project so that environment is getting more familiar all the time, but I still feel most at home doing MFC stuff. As long as there are guys like us around MFC will still have life.
Tom
"Ajay Kalra" <ajayka...@yahoo.com> wrote in message
> "Tom Serface" <tom.nos...@camaswood.com> wrote in message > news:A108B960-857A-483A-9F21-5BF5A3E807FA@microsoft.com... >>I think like so many things the application dictates the tools. It's nice >>having options. The way things stand now I don't think a lot of people >>would use C++ to do managed code.
> That is the right decision.
>>So, the only place it really shines is in total native, or mixed mode. >>So, the C++ guys need to continue to improve that experience to keep C++ >>in the game. I don't think it's going away any time soon.
> It certainly wont go away but its that specilazed environment now where > developers are dwindling in C++.
> That could be true. It's hard to predict where it will go, but I think > we're talking about many years before the functionality of .NET makes it > THAT much better than C++. The only thing that really makes .NET a little > better for me, in some cases, is the libraries that are included. There > is something to do just about everything. I also think the IDE (including > Intellisense) works better with C# code making the coding experience that > much nicer. However, I don't think C# desktop applications are easier > than MFC. Of course, I have a lot of MFC experience so that helps me be > biased. If I were starting a new desktop application today I'd have a > difficult time trying to figure out which paradigm to use. The new MFC > controls that come in the box might help, but typically the cost of these > ltypes of libraries is not a big barrier to purchase. I have a lot of > time invested in using MFC and some 3rd party libraries. I've been > learning C# and .NET while working on an ASP project so that environment > is getting more familiar all the time, but I still feel most at home doing > MFC stuff. As long as there are guys like us around MFC will still have > life.
Have you done any WinForms or WPF? Much of the crud of ASP.NET is removed, and it's a much more direct comparison to MFC. (ASP.NET is a hybrid between C#, Javascript, ASP, CSS, HTML, and probably more, that much of the pain is switching between them and confusing the great .NET stuff from the other web crap).
The bulk of what I've done with .NET has been ASP.NET since it needs to run on the web. So, I've done a lot of web forms, but not many WinForms and only WPF for the sake of playing around with it. Are you saying WinForms can be run on the web? If so, I didn't know that.
Tom
"David Ching" <d...@remove-this.dcsoft.com> wrote in message
> Have you done any WinForms or WPF? Much of the crud of ASP.NET is > removed, and it's a much more direct comparison to MFC. (ASP.NET is a > hybrid between C#, Javascript, ASP, CSS, HTML, and probably more, that > much of the pain is switching between them and confusing the great .NET > stuff from the other web crap).
> The bulk of what I've done with .NET has been ASP.NET since it needs to > run on the web. So, I've done a lot of web forms, but not many WinForms > and only WPF for the sake of playing around with it. Are you saying > WinForms can be run on the web? If so, I didn't know that.
No, WinForms can't run on the web. But to compare .NET to MFC, you really should be doing a WinForms or WPF project, and not ASP.NET. ASP.NET, even though it uses C# and has the full .NET framework available to you, still has too much web stuff getting in the way to compare it with the ease of a desktop app.
I believe Silverlight is MS's attempt to have a common framework for both desktop and web development.
There is *no* comparison between MFC and WinForms. Overall .Net is *significantly* ahead in terms of development environment and features. MFC is at least few years behind and will likely die the way it is. There is a reason MFC hasnt had any significant change in last well.. decade. That doesnt mean its not useful now but its long gone as a main platform for GUI apps.
Keep in mind WinForms are now toast. WPF is the new choice.
>However, I don't think C# desktop applications are easier than MFC.
I disagree strongly that C# apps are difficult compared to MFC. MFC is at least 4-10x difficult to master than WinForms. The fact that you are not using C++ and C# instead alone justifies the benefit.
If microsoft came out with MFC in its current form for the first time in 2007, the product will never make it out of the door.
-- Ajay
"Tom Serface" <tom.nos...@camaswood.com> wrote in message
> That could be true. It's hard to predict where it will go, but I think > we're talking about many years before the functionality of .NET makes it > THAT much better than C++. The only thing that really makes .NET a little > better for me, in some cases, is the libraries that are included. There > is something to do just about everything. I also think the IDE (including > Intellisense) works better with C# code making the coding experience that > much nicer. However, I don't think C# desktop applications are easier > than MFC. Of course, I have a lot of MFC experience so that helps me be > biased. If I were starting a new desktop application today I'd have a > difficult time trying to figure out which paradigm to use. The new MFC > controls that come in the box might help, but typically the cost of these > ltypes of libraries is not a big barrier to purchase. I have a lot of > time invested in using MFC and some 3rd party libraries. I've been > learning C# and .NET while working on an ASP project so that environment > is getting more familiar all the time, but I still feel most at home doing > MFC stuff. As long as there are guys like us around MFC will still have > life.
>> "Tom Serface" <tom.nos...@camaswood.com> wrote in message >> news:A108B960-857A-483A-9F21-5BF5A3E807FA@microsoft.com... >>>I think like so many things the application dictates the tools. It's >>>nice having options. The way things stand now I don't think a lot of >>>people would use C++ to do managed code.
>> That is the right decision.
>>>So, the only place it really shines is in total native, or mixed mode. >>>So, the C++ guys need to continue to improve that experience to keep C++ >>>in the game. I don't think it's going away any time soon.
>> It certainly wont go away but its that specilazed environment now where >> developers are dwindling in C++.
> The bulk of what I've done with .NET has been ASP.NET since it needs to > run on the web. So, I've done a lot of web forms, but not many WinForms > and only WPF for the sake of playing around with it. Are you saying > WinForms can be run on the web? If so, I didn't know that.
I know nothing about ASP.Net nor do I care as its not what MFC is about. ASP.Net did not replace MFC. It merely helped making web apps. You are not using MFC to build ASP apps.
Yeah that makes sense. I have done some stuff with WinForms, but not a major project. I'm reticent to spend much time on it now that WPF is becoming more interesting.
Tom
"David Ching" <d...@remove-this.dcsoft.com> wrote in message
> "Tom Serface" <tom.nos...@camaswood.com> wrote in message > news:eXub2IJXIHA.4696@TK2MSFTNGP05.phx.gbl... >> The bulk of what I've done with .NET has been ASP.NET since it needs to >> run on the web. So, I've done a lot of web forms, but not many WinForms >> and only WPF for the sake of playing around with it. Are you saying >> WinForms can be run on the web? If so, I didn't know that.
> No, WinForms can't run on the web. But to compare .NET to MFC, you really > should be doing a WinForms or WPF project, and not ASP.NET. ASP.NET, even > though it uses C# and has the full .NET framework available to you, still > has too much web stuff getting in the way to compare it with the ease of a > desktop app.
> I believe Silverlight is MS's attempt to have a common framework for both > desktop and web development.
I admit I am considering the investment in learning I've already acquired over the years. There are likely a lot of people like me who have already spent a lot of time learning MFC so the comparison is not fair (as if we were starting from scratch). That gives MFC some momentum still. You are right that the tools for using C# and WinForms seem more advanced in the IDE. In fact, the biggest criticism everyone has about MFC is the loss of the better tools we used to have to provide a common IDE that better supports the other languages.
Tom
"Ajay Kalra" <ajayka...@yahoo.com> wrote in message
> There is *no* comparison between MFC and WinForms. Overall .Net is > *significantly* ahead in terms of development environment and features. > MFC is at least few years behind and will likely die the way it is. There > is a reason MFC hasnt had any significant change in last well.. decade. > That doesnt mean its not useful now but its long gone as a main platform > for GUI apps.
> Keep in mind WinForms are now toast. WPF is the new choice.
>>However, I don't think C# desktop applications are easier than MFC.
> I disagree strongly that C# apps are difficult compared to MFC. MFC is at > least 4-10x difficult to master than WinForms. The fact that you are not > using C++ and C# instead alone justifies the benefit.
> If microsoft came out with MFC in its current form for the first time in > 2007, the product will never make it out of the door.
To be fair though, the application I am working on in ASP.NET could have been done in MFC. A previous version was done in MFC, and then in Perl, and then Java, and now ASP.NET. I am impressed at how far we've come with tools for developing web applications. Going from Perl to ASP.NET is like night and day.
Tom
"Ajay Kalra" <ajayka...@yahoo.com> wrote in message
> "Tom Serface" <tom.nos...@camaswood.com> wrote in message > news:eXub2IJXIHA.4696@TK2MSFTNGP05.phx.gbl... >> The bulk of what I've done with .NET has been ASP.NET since it needs to >> run on the web. So, I've done a lot of web forms, but not many WinForms >> and only WPF for the sake of playing around with it. Are you saying >> WinForms can be run on the web? If so, I didn't know that.
> I know nothing about ASP.Net nor do I care as its not what MFC is about. > ASP.Net did not replace MFC. It merely helped making web apps. You are not > using MFC to build ASP apps.
|
