Support your local MFC Dealership
-
I've been messing around with VS 11 and one thing really gets to me - there's still naff all improvements to MFC. Sure our dev house uses WPF, Silverlight and all the new jazz, but we also maintain a 1.5 million line MFC/Win32 project. And we still can't layout tab controls properly in the dialog editor! I know MFC is long in the tooth, but those of us who are still using it are probably doing so cause we've got big enterprise solutions with a UI layer based on it. MS have not bothered doing any improvements since about VC++ 6.0 - they added the ribbon control and that's about it. If you need a bit more MFC love, try voting for the uservoice thing below: Improve MFC[^] They'll probably ignore it, but it's gotta be worth a try!!
My Blog: www.dwmkerr.com My Charity: Children's Homes Nepal
-
I've been messing around with VS 11 and one thing really gets to me - there's still naff all improvements to MFC. Sure our dev house uses WPF, Silverlight and all the new jazz, but we also maintain a 1.5 million line MFC/Win32 project. And we still can't layout tab controls properly in the dialog editor! I know MFC is long in the tooth, but those of us who are still using it are probably doing so cause we've got big enterprise solutions with a UI layer based on it. MS have not bothered doing any improvements since about VC++ 6.0 - they added the ribbon control and that's about it. If you need a bit more MFC love, try voting for the uservoice thing below: Improve MFC[^] They'll probably ignore it, but it's gotta be worth a try!!
My Blog: www.dwmkerr.com My Charity: Children's Homes Nepal
I consider MFC architecturally broken
- to many design decisions burden the caller to shave off a few bytes of runtime use. This is soooo last century.
- Wrapper Mania for things that can't be completely abstracted, thus those wrappers require you to understand both the underlying API and the wrapper
- "Too Much OO" artificial enhances limitations of Win32 - e.g. the View/Window schism. And the Window/Dialog schism.
- The different UI enhancements are completely incompatible. Basically, MFC is now about three UI libraries under a common name. Or four? I forget. The worst thing is that the project wizard decisions are almost final. This would be the hardest part to "undo" when you want to fix MFC.
I'd rather see a freshly designed library that's really the one go-to point. (And gets over the "to add features to a control you have to inherit". Because it's sooo easy to combine
CListViewCtrlWithSortHeaderwith aCLVCDragAndDropReorderand aCMultilineLV) WTL might be a better base, so I personally don't like it o much. However I don't expect anything like this to happen, so MFC rescue would be the next best thing - I threw in three votes. (dammit, now they have another address of mine!)FILETIME to time_t
| FoldWithUs! | sighist | WhoIncludes - Analyzing C++ include file hierarchy -
I consider MFC architecturally broken
- to many design decisions burden the caller to shave off a few bytes of runtime use. This is soooo last century.
- Wrapper Mania for things that can't be completely abstracted, thus those wrappers require you to understand both the underlying API and the wrapper
- "Too Much OO" artificial enhances limitations of Win32 - e.g. the View/Window schism. And the Window/Dialog schism.
- The different UI enhancements are completely incompatible. Basically, MFC is now about three UI libraries under a common name. Or four? I forget. The worst thing is that the project wizard decisions are almost final. This would be the hardest part to "undo" when you want to fix MFC.
I'd rather see a freshly designed library that's really the one go-to point. (And gets over the "to add features to a control you have to inherit". Because it's sooo easy to combine
CListViewCtrlWithSortHeaderwith aCLVCDragAndDropReorderand aCMultilineLV) WTL might be a better base, so I personally don't like it o much. However I don't expect anything like this to happen, so MFC rescue would be the next best thing - I threw in three votes. (dammit, now they have another address of mine!)FILETIME to time_t
| FoldWithUs! | sighist | WhoIncludes - Analyzing C++ include file hierarchyI know exactly what you mean. This is one of the reasons that I get frustrated with Windows Forms. With WinForms, you have things like a 'Font' property on a control. Great - but under the hood it's going to create a font, track it, send WM_SETFONT etc etc. It's not even MFC that's broken, it's just that Win32 nowadays is struggling with everything we're throwing at it. You'd be forgiven for thinking that WinForms classes are nice and OO - but most properties are actually sending a stack of WM_s! What a pain. We've been moving stuff to WPF - joy of joys when you then find out that after thousands of pounds in training etc etc they're putting the kibosh on that!! Arghghgh!!!
My Blog: www.dwmkerr.com My Charity: Children's Homes Nepal
-
I consider MFC architecturally broken
- to many design decisions burden the caller to shave off a few bytes of runtime use. This is soooo last century.
- Wrapper Mania for things that can't be completely abstracted, thus those wrappers require you to understand both the underlying API and the wrapper
- "Too Much OO" artificial enhances limitations of Win32 - e.g. the View/Window schism. And the Window/Dialog schism.
- The different UI enhancements are completely incompatible. Basically, MFC is now about three UI libraries under a common name. Or four? I forget. The worst thing is that the project wizard decisions are almost final. This would be the hardest part to "undo" when you want to fix MFC.
I'd rather see a freshly designed library that's really the one go-to point. (And gets over the "to add features to a control you have to inherit". Because it's sooo easy to combine
CListViewCtrlWithSortHeaderwith aCLVCDragAndDropReorderand aCMultilineLV) WTL might be a better base, so I personally don't like it o much. However I don't expect anything like this to happen, so MFC rescue would be the next best thing - I threw in three votes. (dammit, now they have another address of mine!)FILETIME to time_t
| FoldWithUs! | sighist | WhoIncludes - Analyzing C++ include file hierarchyHaving used many UI SDKs, using your criteria, they're all broken, including WPF. The reason is simple; UIs are tricky beasts. No matter how well you design a complex UI class, you'll find a time you need to change it. Obscure features of APIs are often overlooked. One thing I like about MFC over most other UI SDKs I've tried over the years is how easily you can go native and back again. What I like most about MFC is that it's very lean and I work in C/C++ (and minimize template use) because it's lean and when you need lean, but aren't quite willing to go pure native, it's a godsend. I can work on code that will run headless, throw in a quick MFC dialog for testing purposes and know the code will still run as intended. Last year I ported some MFC apps over to CE. The port was a breeze. Can't say the same for the .NET code I ported at the same time (.NET CF's stupid pseudo handles are beyond absurd.) The recent changes to MFC were extremely poorly designed and implemented; Microsoft should have teamed up with CodeJock instead of buying BCG, which has a far superior library that doesn't entangle itself (or didn't last time I checked) so deeply into MFC. (It didn't help that last decade Microsoft was infatuated with .NET and make C++ very much a second class citizen, which stalled all C++ development for years.)
-
I've been messing around with VS 11 and one thing really gets to me - there's still naff all improvements to MFC. Sure our dev house uses WPF, Silverlight and all the new jazz, but we also maintain a 1.5 million line MFC/Win32 project. And we still can't layout tab controls properly in the dialog editor! I know MFC is long in the tooth, but those of us who are still using it are probably doing so cause we've got big enterprise solutions with a UI layer based on it. MS have not bothered doing any improvements since about VC++ 6.0 - they added the ribbon control and that's about it. If you need a bit more MFC love, try voting for the uservoice thing below: Improve MFC[^] They'll probably ignore it, but it's gotta be worth a try!!
My Blog: www.dwmkerr.com My Charity: Children's Homes Nepal
I think its way too late now for this. As I understand it VS11 drops support for MFC on XP anyhow: VS User Voice: Allow MFC 11 to run in XP SP3[^] So even if they did finally improve the MFC dialog editor and classwizard it would be no use to me - the legacy apps I'm supporting would still need to be developed in an older version of VS just so I could deploy them to the legacy OS still being widely used! Years ago I would have killed for such improvements to VS - but given they ignored all the requests back then I'd say you've no chance now! They killed the classwizard and dialog editor making the tooling and technolgy almost unusable. What worries me more is all the rhetoric I heard back then (about MFC/CRT not being dead) is exactly what I'm hearing now about WPF (apparently not dead!). Its the same old story all over again, the only difference this time is I don't see any viable newcomer that can actually replace it! Metro on desktops certainly isn't it for me!
-- The Obliterator
-
Having used many UI SDKs, using your criteria, they're all broken, including WPF. The reason is simple; UIs are tricky beasts. No matter how well you design a complex UI class, you'll find a time you need to change it. Obscure features of APIs are often overlooked. One thing I like about MFC over most other UI SDKs I've tried over the years is how easily you can go native and back again. What I like most about MFC is that it's very lean and I work in C/C++ (and minimize template use) because it's lean and when you need lean, but aren't quite willing to go pure native, it's a godsend. I can work on code that will run headless, throw in a quick MFC dialog for testing purposes and know the code will still run as intended. Last year I ported some MFC apps over to CE. The port was a breeze. Can't say the same for the .NET code I ported at the same time (.NET CF's stupid pseudo handles are beyond absurd.) The recent changes to MFC were extremely poorly designed and implemented; Microsoft should have teamed up with CodeJock instead of buying BCG, which has a far superior library that doesn't entangle itself (or didn't last time I checked) so deeply into MFC. (It didn't help that last decade Microsoft was infatuated with .NET and make C++ very much a second class citizen, which stalled all C++ development for years.)
I've been called on for being demanding before :D Good UI is hard, and no framework is perfect. I certainly haven't found any that I'd proudly recommend. However, this doesn't change that a lot of MFC's design decisions are still stuck in the past, and that makes it harder. That's not the problem. I don't see a way how to "modernize" MFC (in terms of tools like resource editor and wizard, resource handling, and general we-could-do-this-for-you-ness.) -- at least not without losing a large part of backwards compatibility. Which would also suck. While I still use MFC for application framework (i.e. pulling up a main window and a dialog), everything else I write happily with a collection of rather simple routines and a subclassing library I'm fairly proud of*. For chewing through the tricky details of a form, MFC gives me claustrophobia (and ATL/WTL feels unwieldy, somehow).
Joe Woodbury wrote:
The recent changes to MFC were extremely poorly designed and implemented
Ack! I didn't have any experience with BCG, and when I first toyed around with it for the first time, I felt like poking my eyes out. It fits the theme of window-dressed neglect, as you describe. To clarify: I'd still love to see a "better MFC" over a completely new framework. There's just so much baggage in MFC that I don't see that happening from a technical stance. (E.g. throwing out the BGC detour would probably alienate to many users.) *) FWIW, the basic ideas are: augment Windows API, don't replace it. A "Message Handler" can handle multiple messages from multiple windows, and each window can have multiple of those message handlers. Oh, and it lives as long as either one of the windows exists, or you have a reference to it.
FILETIME to time_t
| FoldWithUs! | sighist | WhoIncludes - Analyzing C++ include file hierarchy