Alternative to MFC
-
>> Can you name some of these companies please? Microsoft Macromedia Adobe ... Need I go on?
-
I would hardly cite Macromedia or Adobe as companies with a UI that should be emulated. Their stuff is just awful for Windows users because it is all written for Mac and then ported to Windows.
I don't know, Macromedia and Adobe products (or at least the ones i've used) have highly functional UI's. The tabbed environments, in particular, are very funcitonal, and even Microsoft have started using them in their latest products. OK, granted that some of MM's products look a bit 'un-windowsish' (i.e. they don't see to use 'out of the bag' common controls) Dreamweaver 4 does elminate that 'pale grey, rounded button' though, that had existed on Window's versions of DW previously. The palettes (as in tool-palettes) are very well organised, and the colour palette popups are easy to use, yet functional. Other than that, the UI's are basically the same as everywhere else. David Wulff dwulff@battleaxe-software.co.uk
-
>> Can you name some of these companies please? Microsoft Macromedia Adobe ... Need I go on?
I would hardly site Microsoft as a company that does not use MFC. They're not called the Microsoft Foundation Classes for nothing. ;P Many of the alternative GUIs that Microsoft develops are based on MFC and then extended. We see the extended classes about a year after they use them. We don't want the competition to get too close...
-
I would hardly site Microsoft as a company that does not use MFC. They're not called the Microsoft Foundation Classes for nothing. ;P Many of the alternative GUIs that Microsoft develops are based on MFC and then extended. We see the extended classes about a year after they use them. We don't want the competition to get too close...
I was under the impression that the office suite and most other major MS apps did not use MFC, but were created using thin wrappers over W32 calls.
-
>> Can you name some of these companies please? Microsoft Macromedia Adobe ... Need I go on?
Microsoft uses MFC in several applications, Money, FrontPage, PhotoDraw, Wordpad, MSPaint, Encarta, Cinemania, Visual C++ 1-6 Development Environment, are all examples of MFC apps within Microsoft. Microsoft has many apps which don't use MFC. Word, Excel and PowerPoint are all apps which generally don't use MFC. I say generally because pieces, like the Clip Art Gallery are MFC apps. There are also many apps at Microsoft that have ripped classes out of MFC, incorporated them into their own sources and effectively use a private version of MFC that they've maintained and enhanced over the years. The reason this is the case is because at Microsoft the choice of development tools is basically up to the development team, there really isn't any standard or requirements. In the case of Office, the additional fact that their codebases pre-date MFC is another reason. However, many groups conciously choose not to use MFC. Marcromedia and Adobe are also special cases because they both write to home-grown frameworks that abstract the MacOS and Windows API to a common API. They reuse most of their codebase for both platforms. There are many non-MS apps which don't use MFC as well, and from the research I've done in the past most of them are either written directly to the Win32 API or they have their own homegrown frameworks. Later, Walter Sullivan Program Manager, ATL/MFC
-
I wonder if there is an alternative framework to MFC that allowes to write GUI Applications in a similar way, because I'm getting tired of it... There are tons of programs and software of famous companies out there that doens't seem at all to use MFC and have a much better look and feel. They write all on their own?... Anybody can give me some hints? Daniel
What would you look for in an alternative to MFC? If Microsoft had another C++ framework, would you expect any of your MFC code, or MFC knowledge, to be carried forward into an alternative? What features of MFC would you most want to be included in a new framework? Do you care about Doc/View? Do you care about ODBC data access? Do you care about ActiveX Control containment or creation? What in MFC could be fixed so that you didn't think you needed an alternative? Not sexy enough? It doesn't have the UI, or features you need? I am interested in this kind of feedback from all of you. I am the Lead Program Manager of our Class Libraries in the Visual C++ team. We have tons of ideas about where we should go with future versions of MFC, ATL, WTL, etc. and could really use your input to help us make sure. Feel free to post here, send me email directly (walters@microsoft.com) or send feedback to our feedback alias at atlwish@microsoft.com. Thanks! Walter Sullivan Program Manager, ATL/MFC
-
I would hardly site Microsoft as a company that does not use MFC. They're not called the Microsoft Foundation Classes for nothing. ;P Many of the alternative GUIs that Microsoft develops are based on MFC and then extended. We see the extended classes about a year after they use them. We don't want the competition to get too close...
God, no. That's not what I meant. The question was 'companies that product apps not using MFC' - not all MS ones do. That is what I meant.
-
What would you look for in an alternative to MFC? If Microsoft had another C++ framework, would you expect any of your MFC code, or MFC knowledge, to be carried forward into an alternative? What features of MFC would you most want to be included in a new framework? Do you care about Doc/View? Do you care about ODBC data access? Do you care about ActiveX Control containment or creation? What in MFC could be fixed so that you didn't think you needed an alternative? Not sexy enough? It doesn't have the UI, or features you need? I am interested in this kind of feedback from all of you. I am the Lead Program Manager of our Class Libraries in the Visual C++ team. We have tons of ideas about where we should go with future versions of MFC, ATL, WTL, etc. and could really use your input to help us make sure. Feel free to post here, send me email directly (walters@microsoft.com) or send feedback to our feedback alias at atlwish@microsoft.com. Thanks! Walter Sullivan Program Manager, ATL/MFC
Oh boy, can... worms... all over the place :) My biggest beef with MFC is it's blatent violation of encapsulation and it's massive "Everything you could possibly need" classes. Less agregious is the heavy dependance upon Doc/View (Yes, you can disable the Doc/View, but this is more like amputating limbs to lose weight. All the functionality is still there, it's just not used.) If I were going to redesign MFC, i'd do it the way WTL is going. Personally, I think WTL should become a first class VC citizen and demote MFC to "legacy". Although WTL also suffers from some encapsulation leakage as well, and as it expands it seems to be going more and more to the "One class fits all" route. What i'd like to see is WTL using a strict seperation of framework code from the users implementation. I love mixins, but having the users implementation inherit from framework code gets way too messy. For instance, it would be cool to be able to abstract out command handlers into command objects, that way your menu, buttons, views, everything can register themselves for update handling and send messages without having to have everything dependant upon everything else, and without the need for the 50 layers of message dispatching code that currently exists (ok, that's a bit of an exageration, but it feels like it sometimes) Additionaly, I'd like to see whatever framework this is become more standard C++ friendly. use std::string instead of CString, with function helpers for things like localization and resources. completely rip out the legacy exception handling (let's not throw exceptions by reference that need to be deleted) and make the library very exception friendly. Use the C++ RTTI and create much more standard conforming serialization and dynamic object creation methods. Toss the two-stage creation/initialization methodology. Give a lot of thought to overrideables, especially in critical behavior. Prefer template based methods, so you aren't forced to inherit from classes that don't do what you want. Take a page out of the STL and allow much more generic programming. This is your opportunity to make a framework that will live for the next 10 years. Yes, .NET is in the spotlight, but it's not a native C++ framework.
-
What would you look for in an alternative to MFC? If Microsoft had another C++ framework, would you expect any of your MFC code, or MFC knowledge, to be carried forward into an alternative? What features of MFC would you most want to be included in a new framework? Do you care about Doc/View? Do you care about ODBC data access? Do you care about ActiveX Control containment or creation? What in MFC could be fixed so that you didn't think you needed an alternative? Not sexy enough? It doesn't have the UI, or features you need? I am interested in this kind of feedback from all of you. I am the Lead Program Manager of our Class Libraries in the Visual C++ team. We have tons of ideas about where we should go with future versions of MFC, ATL, WTL, etc. and could really use your input to help us make sure. Feel free to post here, send me email directly (walters@microsoft.com) or send feedback to our feedback alias at atlwish@microsoft.com. Thanks! Walter Sullivan Program Manager, ATL/MFC
Things I would love to have: 1) Official support for WTL. Management is skitish about developing with an unsupported library. 2) A more modern "look and feel". Our clients are asking for user interfaces that look like web pages. Support for colored backgrounds and bitmap backgrounds would be great. The ability to easily scale and manipulate fonts would also be wonderful. 3) Better support for switching between views. Again, our clients would like a user interface that looks like a frame based web page. They want a set of tabs off to the left which switch between views on the right. 4) Support for parsing and generating XML would be nice The heat I'm feeling isn't from people using another C++ framework, it's from people who want the look and feel of a web based app.
-
Oh boy, can... worms... all over the place :) My biggest beef with MFC is it's blatent violation of encapsulation and it's massive "Everything you could possibly need" classes. Less agregious is the heavy dependance upon Doc/View (Yes, you can disable the Doc/View, but this is more like amputating limbs to lose weight. All the functionality is still there, it's just not used.) If I were going to redesign MFC, i'd do it the way WTL is going. Personally, I think WTL should become a first class VC citizen and demote MFC to "legacy". Although WTL also suffers from some encapsulation leakage as well, and as it expands it seems to be going more and more to the "One class fits all" route. What i'd like to see is WTL using a strict seperation of framework code from the users implementation. I love mixins, but having the users implementation inherit from framework code gets way too messy. For instance, it would be cool to be able to abstract out command handlers into command objects, that way your menu, buttons, views, everything can register themselves for update handling and send messages without having to have everything dependant upon everything else, and without the need for the 50 layers of message dispatching code that currently exists (ok, that's a bit of an exageration, but it feels like it sometimes) Additionaly, I'd like to see whatever framework this is become more standard C++ friendly. use std::string instead of CString, with function helpers for things like localization and resources. completely rip out the legacy exception handling (let's not throw exceptions by reference that need to be deleted) and make the library very exception friendly. Use the C++ RTTI and create much more standard conforming serialization and dynamic object creation methods. Toss the two-stage creation/initialization methodology. Give a lot of thought to overrideables, especially in critical behavior. Prefer template based methods, so you aren't forced to inherit from classes that don't do what you want. Take a page out of the STL and allow much more generic programming. This is your opportunity to make a framework that will live for the next 10 years. Yes, .NET is in the spotlight, but it's not a native C++ framework.
I love worms...;^) I'm also glad to see that you appear to agree with the need for a native C++ framework. When you say WTL is the way to go, does that mean I can assume you don't really care about any of your existing MFC code being portable to a new library. Do most people feel that way? That's one question we grapple with a lot. Also, could you elaborate on features from MFC you'd expect to exist in a new or updated library from Microsoft but aren't in WTL? For instance: - Do you care about OLE Linking and Embedding - Do you care about built in Printing support - Do you care about easy automation exposure. By that I mean a map based way to expose your automation interface instead of having to author an automation object yourself with ATL and them manually mapping that to your internal app implementation - Do you want STL exclusively for collections and data structures? Or do you expect that we would also continue with our collections. Often times we find that STL isn't very efficient for simply collections. Can you give me some examples of the encapsulation leakage you find particularly egregious? Handle maps in MFC are one I greatly regret. In places I agree we definitely exposed too much, we were trying to be realistic in not keeping anything hidden from you so that you were never backed into a corner. Thanks for the feedback. Walter
-
Things I would love to have: 1) Official support for WTL. Management is skitish about developing with an unsupported library. 2) A more modern "look and feel". Our clients are asking for user interfaces that look like web pages. Support for colored backgrounds and bitmap backgrounds would be great. The ability to easily scale and manipulate fonts would also be wonderful. 3) Better support for switching between views. Again, our clients would like a user interface that looks like a frame based web page. They want a set of tabs off to the left which switch between views on the right. 4) Support for parsing and generating XML would be nice The heat I'm feeling isn't from people using another C++ framework, it's from people who want the look and feel of a web based app.
Thanks for the feedback. As I mentioned in my reply to Erik, does "official support for WTL" also mean that you're willing to start over again with a new class library, leveraging little of your knowledge or source code from MFC? I hear you on the modern look and feel! Take a look at some of the other questions I asked Erik, your feedback would be appreciated as well. Thanks, Walter
-
Oh boy, can... worms... all over the place :) My biggest beef with MFC is it's blatent violation of encapsulation and it's massive "Everything you could possibly need" classes. Less agregious is the heavy dependance upon Doc/View (Yes, you can disable the Doc/View, but this is more like amputating limbs to lose weight. All the functionality is still there, it's just not used.) If I were going to redesign MFC, i'd do it the way WTL is going. Personally, I think WTL should become a first class VC citizen and demote MFC to "legacy". Although WTL also suffers from some encapsulation leakage as well, and as it expands it seems to be going more and more to the "One class fits all" route. What i'd like to see is WTL using a strict seperation of framework code from the users implementation. I love mixins, but having the users implementation inherit from framework code gets way too messy. For instance, it would be cool to be able to abstract out command handlers into command objects, that way your menu, buttons, views, everything can register themselves for update handling and send messages without having to have everything dependant upon everything else, and without the need for the 50 layers of message dispatching code that currently exists (ok, that's a bit of an exageration, but it feels like it sometimes) Additionaly, I'd like to see whatever framework this is become more standard C++ friendly. use std::string instead of CString, with function helpers for things like localization and resources. completely rip out the legacy exception handling (let's not throw exceptions by reference that need to be deleted) and make the library very exception friendly. Use the C++ RTTI and create much more standard conforming serialization and dynamic object creation methods. Toss the two-stage creation/initialization methodology. Give a lot of thought to overrideables, especially in critical behavior. Prefer template based methods, so you aren't forced to inherit from classes that don't do what you want. Take a page out of the STL and allow much more generic programming. This is your opportunity to make a framework that will live for the next 10 years. Yes, .NET is in the spotlight, but it's not a native C++ framework.
Hi, I was just wondering what you think is wrong with the two-stage creation/initialization methodology. Hasn't it got advantages with regard to exception throwing/handling, heap allocation (check for failure) and virtual function calls? Just interested. -------------------------------------------------- If my messages appear curt, I apologize. I try to be brief to save your time as well as mine. --------------------------------------------------
-
I love worms...;^) I'm also glad to see that you appear to agree with the need for a native C++ framework. When you say WTL is the way to go, does that mean I can assume you don't really care about any of your existing MFC code being portable to a new library. Do most people feel that way? That's one question we grapple with a lot. Also, could you elaborate on features from MFC you'd expect to exist in a new or updated library from Microsoft but aren't in WTL? For instance: - Do you care about OLE Linking and Embedding - Do you care about built in Printing support - Do you care about easy automation exposure. By that I mean a map based way to expose your automation interface instead of having to author an automation object yourself with ATL and them manually mapping that to your internal app implementation - Do you want STL exclusively for collections and data structures? Or do you expect that we would also continue with our collections. Often times we find that STL isn't very efficient for simply collections. Can you give me some examples of the encapsulation leakage you find particularly egregious? Handle maps in MFC are one I greatly regret. In places I agree we definitely exposed too much, we were trying to be realistic in not keeping anything hidden from you so that you were never backed into a corner. Thanks for the feedback. Walter
Moving from MFC to another framework of course depends on the richness of the new framework. Arriving at the state our product is in now has taken a lot of dissecting of MFC mostly because MFC is so big and takes control over so much that doing something that doesn't follow the straigth and narrow, takes quite a bit of work. Personally I enjoy many of the features of MFC, especially the message handler framework. The updateUI functionality that treats all UI features the same is a gem. This is really the greatest benefit of the framework for me. When it comes to the other features you mention, I would wish it was possible to make them more pluggable, if you understand what I mean. ATL plug and play attitude about features is a far better approach than the "take it or leave it" approach MFC has. This includes everything from OLE linking and embedding to printing support. I must admit though that I do like the way printing and printing preview is just another result of the drawing code. At my firm we found that using ATL for the automation parts is easier than the MFC approach with nested classes. So no the automation map is not so important because I feel that often you should separate the automation interface from the internal classes anyway. I would love a more up to date framework that we could depend on being maintained for some years. I would hope such a framework would include modern UI-elements as well so that users of the framework are not always years behind the expected look and feel. Another issue that I am curious about is how such a framework would handle new versions. Would it use the binary compatibility approach of MFC. It seems that the binary compatibility approach has hindered addition of new features
-
What would you look for in an alternative to MFC? If Microsoft had another C++ framework, would you expect any of your MFC code, or MFC knowledge, to be carried forward into an alternative? What features of MFC would you most want to be included in a new framework? Do you care about Doc/View? Do you care about ODBC data access? Do you care about ActiveX Control containment or creation? What in MFC could be fixed so that you didn't think you needed an alternative? Not sexy enough? It doesn't have the UI, or features you need? I am interested in this kind of feedback from all of you. I am the Lead Program Manager of our Class Libraries in the Visual C++ team. We have tons of ideas about where we should go with future versions of MFC, ATL, WTL, etc. and could really use your input to help us make sure. Feel free to post here, send me email directly (walters@microsoft.com) or send feedback to our feedback alias at atlwish@microsoft.com. Thanks! Walter Sullivan Program Manager, ATL/MFC
Hi Walter >What would you look for in an alternative to MFC? How about another version of MFC? Ok I like MFC, or most days that is. >If Microsoft had another C++ framework, would you expect any of your MFC code, or MFC knowledge, to be carried >forward into an alternative? You are making me a bit nervous here (not meant seriously). If I had to get a new license whenever BMW released a new version of my favorite car I would be forever learning how to drive a new car. So yes I would like to see a "new" framework build on my previous knowledge. If the "new" framework differs for a good reason and your documentation explains why I would probably concede and get down to learn the new stuff. >What features of MFC would you most want to be included in a new framework? Scanning up and down the hierarchy chart on my wall, how about all of it? I probably don't use a third of those classes regularly but I might want to in the future. The most important feature to me is flexibility. I absolutely hate painting myself into a corner. I hate it even more if a framework starts me of in a corner. > Do you care about Doc/View? Yes I do even though I use it non regularly. It helps to abstract the data from the display. > Do you care about ODBC data access? Yes > Do you care about ActiveX Control containment or creation? Yes >What in MFC could be fixed so that you didn't think you needed an alternative? Adding more classes that not just wrap the functionality of some things but also create new functionalities. Adding some more classes eg: registry wrapper class, two cool classes I found on the net is CAutoFont and CMemDC >Not sexy enough? Sexy for me in a framework is a synonym for consistent and easy to use. >It doesn't have the UI, or features you need? Have a look around this site (I suppose you guys are already doing it). There are lots of good ideas and tips how to do things. www.codeguru.com also has a bunch of good ones. If you know of more let us know. I am already MFC, ATL pregnant no stopping it now. Here is list of goals that a Windows OO framework must adhere to in my opinion. 1) It must be simple to use. 2) It must be consistent in the way things are done. I think MFC is great example here. 3) It must be generic and extendable (Most important to me). I don't like paint and I don't like corners, I like it less if I start in a corner. 4) It must be well documented. Knowing why message maps were chosen above virtual functions makes forgiving a lot easier
-
I love worms...;^) I'm also glad to see that you appear to agree with the need for a native C++ framework. When you say WTL is the way to go, does that mean I can assume you don't really care about any of your existing MFC code being portable to a new library. Do most people feel that way? That's one question we grapple with a lot. Also, could you elaborate on features from MFC you'd expect to exist in a new or updated library from Microsoft but aren't in WTL? For instance: - Do you care about OLE Linking and Embedding - Do you care about built in Printing support - Do you care about easy automation exposure. By that I mean a map based way to expose your automation interface instead of having to author an automation object yourself with ATL and them manually mapping that to your internal app implementation - Do you want STL exclusively for collections and data structures? Or do you expect that we would also continue with our collections. Often times we find that STL isn't very efficient for simply collections. Can you give me some examples of the encapsulation leakage you find particularly egregious? Handle maps in MFC are one I greatly regret. In places I agree we definitely exposed too much, we were trying to be realistic in not keeping anything hidden from you so that you were never backed into a corner. Thanks for the feedback. Walter
First, I do think it's time for a successor to MFC. It seems to carry on too many design decisions forced by compiler and platform limitations that disappered long ago. Few specific points I'd like addressed : * more of a 'pick and use' approach, or to put it differently, good old "you don't pay for what you don't use" C++ design philosophy. More loosely coupled framework should be also easier to learn. * C++ strings and standard containers (STL). Why is it you find them less efficient ? And with a better documentation and debugger support, I see little place for overlapping functionality. Just an opinion ...
-
Thanks for the feedback. As I mentioned in my reply to Erik, does "official support for WTL" also mean that you're willing to start over again with a new class library, leveraging little of your knowledge or source code from MFC? I hear you on the modern look and feel! Take a look at some of the other questions I asked Erik, your feedback would be appreciated as well. Thanks, Walter
The way I look at things, MFC and WTL are complementary to each other. There are applications where MFC is too large and constraining. I would consider WTL a better alternative to writing in straight C/C++ and making API calls. A new class library would not be a problem as long as its well documented in MSDN. As for the questions you asked Erik: - I don't care about OLE linking and embedding. - I would like about printing support that can easily print form based views. - I don't care about automation exposure. - I most certainly want CString. The MFC collection classes should also stay. Most of the problems I've had with MFC have to do with trying to make the interface look modern and annoyances with the way the document - view - framework structure is laid out. I can always get the effect I'm looking for, but I end up having to bend the code into a pretzel to do it.
-
What would you look for in an alternative to MFC? If Microsoft had another C++ framework, would you expect any of your MFC code, or MFC knowledge, to be carried forward into an alternative? What features of MFC would you most want to be included in a new framework? Do you care about Doc/View? Do you care about ODBC data access? Do you care about ActiveX Control containment or creation? What in MFC could be fixed so that you didn't think you needed an alternative? Not sexy enough? It doesn't have the UI, or features you need? I am interested in this kind of feedback from all of you. I am the Lead Program Manager of our Class Libraries in the Visual C++ team. We have tons of ideas about where we should go with future versions of MFC, ATL, WTL, etc. and could really use your input to help us make sure. Feel free to post here, send me email directly (walters@microsoft.com) or send feedback to our feedback alias at atlwish@microsoft.com. Thanks! Walter Sullivan Program Manager, ATL/MFC
I'd like to see at least one more rev of MFC since so many of us are using it, but I don't see the need to have it go on forever. Here are some random thoughts for you: 1) ActiveX Control containment or creation - MFC rules! Future class libraries need to make this as easy as MFC does. 2) DB support - MFC is pretty good, I suspect ya'll could do even better. 3) A complete set of C++ XML classes that are independant of the browser. 4) You can't make printing too easy. 5) I'm tired of doc/view, I'd like some system that encouraged less coupling between data and presentation. 6) I'd like a better network class than the CSocket family, with better support for peer-to-peer networking and interprocess communication in general since that's where the world seems headed. I like network classes that don't depend on a particular version of the web browser. It's such a pain to see a nice feature, and then realize that I'd have to convince my users to upgrade their browser version in order to use it. 7) Better utility classes. Take a look at the utility classes from Sam Blackburn's Windows Foundation Classes ( a name he was using years before MS ) at http://www.samblackburn.com/wfc/ . 8) Is it possible to have a simplier messaging system, that lets any object send a message to any other without making us think about what (if any) windows the two objects might possess? 9) I like the stl collection classes a little bit better than the MFC ones, both will do the job. 10) CString is still the best string class. Make it better!
-
Things I would love to have: 1) Official support for WTL. Management is skitish about developing with an unsupported library. 2) A more modern "look and feel". Our clients are asking for user interfaces that look like web pages. Support for colored backgrounds and bitmap backgrounds would be great. The ability to easily scale and manipulate fonts would also be wonderful. 3) Better support for switching between views. Again, our clients would like a user interface that looks like a frame based web page. They want a set of tabs off to the left which switch between views on the right. 4) Support for parsing and generating XML would be nice The heat I'm feeling isn't from people using another C++ framework, it's from people who want the look and feel of a web based app.
> 4) Support for parsing and generating XML would be nice. No! I love XML and use it so often in my MFC applications, but the idea of XML being in a new-MFC seems silly to me! I personally now never use any of the MFC containers nor the CString wrapper [most of the new recruits to the company are now C++/STL aware, but not MFC aware... it seems silly having an overlap -- I know there are some problems with the STL, but there are cross-platform/portable solutions to many of these problems). Biggest thing for me is (currently) still having nice and easy access to the WinAPI (maybe in the future simple access to .NET would be required -- I'm working too hard right now to read the pile of printouts I have about that all). From the perspective of an author of international apps [and GUI's], I'd love it if there could be a break between the application and their resources (I have to develop different language DLL's) and am sick of having to write handlers for all of the "load some ID from the attached resources" type calls. Ray.
-
What would you look for in an alternative to MFC? If Microsoft had another C++ framework, would you expect any of your MFC code, or MFC knowledge, to be carried forward into an alternative? What features of MFC would you most want to be included in a new framework? Do you care about Doc/View? Do you care about ODBC data access? Do you care about ActiveX Control containment or creation? What in MFC could be fixed so that you didn't think you needed an alternative? Not sexy enough? It doesn't have the UI, or features you need? I am interested in this kind of feedback from all of you. I am the Lead Program Manager of our Class Libraries in the Visual C++ team. We have tons of ideas about where we should go with future versions of MFC, ATL, WTL, etc. and could really use your input to help us make sure. Feel free to post here, send me email directly (walters@microsoft.com) or send feedback to our feedback alias at atlwish@microsoft.com. Thanks! Walter Sullivan Program Manager, ATL/MFC
Hi Walter, Personally I think some times MFC is too complicated for learners. So as templates. They tend to create maintaince nigthmare. First it looks great for development, but once the product/project is in production and all the developer are moved to another project its hard for the continuation engineering team to pick up. I would say MS initative in .net and C# are in the right direction of simplifying things. Probably some thing like attribute based programming in C++ and a frameworks based on that would be best of world. Ramanan
-
I love worms...;^) I'm also glad to see that you appear to agree with the need for a native C++ framework. When you say WTL is the way to go, does that mean I can assume you don't really care about any of your existing MFC code being portable to a new library. Do most people feel that way? That's one question we grapple with a lot. Also, could you elaborate on features from MFC you'd expect to exist in a new or updated library from Microsoft but aren't in WTL? For instance: - Do you care about OLE Linking and Embedding - Do you care about built in Printing support - Do you care about easy automation exposure. By that I mean a map based way to expose your automation interface instead of having to author an automation object yourself with ATL and them manually mapping that to your internal app implementation - Do you want STL exclusively for collections and data structures? Or do you expect that we would also continue with our collections. Often times we find that STL isn't very efficient for simply collections. Can you give me some examples of the encapsulation leakage you find particularly egregious? Handle maps in MFC are one I greatly regret. In places I agree we definitely exposed too much, we were trying to be realistic in not keeping anything hidden from you so that you were never backed into a corner. Thanks for the feedback. Walter
Walter, I've been using MFC for about 7 years, and ATL for 4....and there are a couple places where MFC -- although very good for application development -- falls short, but I consider ATL leave too much for the developer to do when trying to develop an UI with it. At the same time, I love ATL for algorithm oriented COM objects (in MS Speak: Business Objects -- a very misleading term I think). COM support is very very rough. If I'm in C++, I don't want to use Automation!!! Why is it still forced on me when I drop a control on a dialog?!? If I have an Active X control which has its own interface I want to use it! Message maps are a pain in the butt! So many macros, so little documentation! In my own development, I rarely have found the need for macros that the MFC and ATL groups have. If you were to move away from the current map scheme, I'd suggest a simple "upgrade" application that could hunt for the macros and rework them. Too few virtual functions! Talk about being backed into a corner!!! Why is it that whenever I NEED to override a Doc/View method its not virtual!!!!!!! It may impact performance a bit, but I'm far more worried about the fact that I often have to kludge a solution rather than solve it through a virtual function. Along the same lines, the whole MFC and ATL framework lack any use of classes which can be passed into an object to extend its functionality.....now this may sound odd: Imagine this -- the STL std::sort method allows me to pass a class (or function, but the case of a class is more interesting) to indicate how the sort is to be performed. As a result, I can smuggle lots of code and data into the routine rather than just relying on the method they use. I'm not talking about using iterators!!!! I use this technique in several of my own classes, and it is VERY powerful!!!! What a shame I can't do the same with my MFC frameworks. I use STL rather than the MFC containers. They aren't as efficient, but they are part of the C++ standard. I'd suggest the following: MS should push the STL containers in its sample code UNLESS the sample is trying to show something that requires effiency. Printing support in MFC isn't very good. As a result I avoid printing at all costs. Don't remove what little you have -- fix it! CDocument is not very well encapsulated: There are several public and protected member variables in it....and they aren't documented either! Too many Afx??? methods! Gosh....why not simply make an AFX object and declare all the me