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
Oh, I did exactly as you recommended, Somebody, and found Andre's opiniton here (pretty sure it's him):
I'm just wondering what made this guy so angry at BCG...
Prove that BCG performance is poor? I thought I already did that. I listed 5+ performance issues in a post on Sunday. I read the link you posted about Andres post. I fail to see your point. He said "it integrates more naturally into MFC", but he also said "performance is poor [in several areas]".
Let me re-iterate my position. I said:
1) I have never used EITHER BCG or CJ
Actually, that is not entirely true... at my last company, they had a product that was originally written around CodeJock. The original author said that he spent a lot of time fixing CJ bugs (not sure what version he was basing that one). I ripped out the CJ and replaced it with my own library because I wanted controls that CJ did not offer at the time and I wanted to use my own library of course. I didn't really care if CJ was good or not because it didn't offer the controls I wanted at the time (and neither did any other library except mine).
2) I said strictly from DEMOS that CJ looked better. I stand by that and have listed 5+ issues as proof.
3) I simply want a way to turn it off regardless of whether microsoft uses BCG, CJ or even mine.
4) I have better things to do then spam programming blogs
5) By the way you are defending BCG (while no one else is), its clear you work for them. Should we take the word of a BCG employee over the dev community?
Should I have put a disclaimer before, that I don't work for them? :)
I've been using this great (IMHO) product for a long time and just can't stay aside when you and others use the words like "horrible", "poor quality", "abysmal" and so on. Yes, I saw the issues you listed. So what? None of them is critcal enough to say "horrible".
Your position to turn off this stuff is clear -and I don't argue here.
"I fail to see your point. He said "it integrates more naturally into MFC""
The point was "I like the BCG library more". That's all.
Is you own lib available to buy? I am very interested in a good C++ lib.
@Tomas: I don't post anonymously anywhere. And you're right, the old posts on the BCG forum are from me too. I've already said a few posts above that I've used the BCGControlBar till 2 years ago. And yes, it integrates better into existing MFC apps than the other toolkits. But unfortunately the performance hit was too big and also the quality went downhill. So I had no choice but to replace it with Codejocks toolkit. For some time I had a #define to switch between BCG and CJ but it became clear that BCG doesn't match my requirements and won't do in the future. And many others share my opinion. Beside you I know only one other guy who prefers BCG but many who prefer CJ.
But we don't have to argue here which toolkits is better, everyone has different requirements. The point is that NO toolkit should be integrated into the MFC. And beside all the technical reasons I also see legal issues. If every app has to ship and #include BCGs stuff anyway than they do have an anti-competitive advantage.
Chris: Thanks for the interest. I don't sell my library because I don't have the resources to develop or support it full time.
@Somebody: why not upload the sample application built with your lib and post link here? If it's so good you're likely to get venture capital and resources to develop/support it.
At least we'll be able to compare your demo against CJ and BCG.
Andre, I don't see any advantage here, except some marketing exposure. If someone needs a lightening speed tweaked library with perfect pixel match, he still may use CJ products. At the same time, CS has already complete library, while BCG has to create a new one (either derive its classes from the new controls, and/or cut the existing functionality, otherwise it will be shipping the stuff that has been already included in the new MFC - exactly the same stuff!).
VS is shipped with many tools. Would you use a free version of profiler or documentation tool if you need something advanced and professional?
My name is Stas Levin and I am the CEO and Founder of BCGSoft. I really appreciate everyone who’s taken time to comment - even those that have been negative regarding our product. This definitely shows that there’s a lot of passion around native code and libraries. This is a good thing!
We believe, however, that there’s been a lot of misinformation regarding our products. We have thousands of satisfied customers that are using the BCGSoft Professional Library. Many of these customers ship commercial applications with BCGSoft. They are a testament to the quality and performance of our product. If we didn’t believe that we’re better than any competing product we would never have offered a 30 day money back guarantee.
I do want to address some of the specific points that have been raised around performance and flickering:
* Ribbon redrawing performance has been dramatically improved: we worked hard to resolve this problem.
* Tooltip flickering and redrawing problem: yes, this actually happened on the slow computers with a “huge” tooltips. Fixed.
* Other performance and flickering issues will be reviewed and resolved soon.
We’re proud that Microsoft selected us to be their partner in significantly improving MFC. They chose us after a thorough evaluation and I see from their posts on the forum that they stand by their decision. We know that our software isn’t perfect, but we still believe it’s the best on the market. We will continue to strive for excellence and remain open to all your suggestions, comments and feedback.
I'm surprised at the negativity about BCGSoft, and requests for MS to choose a "quality" library if they are to choose any.
The thing is that BCGSoft *is* regarded a high quality UI library. We've used it for some time, and I have not found a library that preseves the quality this well while at the same time adhering to MFC design guidelines. The latter one is a big one too, which I honestly didn't find CodeJock to be as compliant to.
BCG seem to provide a pretty darn complete feature set and at least to me in a blind test, I wouldn't really be able to distinguish a well designed Visual Studio-like app in BCG vs the real thing.
And complaining about adding ~2 MB to the DLL size? Is that really a big deal? What are you doing, shipping your applications by e-mail?? Tons of .NET developers found the .NET Framework at something like 25 MB acceptable, anid this is just all about the size of a typical DLL file...?
Thanks for your reply Stas. As you might imagine I do not agree with you. Your competitors have a 30 day money back guarantee too, so what?
The performance was indeed improved in the recent releases. The Ribbon from version 9.0 to 9.4 was unusable for anything else than screenshots. Since version 9.5x the Ribbon may be used by customers who do not have specific performance requirements. Same with all the others controls. Do yourself a favor and compare the CJ and BCG Ribbon sample. Open the file menu in the CJ sample, it feels solid and opens instantly, while the BCG sample feels sluggish*. And you can even see the difference in the task manager. Nitpicking? Or low (lowered) expectations of BCGs customers?
(* and I've compared it on a fast desktop PC while most of my users use older laptops in their cars and shops)
So why should anyone switch back to the BCG controls? Switching the toolkit costs development time. Time that could be spend on features. What value would I as a CJ customers get from a switch? I don't see any.
You had your chance and failed to deliver. You can find my 2 years old posts on your forum where I complain about the performance and you failed to improve, instead you released the Ribbon component with abysmal quality.
I don't want your controls, so please don't annoy me with increased MFC size and compile time. That's all I'm asking for.
Harsh? No, that's why we have competition. And the bundling and integration is anti-competitive.
Ship it as a separate DLL and prove that you can do better than in the past.
I'd like to know who is going to maintain and support the MFC version of BCG? Is it Microsoft or BCGSoft? According to bcgsoft.com they have an update about every 2/3 months. MS on the other hand updates MFC every 2/3 years. So as a MS customer, but not BCGSoft customer, how often can I expect updates? On the other hand if I am a BCGSoft customer, how do I use their latest version with MFC?
@Andre "Open the file menu in the CJ sample, it feels solid and opens instantly, while the BCG sample feels sluggish"
I've just done it. Took the latest ribbon demos from BCG and CJ available on their sites. The CPU consumption is clearly the same. It's hard to see ANY difference in the performance, yet the CJ sample resizes a little bit smoother(but as we read above, BCG has another fix for that).
Should I mention that CJ shows ugly square tooltips and the color picker has nothing common to Office 2007? Where is the context toolbar?
I'm sorry, but CJ's stuff does not come close to BCG's in Office 2007 compliance. (Oh, the Customization dialog - have you ever seen it in the Office 2007 and comapred to CJ's). CodeJock's products have never been ahead of BCGSoft and won't be. The only argument you have is the slight advantage in the performance - nothing more. So, just stop spaming here and let other people enjoy the finest products from BCG.
Without best regards...
Tomas (a big fan of BCGSoft library)
Are there any Visual Studio Product Managers reading this blog? Putting the BCG code in the MFCxx.dll is just plain stupid. The various C++ DLLs are already too bloated as it is--due, no doubt, to a long indifference of Microsoft to actually serve their C++ developer customers. Adding another 2MB is a huge deal--add in the SxS fiasco and all the more reason to statically link.
Does anyone at Microsoft actually realize what all their nonsense has done to installs? They've become positively bloated.
Too bad Borland became such a screwed up company. A little competition might do you some good.