Alternative to MFC
-
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
-
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
Walter, Thanks for your interest in our feeback. I've been using MFC for years and I mostly like it. I started out as an SDK/C programmer back in the Windows 3.1 days. When VC++/MFC came out it was the perfect reason to (a) start programming in C++, and (b) make Windows programming less painful. The problem came several years later when I got exposed to Visual Basic. That's when my impression of MFC changed. As simple as VB is, I've always thought to myself, "Most, if not all, of this abstraction and encapsulation could have also been done with C++!". I can only imagine where MFC's popularity would be today if it would have been written to work just like the VB library. I think you can agree with me that there'd be a heck of a lot more people using C++ to do Windows programming. The VC vs VB argument would probably not exist. Everyone would agree that C++ would be the way to go unless you're a highschool student learning to program. Unfortunately since VB's simplicity goes way beyond the BASIC language, we have a lot of people today that simply can't justify the extra time and effort it takes to do the same things in MFC. If two years ago you would asked me to recommend a new alternative to MFC in C++, I would have said, "Take the VB library and write it in C++". Today, however, I can't say that, given that .NET and C# are on their way in full force. So I kinda feel that you should just maintain MFC as bug-free as possible and focus more of your efforts on .NET, where we're all headed. Thanks again, Alvaro
-
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
Hello Walter; I'm going to sound a bit cynical here, but it would be really nice if you would simply finish WTL, rather than choosing some new direction to go sailing off in. I've programmed MFC for almost 8 years now. I like it, but understand its problems. I've been using WTL for a few months, and am very impressed by it; but Microsoft's lack of support for the class library is quite sad. No documentation at all; incomplete wizards; no replacement for doc/view, etc. To directly answer your questions: I have no use for ODBC or other database technologies; would prefer not to use ActiveX at all if I can avoid it. I like Doc/View, but find it limiting at times; I'd rather see a Model/View/Controller approach added to WTL. I don't think that MFC can be fixed; its flaws are fundamental. (There was a recent article on Publish/Subscribe in WDJ that pointed out what's wrong with MFC's UI update system; see that for more details.) The biggest problem with MFC is that it is so huge and interdependent; the doc.view architecture is very difficult to customize. In my most recent projects I've stopped using it altogether. Thanks for asking about this, though - recently I've been under the impression that you guys are abandoning the desktop for .NET, which I have no interest in. It's good to know that you're still willing to work with us.
-
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
Some more comments on this... I don't care at all about my MFC code being portable. I have found that it is very easy to convert existing MFC code to WTL (at least, for low-level classes; higher-level stuff needs to be rewritten from scratch - but that's a good thing.) I've always felt that the MFC collection classes were a lot easier to use than STL; I tried to use STL in my new WTL project, but gave up and fell back on the built in ATL collections. And _please_ don't replace the simple CString class with that abominable STL string stuff! OLE, printing support, etc. - yeah, whatever. I've never had the need to do anything with OLE or COM, and haven't needed print preview in a long while. Make them available, but make them easy to excise - or more accurately, put them in separate mixin classes so they can be added only where needed.
-
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
Don't be too nervous. MFC is extremely valuable to Microsoft and will be around for a while. MFC is actively under development, we have a full development/test team working on MFC/ATL. Any move to a new library would be as transitional as possible. As for language independant library, that is what the .NET Platform and .NET Frameworks are all about. That is our language independant solution. My team is hardcore C++, counting every byte, every page fault, every CPU cycle, and loving it. We fully accept that for most Windows programmers, that level of optimization and detail isn't necessary, but we are here for those of you who care. Thanks alot for your feedback! Walter
-
Don't be too nervous. MFC is extremely valuable to Microsoft and will be around for a while. MFC is actively under development, we have a full development/test team working on MFC/ATL. Any move to a new library would be as transitional as possible. As for language independant library, that is what the .NET Platform and .NET Frameworks are all about. That is our language independant solution. My team is hardcore C++, counting every byte, every page fault, every CPU cycle, and loving it. We fully accept that for most Windows programmers, that level of optimization and detail isn't necessary, but we are here for those of you who care. Thanks alot for your feedback! Walter
By language independant I think he meant HUMAN language ;) Or perhaps he meant compiler independant. Either way it makes little sense for a C++ framework to independant of C++.
-
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
Yes, I definately agree on the need for a continued native C++ framework. The MFC compatibility issue is a sticky one. I'm the type of person that would prefer to start from scratch and leave MFC for maintenance. Borland did that with OWL, but then again, they also lost a great deal of their customers in the process. Ideally, it would be nice to see some kind of bridge library, that would allow you to use MFC and whatever the new library is together. Not in the same files of course, but perhaps something that provided the necessary state objects and message translations to allow you to use existing MFC from this NFC (New Foundation Classes) system. This would allow you to gradually phase MFC out, or if you're on the bleeding edge, to throw out MFC completely without taking the compatibility hit. Must have features from MFC in the new library: - Printing support - ActiveX support (both for embedding and controls, as well as automation) - Command update mechanisms - Friendly message handlers (translating WPARAM and LPARAM). - Socket support - Full common control wrappers Items that should be included, but heavily changed: - Doc/View (it should really be a full Model/View/Controller framework) - Docking support. Not just toolbars and dialogs, but any kind of window. - SDI/MDI support should be enhanced to provide Multiple top level window support - Thin wrappers, such as CDC, CPen, CWnd, etc.. These classes need to be utility classes rather than base classes though. Not everything needs to (or should) be inherited. Call User functions through a publish/subscribe methodology rather than virtual functions. Other things that should be included: - enhanced windowing support, such as Irregular windows, Transparency, etc... GDI+ support - High/Low level wrappers. Low level are thin wrappers, while high levels add much more abstraction. - Message and command objects, rather than just calling functions. This allows commands to be processed independantly of given windows. - Encapsulate, Encapsulate, Encapsulate. If you need to expose it, use a method. - More generic programming. Use window class objects instead of virtual functions to alter basic behavior. Provide Behavioral objects, ala STL's extension mechanisms, etc.. - Exception friendliness and Exception safety. Things that need to go: - CString. Yes, it's convenient and nice. I like CString, but we have a standard string now. Use it. If you need to add the functionality of CString, do it through utility functions
-
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. --------------------------------------------------
The two stage creation/initialization is fine in some instances (pardon the pun), however it also leads to many problems where C++ objects exist without valid Window objects beneath them. Exceptions can be handled and thrown in a single stage creation process even easier, since you only need to worry about it once rather than twice.
-
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
MFC is OK, but I would like to see bunch of new classes in it (tip: just browse CodeProject and CodeGuru for ideas). Also I prefer to use classes that are as much independent from other classes as possible (atomic classes). Classes that I would like to see in new MFC are: - support for window that automatically resizes/reposition/redraws its childs when resized; same class should be used for all types of windows -views/dialogs/...-; it shouldn't be derived from CWnd but abstract class used by inheritance (class CMyWindow: public CWnd, public CResizer) or as class member; when given window handle class should enumerate all child windows and store their info (rectangle, class name), on eanch OnSize we should call some other function member that would do the resizing. - CMemDC class I really like this kind of public poll. I think that's a way to go.
-
MFC is OK, but I would like to see bunch of new classes in it (tip: just browse CodeProject and CodeGuru for ideas). Also I prefer to use classes that are as much independent from other classes as possible (atomic classes). Classes that I would like to see in new MFC are: - support for window that automatically resizes/reposition/redraws its childs when resized; same class should be used for all types of windows -views/dialogs/...-; it shouldn't be derived from CWnd but abstract class used by inheritance (class CMyWindow: public CWnd, public CResizer) or as class member; when given window handle class should enumerate all child windows and store their info (rectangle, class name), on eanch OnSize we should call some other function member that would do the resizing. - CMemDC class I really like this kind of public poll. I think that's a way to go.
Thanks, I've enjoyed it and received a lot of valuable feedback. Keep the input coming. We're making some plans for the next couple of versions right now and this direct feedback is extremely valuable. Walter Sulivan Lead Program Manager, ATL/MFC
-
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
-
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
We would like to see more functionalty/support for: * localisation * some kind of a layout manager for dialogs/windows * some of the GUI controls that are used in the Office products - perhaps even some nongui ones like the spellchecker stuff. * some way of splitting the MFC dll up so we only pay for the functionality we need - CWnds are great -OLE - sucks. We hate the MFC COM way - nested classes etc - ATL is much easier to use/understand. We love CAxWindow for hosting controls. although the containment through CWnd is cool also We like Doc/View and when we don't think its applicable we can get rid of it easy enough.
-
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
While MFC certainly shows it's age (i.e. code kept in for backward compatibility) I quite like it. It's easy to debug, well understood and documented, and most importantly has had years of testing. Although the size of a statically linked EXE can be on the large size I would most certainly rather have that than write my own Print Preview, or SplitterWnd. ATL is cool but tracking down bugs can be an absolute pig, trying to remember what the template parameters are etc. Sure, use templates but please don't go template mad (I think the STL sets a good example). And please extend the ATL Studio integration. Studio integration with MFC is great (although I would like to see better support for user-defined messages). Whatever becomes your de-facto library please keep this up. And finally, I like to have a choice of libraries. If I am trying to get the smallest possible EXE/DLL I'll put up with the inconveniences of ATL but if I am more concerned with speed of development and maintainability I'll use MFC. I don't think there's one 'silver-bullet' class library, but then again I may be wrong... Good luck. p.s. (For the documentation team: Could we PLEASE have some decent MSDN help for the STL.) Dave Vest http://www.agentransack.com
-
Here is a bit of history for you young kids... Back in the early 90's, Borland had a C++ class library called the Object Windows Library (OWL). It was considered by many (though not me) to be superior to MFC, and was quite popular, but Borland got Microsofted to death and not OWL is just a foot-note in history. OWL is not used in C++ builder. C++ Builder uses the Visual Componenet Library and is essentially Delphi in C++. The last Borland compiler to use OWL was Borland C++ 5.0, although 4.5 was my preferred version. There is nothing wrong with OWL and it works fine, but for some things like COM or ODBC, you may need to use native API calls as OWL doesn't have classes for though. Borland C++ is a fast compiler (after all, it was released in 1995), and is probably available cheap. I just hope you don't mind using 5 year old technology.
-
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
During my work I have faced with many problems of MFC: · Single inheritance in architecture; · Slow ODBC classes - I don't use them at all; · CView derived classes cannot be inserted as control into dialog boxes; · Only little number of applications requires document-view architecture. Most of database applications don't require it at all. However for some other applications DVA (or even model-view-controller architecture) is very convenient. I think you may leave DVA, but it must not be required in all applications. DVA can be implemented as additional layer of classes; · COM & ActiveX: I think MFC cannot provide appropriate COM support. ATL is better choice. I think new library must be based on ATL (as WTL); · Component-based approach - after comparing MFC and Delphi you may found several advantages of Delphi - they are data-aware controls and component-based approach. I prefer using C++ classes instead of ActiveX controls in C++ applications; · Please don't include collection classes in new library. It may use STL, because STL is a good standard library. Let's use standard approaches. · I would rather using WTL then MFC. WTL is fine. It satisfies all these requirements. Please make it standard.