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
Tomas: I was getting ready to abandon this blog because its clear that Microsoft is not listening to us in regards of at the very least giving us an "off option" or even that they aren't really reading it.
I will say this: BCG has a *few* things implemented in the Ribbon that CJ does not. But regardless of performance or flickering, BCG has a lot more drawing bugs. If you are not picky about drawing bugs in your GUIs, maybe you should move to the back end work. I have already listed 5 drawing bugs above that you declared "minor". So I'll listed 5 more:
[Before I do, FYI, notice Stas did not even comment on the Office/VS toolbars because they are so broken]
1) On the Office 2007 style menus, the drop shadows are "so weirdly wrong". It looks rectangular with weird points sticking out of it. Not even close to Office 2007 or how a shadow would appear in nature or even the stock OS shadow.
2) On the Office 2003 / Visual Studio 2005 style menus, if the menu gets inverted, the shadow around the button just gets left behind in the wrong place and wrong shape.
3) Visual Studio 2005 demo, I leave a few of the docking windows in the floating position, it now repaints so slowly when the application is launched.
4) Toolbar customization: mouse randomly flashes to "circle slash" cursor and back as I drag a button across the screen, the insert mark is often not drawn correctly, etc. etc.
5) Toolbar buttons often get left in "hot" state when the mouse is not even on them.
There, I threw in a free bonus one in #4. Thats 6 bugs there, 5 bugs from before. That makes 11 so called "minor bugs" I found from just minor testing with the two demos. I have not even scratched the surface in testing other themes and various OSes, etc.
Please stop calling BCG a "great" library, because it is clearly not and as Andre stated, BCG has shown ZERO effort in fixing any of these 11 bugs I just mentioned, because they have existed in the demos for as long as I have been testing them against my library (which is many, many years).
I am not baised towards either BCG or CJ. CJ has issues too, but with Codejock is more of "some missing features" vs. broken ones.
Three years ago I did a major evaluation of CodeJock and BCG (Dundas/Ultimate Toolkit was eliminated quite quickly.) My test consisted of writing the basic framework of the planned application with each toolkit. In the end CodeJock was the hands down winner. It wasn't due to performance as much as the terrible all-or-nothing architecture of BCG--to use it would require compromising to many parts of the design of the application. Plus, BCG required an amazing amount of monkeying around with all basic framework classes and the documentation stunk.
By contrast, CodeJock not only let me use just those parts I needed, its integration into my App was so seamless I thought I'd made a mistake. On top of all that, the documentation was excellent as was the support. They not only got back to me about a serious issue within 24 hours, they solved it! (BCG took over a week and basically told me "tough luck".)
(In case anyone is wondering, in the end .NET was used for the application I mentioned and the result is a big, slow giant--and I mean humongous--turd.)
Someone: The bugs you've listed are really minor, perhaps this is the reason they do exist up today. 99% of customers won't mention them at all. If you want to talk about attention to details in CJ product, please:
1. Buttons should lose pressed/highlighted state when you move mouse cursor out, but keep pressing the left mouse down.
2. White pixel at the bottom right corner of the popup menu.
3. Ribbon tabs, must display at least 3 characters.
4. You can highlight and press another ribbon button when a popup menu is displayed.
5. Should I mention a crash in a Gallery?
I found these problems in 10 minutes as well. So, it seems that CodeJock also has some "broken" features.
1) I mentioned this same issue in BCG
2) BCG doesn't even clip the ribbon tab text properly (neither does CJ). Both often over draw the tabs.
In any event, this discusion is getting pointless. Both libraries have issues. You obviously prefer BCGSoft and I obviously prefer using my *own* library (because I prefer fixing bugs in my own code vs. others). Neither of us will convince the other.
The whole point is, I don't want to ship BCG with my app, so why not have an option to turn it off?
To the other person. Yes, 2MB of unused bloat bothers me. Why do you think I'm not using GDI+ or the 30MB of bloat .NET?
@Joe. Please stop talking about documentation and API. It's well known that CJ's documentation has always been useless. Just search their forums (but they usually remove negative things).
About API and seamless integration with MFC's applications: even Andre told that BCG is much better in this area.
"as the terrible all-or-nothing architecture of BCG"
LOL - go for .NET, Joe, MFC is not your cap of tea :)
@Somebody. "In any event, this discusion is getting pointless"
Agree... Just ignore my answers to Andre :)
You need to stop being an apologist for BCG.
I am speaking from my direct experience of an intense evaluation of BCG. At the time I did my evaluation the architecture did require almost their entire class library to be linked to the application. (You are aware that BCGs architecture is quite different from CJ and UT, right?)
I also stand by my complaints of BCG's poor documentation and support. They simply did not document huge portions of their class library.
I made it very clear this was three years ago and BCGSoft may have changed since then. I doubt the fundamental architecture of their product is much different, but it's entirely possible their documentation has improved.
You snarky comment about .NET makes no sense. I'm trying to keep my apps slim, not fat. I'm still annoyed at the changes to MFC with VS 2002 that at least doubled the minimum size of an MFC app (you used to be able to strip out most the active X stuff amongst other things.) I currently use straight C++ for most my work.
Be aware that your use of ad hominem attacks and suggestions that CodeJock engages in some conspiracy instead of arguing the substance of people's complaints only undercuts your defense. You may have had a good experience with BCG, but I have not and am simply reporting that and why.
"I also stand by my complaints of BCG's poor documentation and support"
Is it related to the new MFC we're discussing here? I believe MS has much more resources to document everything.
"I doubt the fundamental architecture of their product is much different"
The architecture is based on MFC and the whole library is designed to be very comfortable to MFC developers. It's all matter of skills and... taste. But I'm sure this fact influensed the decision.
"Be aware that your use of ad hominem attacks and suggestions that CodeJock engages in some conspiracy"
Some time ago Kirk Stowell, CEO of CodeJock, personally encouraged his customers to post on forums about MS plans to update MFC. Unfortunately, the exact wording I meant in my post above has been cut off from CodeJock's forum.
Are there any plans to upgrade some other parts of MFC, maybe moving away from all those macros.
I can't help but thinking it would make sense to do it now.
I think the discussion is going in wrong direction. It is useless to fight about supremacy one or another 3rd party library. The decision is already made and I don’t believe that VC team is going to change it.
I’m not devil’s advocate so I’m not going to sing alleluia for Microsoft. But I am very excited about the rebirth of MFC. MFC is a great framework and with new features it will became even better.
We are taking here not about BCG or CodeJock. The new extensions are going to be supported and maintained from VC team the next few years. So I don’t think that these gays are going to erase just four chars “BCGP” from the class names and let the cat out of the bag.
I’m looking with a lot of expectation into the future and the time after the first Beta-Release. The nights are going to be short again and we will all have some new chances to bitch about MFC again…
Wow! A lot of feedback both ways...
Lets face it guys:
1) BCG and CJ both have plenty of problems.
2) We aren't going to change Microsofts mind either way :(
3) Nobody from Microsoft is even reading this feedback (and if they were, they wouldn't care). Microsoft has shown in the past that they hardly if ever respond to feedback during the dev cycle or after shipping unless it is really overwhelming (and 5 to 10 people is not considered overwhelming). Remember, Microsoft knows whats best for us :).
4) The code will be maintained by the VC++ team which means we are unlikely to get bug fixes (because they never have delivered them in the past, and I don't expect them to now) between cycles.
Basically whatever glitches or bugs or performance issues the initial release comes with, you'll have to decide if you can live with that for 1yr+.
BCG won't save you... they aren't going to release new builds of MFC. You'll have to go to the external BCG or the external Codejock which makes integrating either library so tightly into MFC a really, really, really, really, really, really, really, really, really, really bad idea.
All these features are in Visual Studio 2008 Beta 2. I don't see it. This is marketing crap!!!
These features are not in Beta2. For our release plans, please see our previous post at http://blogs.msdn.com/vcblog/archive/2007/11/09/announcing-a-major-mfc-update-plus-tr1-support.aspx
Visual C++ Team
I used BCGSoft for years and I think that it is (one of) the best GUI lib.
Compare to CodeJock, IMHO, BCG is simpler for developer using and more close to MS products GUI (I mean look and feel).
Anyways I think it is a greate news and the right direction.
Best regards to Visual C++ Team.
Bundling a large GUI library in with MFC is simply a bad idea.
I don't see a massive deployment issue in having an extra DLL for Office Ribbon functionality, just as gdiplus is extra. Tripling the current DLL size is simply unacceptable.