Alternative to MFC
-
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.
-
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
I would agree with most of what Eric said, and most of these features are part of the VCF or Visual Component Framework (http://vcf.sourceforge.net). In addition I would want easy to use graphics classes that actually save you time as opposed to the sill CBrush and CPen classes in MFC which require almost as much work as writing the drawing code in plain old Win32 calls. VCF has a pretty easy to use GraphicsContexts class that does just this as well as an extensible approach to Stroke's and Fills. VCF has a standard Model/View/Controller architecture built into all of it's controls (at least where relevant). In addition it also has the Publish/Subscribe or Observer pattern built in as it's event mechanism. Oh, and it seems to have full reflective capabilities almost identical to what is planned in .NET, but using standard C++ (no extensions required !)
-
I would agree with most of what Eric said, and most of these features are part of the VCF or Visual Component Framework (http://vcf.sourceforge.net). In addition I would want easy to use graphics classes that actually save you time as opposed to the sill CBrush and CPen classes in MFC which require almost as much work as writing the drawing code in plain old Win32 calls. VCF has a pretty easy to use GraphicsContexts class that does just this as well as an extensible approach to Stroke's and Fills. VCF has a standard Model/View/Controller architecture built into all of it's controls (at least where relevant). In addition it also has the Publish/Subscribe or Observer pattern built in as it's event mechanism. Oh, and it seems to have full reflective capabilities almost identical to what is planned in .NET, but using standard C++ (no extensions required !)
I've looked at VCF, and talked a bit with the author about it's direction. I think it's a great bit of work, but he seems to be falling into the same pitfalls that make MFC show it's age. Primarily, he's developing his own RTTI system (because not all compilers are standard compliant) and he is developing his own collection classes and other redundancy. I also don't agree with building in any particular architecture into the components. I think that should be up to the developer to decide, and provide a way to use those components in whatever architecture they choose to use. But oh well, he's come a long way, and there's a lot there.
-
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.
OWL will still live on in our hearts. I'm not sure if i would consider it superior to mfc, but I don't remember having any major complaints. Anyone know why OWL died to the sword of MFC? probably MS's monopoly. :(
-
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 am of the opinion that MFC should not be replaced by an alternative but should have some evolution to facilitate it's use. As a beginning programmer we have to learn the use and to understand the behaviour of a lot of functions. Changing that frequently we all remain students to explore or learn a new develoment tool by trying out... and we can't concentrate enough on developing applications and grow in the application of the tool we are working with. As developer we like to have a development tool for rapid and reliable development of applications. That's where we get the money from. In the question Document/View architecture yes I care, because I find this is a consistent way to split data from the view. The mechanism to create a second or a nth view may be improved or made more transparant to the developer and may be better documented. Especially the printing facility could be improved and need to be ficed any way. My experience is if the document has more than 8 pages, printing doen't work properly. The way to go around is to split the document contents over more views. ODBC yes I care because many applications have to be developed on existing databases. In developing UI with resource editor, changing fonts, colors of statics and controls should be made much easier by setting properties as in VBA. A class to create output in HTML will highly be appreciated.
-
I am of the opinion that MFC should not be replaced by an alternative but should have some evolution to facilitate it's use. As a beginning programmer we have to learn the use and to understand the behaviour of a lot of functions. Changing that frequently we all remain students to explore or learn a new develoment tool by trying out... and we can't concentrate enough on developing applications and grow in the application of the tool we are working with. As developer we like to have a development tool for rapid and reliable development of applications. That's where we get the money from. In the question Document/View architecture yes I care, because I find this is a consistent way to split data from the view. The mechanism to create a second or a nth view may be improved or made more transparant to the developer and may be better documented. Especially the printing facility could be improved and need to be ficed any way. My experience is if the document has more than 8 pages, printing doen't work properly. The way to go around is to split the document contents over more views. ODBC yes I care because many applications have to be developed on existing databases. In developing UI with resource editor, changing fonts, colors of statics and controls should be made much easier by setting properties as in VBA. A class to create output in HTML will highly be appreciated.
It's easy to say this, but the reality is that you can't just "evolve" MFC into a better architecture, because there are legacy support concerns. You can't change the basic problems because so much code depends on them. I also don't think you're looking at what a new framework could give you, only looking at your experience. MFC's Document/View architecture is ok, but it's vastly inferior to a true model/view/controller architecture. D/V was poor clone of it, and it needs major changes to make it optimal.
-
OWL will still live on in our hearts. I'm not sure if i would consider it superior to mfc, but I don't remember having any major complaints. Anyone know why OWL died to the sword of MFC? probably MS's monopoly. :(
No, it died because Borland replaced it with VCL.
-
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.
I second everything here. Wrestling with UI issues is the biggest headache. Depending on linked in resources is a serious constraint. Keep the library up-to-date with the common controls. Make component development easier. Serial/USB/IR/other I/O communication classes. You should be able to get a good clue from all the third party "solutions" for MFC short comings. Bill Sutphin
-
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
The main problem i have always encountered with VC++ Environment is building database applications. A library than can manage every database technologies (ODBC or ADO or proprietary drivers (Oracle, Sybase...)) without having to know deeply the code needed for each technology. It would be very nice if the library could hide all the Recordset syntaxes (verbose) (for ODBC, ADO), Sql Cursors (for Oracle or Sybase) and so on. In fact software like PowerBuilder resolves most of the time the need to easily build Database Applications. Using simple syntax (Generic SQL) you don't have to worry about the kind of database you use. In the same way, what's about integrating into VC++ more and more wizards to help easy built of database applications by generating Generic Code to access any database !!! It would be also very nice to enable any MFC or new library to be run into a browser without having to change a single line of code. I have never understand how a software like 'WINDEV 5.5 (PcSoft enterprise)' can fulfills every need of a developper : - Database Access to any kind of Database, - Application Execution either on Windows or on a Browser of the same application, - Documentation Generation, - RAD Tool, - Database Structure Definition (like AMC Designor), etc... and that even Microsoft didn't try to do the same !!! VC++ is very good to build system application, drivers etc... but when you want to build advanced user man machine interfaces with database management, it's really a plain task. Please in your new library, simplify database access to any connectivity types. Thanks.
-
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, I'm joing this discussion a little bit late, but I hope my voice still counts. So, here are some things that I would like to see in MFC: 1) get rid of the MFC collection classes and use STL instead. In my company, we are using STL for ur internal data structures, a than we have problems exchanging it with MFC classes. 2) replace RUNTIME_CLASS and all its friends with C++ RTTI. This will make it compatible with the rest of the world. As a side note: I tried once to derive template classes from CView, it was quite tricky mainly because of RUNTIME_* macros and DECLARE_DYNAMIC. I finally succeeded, but it's not a nice code. 3) I worked on several large-scale projects, and from my experience Doc-View architecture does not scale up very well. We've developed our own Model-View-Controler classes on top of DV to make it more flexible. I think you can try this approach. 4) Also it would be good to have multiple inheritance for MFC classes (or for Window classes at least). Ideally I would see modular View classes where I can add/remove pieces of functionality just by inheriting from plug-in class. Sort of WTL, but without templates. I've seen such things done. 5) Do not require every class that has to work with MFC to inherit from CObject. For example: hint class passed in UpdateAllViews should not be a CObject-derived. 6) Split MFC code into smaller dlls. Few other wishes, not neccessary targeting MFC: - make #import derective using ATL wrappers (CComPtr, CComBSTR, CComVariat) instead _bstr_t etc. It's really annoing to have two sets of classes doing the same thing in two different ways. Thanks for this opportunity to experss my wishes, Best regards Maciek Sarnowicz mailto:Maciek.Sarnowicz@imaigngresearch.com
-
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 just simply like to see a way of creating everyday controls that we see elsewhere in MS products. For example, progress bars with text in the bar. We (as a development) community shouldn't have to depend on guess work to create these controls. Doc/View? I think the current framework is a little too dependent on it. If you try to move away from that framework by disabling Doc/View, you are off the "beaten path" and are making your program prone to crashing, at least in my experience. The wizards are too generic, and too much is done by them without any explanation. I find myself (I've programming with VC++/MFC for about 6 months now) constantly asking "How Do I..." questions. Understantably so, but the answers are VERY hard to find in the MSDN documentation (another can...worms...:) ) I find that I use DAO more than ODBC. I've only written one app in VC++ with database support, but serveral in other languages (Pro*C, Informix-4GL, etc.). It's seems to be more suited to "embedded" SQL type queries. I find it very difficult to create modern looking apps with the current development suite, and often turn to classes found on this site (or others) to accomplish what I need. What does that say about MFC? I don't know, for sure. I feel that backwards compatibility is a HUGE issue with MFC, but I may be alone on this thought.