I suggest you ...

Improve MFC

Like many developers we maintain and develop an extremely large enterprise MFC application. All in all about 1.5 million lines. Asides from the addition of ribbons and a few extra controls we have had very little improvements in how we can work with MFC or native Win32 apps (in fact, the speed has gone down and classwizard seems to have gone from bad to worse to gone). Can you consider:

1. Improving the Dialog editor so that we can lay out dialogs with guides and the extra alignment options that are standard with C# - automatically spacing items correctly and so on.
2. Introduce a standardised feature for resizable dialogs, somewhat akin to C#'s docking or attaching.
3. Please, please, please allow us to work on the tabs of a tab control directly. Tab controls are a real pain to work with.
4. Change the class wizard so that a dialog header file doesn't contain its resource ID in the header. Having '#include "resource.h"' in the header of every class is a pain and causes numerous conflicts in applications that have many dialogs.

Essentially I'm asking to have the MFC functionality brought up to line with what we have in Windows Forms. Developers who are still using MFC are almost certainly like us in that they are using it because they have a large enterprise solution to maintain. Such developers are professionals using Visual Studio to build big, serious, expensive applications. Whilst improvements in C#, WinForms, WPF, SL and so on are great, MFC has been woefully neglected for years.

2,452 votes
Sign in
Sign in with: facebook google
Signed in as (Sign out)
You have left! (?) (thinking…)
Dave Kerr shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →


Sign in
Sign in with: facebook google
Signed in as (Sign out)
  • Iwona Kirby-Green commented  ·   ·  Flag as inappropriate

    If anyone wants range for support for MFC collections just email me. I have a single header file that adds this.

    tomkirbygreen at gmail dot com

  • Andrey commented  ·   ·  Flag as inappropriate

    Please add "range based for" support for CArray:
    CArray<T> array;
    for (auto& val : array) {}

  • Chris commented  ·   ·  Flag as inappropriate

    That is a nice idea. +1

    Most of us are working with big legacy applications written in MFC. Rewriting the whole thing with Qt or C# is too expensive. That is why we need improvements with new MFC versions.

  • Massood Khaari commented  ·   ·  Flag as inappropriate

    MFC is real pain in comparison with popular GUI frameworks like Qt. I wonder why Microsoft won't make real updates to it. Despite regular version releases, it follows the basic architecture and fundamentals it was based on many years ago.

    It should (must) be reinvented and re-designed into a real OO architecture and well-structured programming model, not just being a flat wrapper for Windows APIs.

  • Johan commented  ·   ·  Flag as inappropriate

    I too think that we need a modern C++ wrapper of the native Windows APIs. However, in its current state I hesitate building a new application user interface using MFC, even though I consider myself an expert at it. Well, what should be the first choice of design tool from Microsoft when building native applications in the style of Windows forms/dialogs?

    With all the new features of C++11, it feels a bit dull to keep writing the old BOOL and NULL macros instead of bool and nullptr. I think it's time to deprecate CList, CArray (it doesn't even support non-POD types because of memcpy), etc and add support for the standard library containers that we can use with lamdas, etc.

    It may be possible to solve polymorphically, but ideally I wish for a new full-blown MVC "MFC 2.0". To upgrade existing MFC projects we then need provided tools to convert all dialogs in our rc files into new XML style resources, etc. I would very much like to see something similiar to the Qt resource system where you can reach into the resources to get any embedded binary file as easy as ":/resources/image.png".

    I would also like to see better tools to help us create the UI in different languages (again, Qt has a better solution in my opinion). In MFC you now need to create 20 versions of each string table and of each and every dialog! On top of that, the layout of dialogs must be adjusted according to the asian languages where the controls have other dimensions (and to verify the results you need to buy and install different versions of Windows). If you forget to add an ID in some version of the dialog, the application will crash when running it in that particular language. It becomes a nightmare to maintain.

  • Anonymous commented  ·   ·  Flag as inappropriate

    Oh, please, yes!!!
    Re-invent the resource editor for MFC, it is long overdue

2 Next →

Feedback and Knowledge Base