locked
Request for MFC suggestions RRS feed

  • Question

  • Hi all,

    We in the Visual C++ team are currently working on planning for the next version of MFC, and we are looking for suggestions for improvements.
    So I thought I would ask you: what would you love to see added to MFC, or what is missing that you feel should be supported?

    Thanks for any suggestions or feedback you have!
    Pat Brenner, Visual C++ Libraries Development

    Saturday, July 24, 2010 12:12 AM

All replies

  • Something I'd like to see in MFC:

    - More friendly to STL, like supporting or using std::string, or std::vector, etc.

    - Use std::fuction and std::bind for event handler (or the signal/slot idiom, or the reflection in C#).

     

    Saturday, July 24, 2010 4:36 AM
  • I'm happy to see the Visual C++ team is asking! MS has been doing a great job in modernization of MFC with the additions of the 2008 feature pack and the new additions in 2010. We write about 15 MFC apps/year mostly as a management interface to our hardware devices making use of single doc interfaces with the occasional multi-doc interface.

    We would like to see:

    • More flexible splitter window not base so much on views, but CWnd based classes
    • Some modern GUI (GDI+) utility functions - maybe somehow have attributes for items (anti-aliasing for lines and alpha blend control)
    • Fix your wizard bugs. The bugs keep following versions of VS. For example- try to create a single doc interface with out Doc/View. You will notice that the toolbar icons don't match the menu IDs. IE - no new button, but new is defined in the resource file. The bitmap is missing the new.
    • Not library related but better documentation (minimal) on new feature added to MFC - Feature Pack comes to mind.
    • Enhance the CMFCVisualManager API for to get the color scheme, gradient fills and other items that will help us create an application that looks like it belongs with the newer libraries. Example CMFCVisualManager::GetColor(nIndex) where nIndex use is like the GetSysColor function.
    • Enhance the CDialogEx - make it so it could take advantage of the CMFCVisualManager. Maybe a CMFCDialog - ??
    • Not sure if this could be wrapped up in MFC, but gesture controls. I'm sure this is more of a OS messaging item, but a way we could make use of gestures.
    • Multi touch - again may be system message/event based, but MFC help for this too.
    • What would be very nice, create a window transition manager for MFC where you have control on how to transition from one view to another. A drag of a top layer window would reveal the bottom window. A flick. Other transitions could include fade from one window to another or animated drops. Of course, a page turn would be cool. I hear that MS owns the patent for this.
    • The windows transition manager leads to something else, how about a animation manager. Have the ability to animate objects.
    • CBingMapWnd - Yes - that would be a cool window class. Having access to Bing Maps through a window class rather than through HTML would be very cool.

    Thanks for asking. I'll most likely edit this many times as I think of ideas.

    Monte---

     

    • Edited by RumJungle Wednesday, August 11, 2010 4:27 AM Added CBingMapWnd -- Hope you are still checking!
    Saturday, July 24, 2010 5:16 AM
  • Not MFC specific, but I'd like to be able to handle XML document
    serialization in a pure native C++ application in a way that's almost
    as easy as the .Net XML serialization.

    Dave

    Saturday, July 24, 2010 9:07 AM
  • I think the best thing that could modernize MFC is adding a Visual Window Designer (like Windows Forms one) that will work synced with the generated code (that is, if customer modifies generated code, UI in designer will be updated, and vice-versa).

    I'm not talking about a Dialog Editor because it is done, I'm talking a way to build "main windows". Take a toolbar, a statusbar, a main window, a treeview, a richedit, a listview and put them together and allow change their properties. Move them, add splitters, toolbar buttons, etc, and then allow to save the custom state.

    For me, the most difficult thing for novices (and not-so-novice) people is to build a decent MFC UI in a reasonable amount of time. Feature Pack is in the right direction, but most of time the resultant from the Assistant is not the user wants, and we need more power and more easyness to be able to compete with, for example, QT.

    Well, my real idea is to throw away MFC and start with a new, possible source code compatible with MFC, more OO and modern designed UI library for C++ like QT. But based in STL, boost and so. It is. I've wrote it. Sorry. :-)


    MVP Visual C++ - Visita mi blog sobre desarrollo: http://geeks.ms/blogs/rfog/
    • Edited by RFOG Saturday, July 24, 2010 10:45 AM correct text
    Saturday, July 24, 2010 10:43 AM
  • "Pat Brenner MSFT" wrote in message news:6411284a-1782-4beb-b98e-450f6db76548@communitybridge.codeplex.com...

    We in the Visual C++ team are currently working on planning for the next version of MFC, and we are looking for suggestions for improvements.
    So I thought I would ask you: what would you love to see added to MFC, or what is missing that you feel should be supported?

    Thanks for any suggestions or feedback you have!
    Pat Brenner, Visual C++ Libraries Development

    I've been using MFC since about 1995 but have been having trouble with the learning curve for the new feature pack classes: specifically with a tabbed MDI app using CMFCToolbar and CMFCMenuBar.   (I appreciate your comments on my "On menu bitmaps.." post of 4 July - I posted it because it took me such a long time to figure out.)

    So here are some things I would like:

    1. Much more thorough documentation of the feature pack classes - with explanations of how to do things and not just one line definitions of what member functions do.   Also complete documentation of the members of classes!   (I opted to load the help system on my computer, as I don't always have a broadband connection when working on the move.)

    So what I mean by complete documentation of members is for example:

    Look up CMFCPopupMenu
    There's not much indication of whether it does what I want.
    One constructor is listed: it takes a CMFCToolBarsMenuPropertyPage, pointer which is listed as an 'internal class'.  It is not mentioned that that constructor is protected, and the other one (with no arguments) which is public, is not on the list of members.  [The MSDN website documentation is the same.]

    2. More comprehensive customisation options.

    2a  I figured out how to put a bitmap on a menu when there's no toolbar button for the same command.  As I say, it took a while, but so far so good.

    2b  Toolbars whose default state hides some of the buttons.   My example is musical dynamics: ffff, ff, f, mf, mp, p, pp, ppp, pppp. ffff,fff,ppp,pppp are rarely used so I thought I'd hide them by default, but leave them there so those who need them can get them from the toolbar's add/remove buttons list.   It would be nice if this was straightforward!

    [I've sort of managed it.   The toolbar is created with all buttons.   Then immediately after loading it I call RemoveButton() for the unwanted buttons. At this stage (at least) it only hides the button.  In a class derived from CMFCToolBar, I implement the OnReset() member so that, once the tool bar is established at least, it posts itself a user message in response to which, it uses CMFCButton::SetVisible() to hide each button which is wanted hidden by default, and then calls AdjustSizeImmediate();   The message posting was an attempt to avoid a crash when I go up and down the buttons menu for the toolbar showing some and hiding some, and then, without leaving the menu, press Reset toolbar.   That only crashes occasionally now, but even so some more experimentation will be needed - this is very hard work!]

    2c Commands which are not on menus.

    If I look at the customisation dialogue, the commands page only list commands which have a menu item.   So I can't (as far as I can see) put a command which only exists on a toolbar, on another toolbar (or on a menu!). Now it looks like I can derive from the CMFCToolBarsCustomizeDialog property sheet and maybe improve the situation myself.  If so, some instructions would have been useful.

    The CMFCToolBarsCommandsListBox class looks very nice (and crucial to this task), but again the documentation doesn't help much, so I don't know if I can use it.  (I have various places where I want to list commands which are available.)   The documentation of CMFCToolBarsCommandsListBox::DrawItem says "This class supports the MFC framework infrastructure and is not intended to be used directly from your code.", but that isn't mentioned on the main page for  CMFCToolBarsCommandsListBox.  :-(     So who knows if I can bend it to my will?   I do know it will take time delving into the source code to find out!

    3.  Something completely different:  it would be very nice if there was a "Save As PDF" command so applications could save PDF files (with embedded fonts) without the need for having a pseudo-printer PDF writer installed. (I guess Microsoft's XPS serves the same purpose and the "printer" option for that comes with Windows these days, but I still get asked for PDF a lot!)

    In conclusion here: not so many requests for completely new stuff, but a big ask for a lot of tidying up of the CMFC Classes and expanding their documentation.   Its absolutely great that MFC is under active development for modern applications, and I love the appearance of new applications created with the App wizard, but getting into the Feature Pack Classes is a very steep learning curve and I'm aware that in two months I have barely scratched the surface!

    Dave


    David Webber
    Mozart Music Software
    http://www.mozart.co.uk
    For discussion and support see
    http://www.mozart.co.uk/mozartists/mailinglist.htm


    David Webber Author of Mozart music notation software http://www.mozart.co.uk
    Saturday, July 24, 2010 2:39 PM
  • Hi all,
     
    We in the Visual C++ team are currently working on planning for the next version of MFC, and we are looking for suggestions for improvements.
    So I thought I would ask you: what would you love to see added to MFC, or what is missing that you feel should be supported?
     
    Thanks for any suggestions or feedback you have!
    Pat Brenner, Visual C++ Libraries Development
    1. Refector the MFC code so that static-linked MFC projects that do not need new features are as small as as they were in VS2008. See
     
    http://tedwvc.wordpress.com/2010/05/27/how-to-make-small-statically-linked-mfc-exes-in-visual-c-2010/
     
    Even better make them as small as small as they were in VC6. My VC6-generated SDI application with around 100,000 lines of code is under 600KB in size.
     
    2. Modify CDocManager::DoPromptFileName() to allow replacement or modification of the CFileDialog object, as described long ago by Paul DiLascia:
     
    http://msdn.microsoft.com/en-us/magazine/cc301412.aspx
     

    David Wilkinson | Visual C++ MVP
    Sunday, July 25, 2010 11:08 AM
  • I would like to have:

    1. Better control through the wizards and properties to set more dialog/control attributes like font.

    2. XMLWriter/Reader classes.

    3. Separate new MFC code so I don't have to staticly link an extra 1.5MB if not used.

    4. Use FindResourceEx rather than FindResouce so that language can be changed in the same EXE without regard to the OS language.

    5. Better drag and drop integration for controls like list control.

    6. Better support for advance list control options like grouping that works.

    Tom

    Monday, July 26, 2010 5:34 PM
  •  
    As others have pointed out, better documentation. But not only in the
    Feature Pack classes, also update the 'old' ones.
    More specifically, I'd like to see better and more complete examples.
    Most of them are too trivial. And examples that use and encourage a
    modern and correct coding style, like using controls as member
    variables, not through GetDlgItem.
     
    It would also be nice to set the defaults of wizards, etc. to more
    "logical" values, like making the members of classes protected by
    default, and not including the app's header file in every cpp file.
     I use VS2005 mostly, so maybe some of these suggestions have already
    been addressed in VS2008 or 2010.
     
    Tuesday, July 27, 2010 10:28 AM
  • I thought of something else yesterday.  Not sure how this would be implemented, but it would be nice if there was a way to automatically set up the variables for controls all at once with CW rather than having to do each one a at a time.  For example, I always create a Control variable like m_cMyControl and CString variable like m_csMyControl for edit controls.  This could be ambiguous because, of course, a text control could be a string or a number, but there is a property that says whether or not it's a number and that could be used... Or... the user could just click some text boxes on the screen and have both variables for a control set up at once.

    It would be nice if there were a way to just set this up automatically without needing to even resort to CW at all, but I'm not sure how that could work.

    Tom

    Tuesday, July 27, 2010 3:57 PM
  • I agree with others, in that  a XML reader/writer classes would be a help.

    Also, add some consistency.  For instance, CWinApp::GetProfileString() returns a CString while you pass CComboBox::GetLBText() a reference to a CString.

     

    Steve

    Tuesday, July 27, 2010 4:53 PM
  • Aside from all of the great technical suggestions so far, I would like to see MFC updated to directly support modern application appearance.  Bitmaps, skins, direct support for png images, etc.

    Make it possible, and straight-forward, to create applications with MFC that *look* the way we want them to.

     

     

     

    Tuesday, July 27, 2010 6:58 PM
  • We'd like to see full support for PNG files, both in the UI and in the resource files.
    Tuesday, July 27, 2010 9:10 PM
  • seamless support/integration/wrappers/wizards for

    - Direct2D/DirectWrite.  (7/Vista)

    - Windows animation framework (working on 7/Vista/XP)

    - Windows Automation API 3.0 (working on 7/Vista/XP)

    decouple feature pack stuff from everything else (flip of switch instead of hacks)

    modern Help intregration (handcuffed by Microsoft releasing something better than HTML Help 1.1) - this hasn't been touched in 12 years.

     

    Tuesday, July 27, 2010 11:43 PM
  • I would suggest to fix the bug with class wizard - it does not work with classes in namespaces.

    http://social.msdn.microsoft.com/forums/en-us/vcmfcatl/thread/08068487-CC49-4312-890B-8880281ADD7B

    Thanks

    Vaclav

     

    Wednesday, July 28, 2010 9:01 AM
  • The print preview dialog window should open as a top level window. Only print related toolbar should be visible.

    The last version this worked correctly was VS 6.

     

    Vaclav

    Wednesday, July 28, 2010 10:32 AM
  • I really love that MFC is getting some attention once again...   I used both MFC and .NET at my last job and recently took a new one that looks like it might be exclusive MFC development...  this technology is not going away anytime soon and a lot of us need your help!

     

    1.  Some sort of code refactoring (even if its not perfect and comes with disclaimers) would save lots of time.

    2.  MFC classes for xml

    3.  An easy way to target and work with older versions of MFC  from the most recent Studio release...   i.e. If I want to make a quick small app utility that I know will run on every windows computer every made it could use the same DLLs as 6.0.   In .NET is is very easy to target 1.0, 1.1, 2.0, 3.0, 3.5, etc...

     

     

    Wednesday, July 28, 2010 3:25 PM
  • David L. recently explained how to do this in VS2010:  open the Project Properties dialog, select General from the list on the left, and set Platform Toolset as desired.  For this to work, you need to have installed VS2005 and/or VS2008.  I don't believe VS6 is supported.
     
    -- David
     

    3.  An easy way to target and work with older versions of MFC  from the most recent Studio release...   i.e. If I want to make a quick small app utility that I know will run on every windows computer every made it could use the same DLLs as 6.0.   In .NET is is very easy to target 1.0, 1.1, 2.0, 3.0, 3.5, etc...

     

     


    Efficiently access this forum with newsreaders like WLM, Thunderbird, and Forte Agent: http://communitybridge.codeplex.com
    Friday, July 30, 2010 2:07 AM
  • Hi all,

    Thanks to all of you for all the great suggestions and ideas so far!  Keep them coming!  I am listening.  I can't guarantee that we can do all of these things, but I am pretty sure that we will at least do some of them and will consider all of your suggestions.

    Pat Brenner, Visual C++ Libraries Development

    Friday, July 30, 2010 5:13 PM
  • A minor one, to encourage folks to do the right thing (rather than
    have duplicate information)...

    Have the auto generated About dialog get its displayed information
    from the version resource. A helper class to get the version resource
    information would be useful in non-gui applications too.

    Dave

    Friday, July 30, 2010 9:55 PM
  • Thanks for the info! VS2005 and VS2008 is a good start.   I have a new laptop on order, and have been putting off loading VS2010...    I guess when it gets here I will have to load every copy of Visual Studio in sequence starting with 6.0...     at least at this job I no longer need VC 1.52 and 16 bit support!
    Monday, August 2, 2010 10:33 PM