Hi I’m Pat Brenner, a developer on the Visual C++ libraries team. I’m pleased to give you a sneak peek at a major MFC update we’ve been working on. Since we’re adding a number of cool new user interface components to MFC, this blog post is going to be graphics heavy. I’d much rather show you some of these components than just describe them! I hope you enjoy this quick tour through the new portions of the library.
Modern user interface elements
This update to the MFC library will enable developers to build modern user interfaces with support for the Office 2007 Ribbon Bar, Office-style menus, Visual Studio-style docking toolbars, tabbed documents and much more. All of the components included in the update will run on Windows 2000 and above.
Let’s take a look at some of the Office 2007 Ribbon Bar support. Below is an image of an MFC application built with the Office look and feel:
The ribbon support includes support for the application button (the large round button at the top left), the quick access toolbar (the small set of tools just to the right of the application button) and the standard ribbon components. Each tab on the ribbon (e.g., the “Home” tab above) allows access to a category of tools. Each category is divided up into a set of panels (e.g., “Clipboard” and “Font” above) and each panel contains a set of ribbon elements. These ribbon elements can have a wide variety of styles—I’ll go into more detail about these later.
Perhaps many of you would like to build applications that utilize some of the functionality we’ve had in Visual Studio. For example, one of the most requested features is support for the smart docking we added in Visual Studio 2005. With this new release, all the cool user interface features you’ve seen in the past versions of Visual Studio are at your disposal.
Let’s take a look at some of the Visual Studio support. Below is an image of an MFC application built with the Visual Studio look and feel:
MFC now implements its own menu bar and toolbar, which is fully customizable like the Visual Studio toolbar and menu bar. This means that buttons can be moved between toolbars, and even from the toolbar to the menu bar and vice versa. Custom toolbars can be created, and commands can be added to them. And the images for the individual toolbar buttons can even be changed, and custom images can be created and used. Support for docking panes is also included—these panes can be grouped into one docking frame as above, they can be floating as well as docked, and they support auto-hide mode like in Visual Studio, so a docked pane will slide out from the edge of the frame when its tab is hovered over, mimicking the Visual Studio behavior. There is also support for tabbed MDI documents (which can be grouped) like in Visual Studio.
In addition to all the features supporting Office, Internet Explorer and Visual Studio “look and feel” there are a number of built-in cool elements you can use in the ribbon in your application. In the images below, we provide a quick visual introduction to what’s included in the library. The images come from the RibbonGadgets example that ships with the library.
In the image below you can see large and small buttons, as well as check boxes. The buttons can be simple (so they just respond to a click), or they can drop down a menu or be a split button which responds to the click or drops a menu depending on the click location.
In the image below you can see what we call palette buttons. These can be a set of buttons that have associated images, so the user can see what he will get when he clicks on a button in the palette. These palettes can be embedded in the ribbon, or they can be dropped down from a button in a window which can be resized dynamically by the user.
In the image below you can see a variety of color choosers. These can be embedded in the ribbon, or they can be attached to a button. The table of colors associated with the chooser can be customized in your application. There is a color picker dialog which offers even more flexibility, including the ability to choose the color of any pixel on the screen and use that color.
In the image below you can see groups of commands. A ribbon group can be built from an existing toolbar, so if your application has a large number of toolbars, you can place them on the ribbon with ease.
In the image below you can see support for edit boxes, combo boxes and spin controls, as well as the font picker control, which can display the font names in the font (as in Word) so you get an instant preview of the font appearance.
Below you can see a few more ribbon elements. Several of these, including the progress indicators and the links and sliders, actually make more sense on the ribbon status bar, which you can see in the first image at the top of this article.
Powerful application wizard
We’ve also beefed up the MFC Application Wizard (see the images below) quite a bit to enable easy use of these new features in MFC. We’ve added a couple of options to the “Project Style” category which will allow you to build a project that looks something like Visual Studio or an Office application by default. We’ve added the option to use tabbed MDI document windows rather than the old MDI style. And we’ve added the ability to choose the look and feel of your application with the “Visual Style and Colors” combo box.
An option that is hidden in this image is a checkbox that allows your application look and color to be changed at runtime. You can choose your application look and color at design time, but if the user wants to change it, he can do so easily. This is possible because the drawing of all the user interface elements is done via what is called a “visual manager”. The visual manager takes care of all the drawing of elements, so if a different look is desired, all that is required is to switch to a different visual manager, and redraw the window, and your application instantly has a completely new look. As you can see in the image below, a number of schemes are supported, including Office 2003, Visual Studio 2005, and several different Office 2007 schemes which use different colors. All of these are implemented using visual managers.
An option that is disabled in the image below (because ribbon was chosen instead of menu bar) is a checkbox that enabled “personalized menu behavior”. This means that the menus will not show all commands by default, just like in Office applications. When a menu is hovered over briefly, the menu will expand to contain its full set of commands. And as the application is used, the most-used commands are added to the menu by default, so over time, the menu will become personalized to how it is being used.
Below is a screenshot of a running application which uses a ribbon. This is actually the application created by the Application Wizard when the “Office” project style is chosen. There is an Outlook-style navigation bar docked on the left side of the frame, and a caption (or message) bar at the top of the client area. Note that the application button, quick access toolbar buttons, and the ribbon elements have keyboard hotkeys which are available when the Alt key is pressed. On the right hand side of the ribbon is a drop-down element named “Style”, and from it you can choose which color you’d like the application to be presented in.
Easy to update existing MFC code
One of the great things about the new components is that they’re easy to incorporate into existing applications. All of the new behavior is encapsulated in new classes, and none of the existing classes have been modified. If you want to update your existing MFC application to use the new menu bar and toolbar support, all that is required to update your application to the new look is to change the base classes of your application and frame windows, and add a few lines of code, and you’ve just updated your application to have a more modern interface.
Below is an image of the new DrawClient sample. This is a remodel of the DrawCli sample that ships with MFC—it’s been updated to include Ribbon support. Most of the modifications to the source code were in mainfrm.h and mainfrm.cpp. The ribbon is currently built entirely in code. The ribbon is created and then the various ribbon elements (application button, quick access toolbar, categories, etc.) are added via calls to ribbon member functions. However, the underlying command architecture did not have to change—all the ribbon controls can be associated with a command identifier, and when the command is fired, it is handled via the existing command handlers. The object drawing code did not have to change in any substantial way—it was only augmented to allow a few new capabilities. One of these capabilities is something I’ll call “command preview”. This means that, just like in the new Office applications, you can see the effect of a command before actually choosing it. For example, the purple rounded rectangle is active below. As you float the mouse over the large color buttons in the ribbon, the rectangle will temporarily change color to match the color of the button the mouse is hovered over. When you click on the button, the color of the rectangle will then be changed.
We’re pretty excited about all these new additions to MFC, and we hope you are too! Feel free to ask any questions you have about the new features and I’ll do my best to answer.
Visual C++ Libraries Development
> "But it has been approved by the Office team with respect to their ribbon guidelines."
Does this remove the need to license the 2007 Microsoft Office User Interface when using the MFC implementation?
"We have integrated everything into MFCxx.DLL, to simplify deployment. But the DLL did not grow to 20MB. It grew from 1.2MB to 3.8MB."
I assume not including the visual styles?
Let me quote from this post made only a few days ago here on this blog (http://blogs.msdn.com/vcblog/archive/2007/10/28/more-on-the-korean-trip.aspx):
"Of course, we have received a number of excellent feature requests to be considered for our next versions of Visual C++: Componentized and light-weight MFC libraries"
So basically you're ignoring your customer requests and justify it by saying this simplifies deployment? That's absurd.
I and many others don't want this features and there is no justification why you increase the download size of our apps.
@JSchroedl: Already implemented in MFC 9.0. Please check CFrameWnd::SetMenuBarVisibility()
To clarify the office UI licensing questions, customer will still be required to click through the office agreement.
Visual C++ Team
Andre & somebody,
Thanks for the feedback!
With regard to the post regarding simplifying the deployment story, let me assure you that we are not igonring the customer feedback. We are currently considering how to ease the deployment of our libraries in general. Unfortunately, that won't be something in the VS2008 time frame since as you probably know, VS2008 will soon be out. We are looking into that for the next release.
Once more, we appreciate your feedback.
Andre, I checked the posts and spam filter and it looks like some of your posts were regarded as "possible spam"...don't know why though. I marked them as not spam and they should be visible now. Let me know if you can't see any of the posts you previously posted.
To Andre & WhatDoesItMatter:
We aren't filtering any posts. There were 3 posts caught by the blog software as "possible spam". Once we checked for unposted comments this morning, we published them.
Visual C++ Development Team
Huh? Why does the MFC need his own implementation of toolbars if Visual Studio already has one or better put: why doesn't VS use the one from MFC? "Doesn't eat Microsoft it's own dogfood?"
I don't believe any major MS software uses MFC. Office uses its own private GUI library in native C++. Visual Studio uses something derived from that. Its not an MFC issue, its a Win32 issue. MFC is a thin wrapper (or at least it was) on the Win32 controls. Its the Win32 controls that dont provide a rich, modern UI. Blame the common control team for that :).
@Bill & Ayman: Thanks for clearing that up. I know the comments were harsh but hopefully still respectful.
The reason why I absolutely dislike the integration of the BCGControlBar is because I've used the toolkit 2 years ago in my own app and I had to strip it out and replace it with Codejocks toolkit. The performance and quality went steep downhill. If you need to log and monitor engine parameters in realtime (where realtime means 100 samples per second) it's not affordable that the highlighting of some buttons takes up 100% cpu time. Also the look&feel (= user experience) was and is still not good. Just a few weeks ago I've removed the last #ifdef BCG.
And I really really doubt that this will change till the release of the new MFC. And even if you improve the toolkit, there is still no justification to switch back to BCGs implementation. What do your customers gain that they couldn't have before? You don't even have the controls ready for RTM.
I also prefer they current deployment model where the toolkit ships on top of the MFC. While I consider the MFC to be stable, updates are only required once a while when the Windows division shipped a new version, I want toolkit updates and bug fixes ASAP.
So there are many reasons why the BCGControlBar should not be integrated into the MFC:
a) You can ship MFC90.DLL with VS2008 RTM and can keep the version the same for the new controls
b) You can update the controls without the core MFC
c) Customer who do not wish to use the new controls don't need to deploy a MFC DLL triple the size as before
So please reconsider your decisions.
Bill, Ayman, Andre: I totally agree with Andre on this. BCG performance and look & feel is bad (there is one toolkit out there that is even worse then BCG actually -- that one makes BCG look spectacular). I'm not trying to sell you on Codejock at all. If I was trying to sell you on a GUI lib, I'd sell you on mine :). Although at this point, my ribbon impl is not yet complete which is why I don't sell it.
All we are trying to say is that use whatever you want for "giving out for free purposes" because obviously we aren't going to convince you otherwise at this point in time (or probably ever). Although I think you'll find on here and on Usenet is the reaction to BCG in general is mostly negative. The point is at least make it modular to the point that we can drop in whatever library we want or none at all.
Think about it... say I want to give my boss (or client) a quick & dirty app to fix something or do something quick. The VS2005/2008 MFC is not yet common place, so we need to ship that. My boss and/or customer might be curious as to why I'm shipping a 4MB DLL all of a sudden.
For those that want to use the included BCG lib, fine for them. For those of us who want to use something more professional, fine for us :).
P.S. You already compile the debug version of MFC into multiple DLLs, so obviously this is a feasible request :).
Does that growth include integrating ATLx.DLL and integrating MFC<humanlanguage>x.DLL into MFCxx.DLL, to simplify deployment?
If the answer is no then I second (or fifth or whatever) those who say the BCG library should be a separate DLL.
Just do something like:
or whatever in the StdAfx.h file. Then in the afx.h file, only include the BCG headers, libs and DLLs if that symbol is defined. Have the wizards put that define in automatically for new projects if they select the BCG mode from the wizard. If you want to get real fancy, give the option to "BCG-isize" projects during migration.
Simple as that. Everyone will be a happy camper. Those who want a free solution will be happy. Those who want a light weight plain MFC DLL will be happy, and those of us who want to use a different lib will be happy.
Just a few comments:
Re: filtering - even my comments often get flagged as spam and don't show up for a day or two until one of the blog admins notice it. Sorry about that, I'm not sure exactly what it is that triggers that - maybe if some word is close to a swear word or something?
JSchroedl, re: "can you tell us if we'll gain the ability to hide a window's menu bar and have it appear when the user presses Alt?"
Actually, this is one of the features that will be shipped in Orcas as part of the default/old school MFC menu bars and will be available at RTM without any updates necessary. Not sure if it will work with the new stuff since it's designed to mimic Office and VS which don't do that as far as I'm aware.
Re: the merits of wrapping existing implementations vs coming up with new ones.
The problem with trying to rip pieces out of Office or VS is that you want only to get the stuff you want and not any of the other stuff. Any big app is it's own framework with its own legacy of crazy interdependencies. Even if you did manage to pull out what you wanted, it's interface would probably need a lot of reworking to get it to work in a new framework or not to rely on assumptions about how Office or VS behaves. Not that it's impossible, just that it's not always going to be the best decision. Also, you don't necessarily want the overhead of VS to end up in your MFC app since the complexity of the VS GUI might be way more than you're interested in. It's better in my opinion to provide a more customizable solution where you can turn features on or off and tweak them. Providing an application framework and library is a slightly different problem that producing a one-off application.
To address concerns over file size:
I realize that some people don't like the additional size. I think it's a small burden to bear myself in most situations (I'm sure there are some of you where this isn't the case). Luckily, your situation will be somewhat mitigated since you can still deploy the Orcas RTM bits which won't include this update. Once the update is out, the subsequent service releases will contain it, but I that growth is something whose benefits far outweigh the costs. MFC could turn into a perpetual maintenance-mode library, but personally that wouldn't make me any happier. If that happened (and let's be honest - to a large extent that's what happened the last couple years on the visuals front), you would see a continuously dwindling investment and a higher and higher bar to fix bugs. Instead what this does is really revitalize MFC as a platform, contributes to making it an interesting product to work on and makes it a viable platform for continued development.
Anyway, I can say that personally I'm excited about the enhancements coming down the pipe. It's great to finally see a wizard generated MFC App that doesn't look like a time capsule from 1998. I think it's great that we're able to drop this so soon after VS2008 and am even more excited about the possibilities this opens up for the next version of VS.
Visual C++ Libraries Team