The Chromium Embedded Framework (CEF for short) is an open source framework for embedding Chromium-based browsers in other applications. The base implementation is targeting C/C++ applications but ports for other languages exist (these include Java, C#, Delphi, Python).

The nightly builds (for various systems and platforms) of CEF are available for download at These include:

  • CEF source code necessary to build your apps with
  • CEF dynamic and static library files (together with its dependencies) that you must use in your application
  • C++ wrappers for the C API
  • source code of two sample applications, one called CefSimple and one called CefClient
  • symbol files for debugging binary distribution of CEF
  • build of CefClient sample app with all dependencies and resources

Building the 64-bit version of the sample applications is not straight forward though. In this article I will show what you have to do make it work.


The following prerequisites are necessary:

  • Visual Studio 2013
  • CMake tools

Notice: Though CMake should be able to generate projects for Visual Studio 2015, I was not able to make it happen. Moreover, the cef_sandbox.lib lib is built with Visual C++ 2013 which means the modules that are linking it should also be built with the same tool set.

You should download the nightly build of the development branch for Windows 64 bit and unzip it.

Create Visual Studio projects

To create Visual Studio projects run the following command from the CEF’s main folder in a console:

This will create:

  • a VC++ 2013 solution called cef.sln in the main folder
  • VC++ 2013 project files for libcef_dll, cefsimple, cefclient
  • two additional project files called ALL_BUILD and ZERO_CHECK

This is how the content of the CEF folder looks after generating the Visual Studio project and solution files.

This is how the Visual Studio solutions looks.

Create 64-bit configurations

Though the download is suppose to represent the 64-bit version of the framework, and the DLLs and LIBs in the Debug and Release folder (i.e. the CEF builds and its dependencies) are indeed built for the x64 platform, the generated projects do not have configurations targeting the x64 platform.

What you have to do is:

  • create configuration for targeting the x64 platform (by copying the settings from x86)
  • change the Output Directory for all projects and configurations to be $(SolutionDir)$(Configuration)\ which means the output folder will be the existing Debug or Release folder from the main CEF folder.
  • for the libcef_dll project change the Librarian > All Options > Additional options to /machine:X64 %(AdditionalOptions)
  • for the cefsimple and cefclient projects change the additional dependencies settings to point to libcef.lib, libcef_dll_wrapper.lib and cef_sandbox.lib, instead of the relative paths as in the project.
    This is how the list should look for all platforms and configurations:
  • for the cefsimple and cefclient projects add $(SolutionDir)$(Configuration)\ to the Library Directories for all configurations and platforms
  • modify the Post Build Event for the cefsimple and cefclient projects to no longer copy files from the solution’s Debug and Release folders to the project’s Debug and Release folders.

    Initially, the post build event looks like this (for Debug configurations)

    It should be changed to look like this (beware at the output folder indicated by outputresource; it should be the Debug\Release folder in the main folder):


In the main folder there is a sub-folder called Resources. The entire content of this folder must be copied to the out folders, Debug and/or Release. These files are necessary for the sample applications to run properly.

Building and running

With all these in place you can build the projects. The build should succeed and the content of the Debug folder for instance should look like below.

You can then run the two sample applications. This is how cefsimple looks.

This is how cefclient looks.

, , , , , Hits for this post: 10469 .

In Visual Studio 2015 MFC comes with a new features (something that has rarely happen in recent years): support for dynamic dialog layout. That means library support for moving and resizing controls on a dialog. In this article I will show how this feature works.

Suppose we have the following dialog:
Dialog in original size

What we want is that the controls on the dialog move (the buttons) or resize (the group box, edit and the list) when the dialog is resized:

Resized dialog

Resized dialog

The resource editor provides support for this, but it can also be done programmatically. If you open the properties of a control there is a new category called Dynamic Layout that allows you to select a moving and a sizing type.
Dynamic Layout Settings
The options you have for both moving and resizing are: None, Horizontal Vertical, and Both. These options should be self explanatory. However, the important thing to notice is the value for the X and Y axes moving and resizing: these are ratios, not dialog units or pixels, having a value between 1 and 100 and defining how much a control is moved or resized when the host dialog changes size.

Now, to enable the layout shown in the the example above we need to do the following:

  • fully resize (100%) the group box and list box both horizontally and vertically
  • fully resize the edit control horizontally
  • completely (100%) move the OK button vertically
  • completely move the Add button horizontally
  • completely move the Clear and Cancel buttons both horizontally and vertically

Dynamic layout settings for the example dialog
It is pretty simple to put values into the dynamic layout settings for each control. When you build and run and resize the dialog box the controls move or resize accordingly.

These dynamic layout settings are put in the resource script (.rc file) of the application. For the example above it looks like this:

In this definition IDD_MFCDYNLAYOUTDEMO_DIALOG is the identifier of the dialog for which the settings are defined and the numbers in the BEGIN-END block represent:

  • the first line is a header containing the version number on the structure (0 in this version)
  • the consecutive lines are the dynamic layout settings (move and size ratios) for each control on the dialog, corresponding to the order the controls were defined for the dialog in the resource script file.

Dynamic layout settings in .rc file

These settings are loaded into a CMFCDynamicLayout object (see afxlayout.h/cpp). This is done in the OnInitDialog method of the CDialog class as shown below:

Note: for CPaneDialog, CDialogBar and CFormView on the other hand this is done in HandleInitDialog.

This LoadDynamicLayoutResource is actually a member of CWnd which contains other methods for working with dynamic layouts:

  • EnableDynamicLayout: enables or disables layout manager for a window
  • IsDynamicLayoutEnabled: indicates if layout management is enabled for a window
  • GetDynamicLayout: retrieves a pointer to layout manager
  • ResizeDynamicLayout: readjust the position of the controls handled by the dynamic layout manager as a response to WM_SIZE
  • InitDynamicLayout: initializes dynamic layout manager as a response to the WM_CREATE message

These methods allow you to enable or disable the dynamic layout management on the fly.

  1. Initially the dynamic layout management is set so the controls move and resize when the dialog is resized.


  2. Disable the dynamic layout management and the child controls are no longer adjusted.
  3. Re-enable the dynamic layout management and it works again.

The catch here is that just calling CWnd::EnableDynamicLayout won’t work because this method only deletes and recreates the CMFCDynamicLayout instance.

Just like CDialog::OnInitDialog you’d have to call CWnd::LoadDynamicLayoutResource. Therefore, the correct code for enabling and disabling dynamic layout management should look like this:

As mentioned earlier, setting the move and size values for dynamic layout management can be done programmatically using the CMFCDynamicLayout class. This is important when the controls are created dynamically and not in the resource template. What you have to do is:

  • create the CMFCDynamicLayout object
  • store the host window (the dialog) in that object
  • add the child controls with their move and size settings

The following code provides the same dynamic layout functionality as shown earlier except that all is set from code. Note that you must call EnableDynamicLayoutHelper from OnInitDialog.

Actually the same code as above can be expressed differently with the help of several static methods from CMFCDynamicLayout that create instances of MoveSettings and SizeSettings.

One important thing to notice here is that this code does not call CWnd::LoadDynamicLayoutResource because there are no settings in the resource script file. All these settings are only provided programmatically in this case.

When controls have to move or resize completely (100%) across one or both axes, setting the right values for the layout is straight forward. It gets complicated though when controls are not positioned sideways or need to move or resize with more complicated rules. Let’s take an example where the OK and Cancel buttons are positioned at the bottom vertically and centered horizontally. When the dialog resizes they should retain the original size, but they should always remain at the center bottom.

dynlayout10 dynlayout11

In this case the Y ratio for move is again 100. But what is the move ratio on the X axis? To determine you need a paper and pen. Basically we need to find how much do the buttons move on X when the width increases by 100 units. That is the ratio we have to set.

Initially the dialog has 251 units, that means two halves of 125 and 126 units. We want to keep the buttons apart by 10 units. What means the OK button is left aligned at 70 units and the Cancel button is left alight at 130 units.
Then we increase the size of the dialog by 100 units. It’s now 351 and the haves have 175 and 176. The buttons are still 10 units apart and their with is still 50 units each. That means the OK button is now left aligned at 120 units, and the Cancel button is left aligned at 180 units.
The conclusion is their both left margin has moved 50 units, and that is the value we need to set for the X ratio of their move setting. (Remember, the value is a ratio, but 50 units out of 100 units is also 50%.)

What if the OK and Cancel buttons should both be aligned at the center of their each half on the X axis and always preserve the margins? In other words they should change like this:

dynlayout14 dynlayout15

In this example, initially, the dialog has 231 units and that means two halves of 115 and 116 units. The buttons have both 60 units width, so they are aligned at 27 or 28 units to the margins.
When the width of the dialog increases by 100 units to 331 units, the two halves have 165 and 166 units. The buttons preserve their margins, so their new width is 110 units.
(Notice that the image above is stretched and the margins may be misleading.)

The conclusion is that:

  • The OK button did not move horizontally, but it increased its width from 60 units to 110 units, that means 50%.
  • The Cancel button moved horizontally and is now left aligned at 193 units instead of the original 143 units. That means it moved by 50% horizontally. Its sized increased from 60 units to 110 units, that also means 50%.

With those values set the buttons are resized and positioned as intended.

For more information see MFC Dynamic Dialog Layout.

Demo source code:
MFC Dynamic Layout Management - demo 1 (974)
MFC Dynamic Layout Management - demo 2 (872)
MFC Dynamic Layout Management - demo 3 (707)

, , , Hits for this post: 17383 .

A WinForms DataGridView control has the ability to automatically generate its columns and populate from a specified data source (which can be a DataSet, a simple list or something else). All you have to do is something like this:

When you do the same in MFC, it doesn’t work (supposing that you followed all the steps for hosting a WinForms control in an MFC application as described in MSDN).


After debugging through the .NET framework sources I realized the problem was that the BindingContext property of the DataGridView control was null. This property represents a manager of the list of bindings for the control. If this is null then the control will use the binding context of the parent, which is usually a WinForms form. However, in this MFC application there is no WinForms form and the parent of the DataGridView control is null, which means the control does not have a bindings manager, and no bindings can be set.

The solution is to explicitly set the BindingsContext property to an existing binding context (a new object) before setting the data source.


The lesson learned is that when you host a WinForms control in an MFC application some things won’t just work out of the box, if they rely on a parent form functionality. There is no such WinForms form and you might need to do additional manual initialization.

, , , , , , Hits for this post: 38195 .

CDatabase bug in MFC in VS2012

After migrating an MFC application from Visual Studio 2008 to Visual Studio 2012 I run into an unexpected error: the application was having problem fetching data from the SQL Server database. After debugging it turned out that function CDatabase::GetConnect that I was using to retrieve the connection string after opening the database (for different purposes) was suddenly returning an empty string. It turned out this was a known MFC bug, reported on Microsoft Connect. The cause of the problem is that CDatabase encrypts the connection string, and then empties it. Here is a snippet of OpenEx:

Though Microsoft promised to be solved the bug in the next major version I needed a fix now. So here is my fix.

CDatabase has a protected member m_strConnect which is supposed to keep the connection string in plain text, and one called m_blobConnect that represents the encrypted connection string. However, there is no method in CDatabase to return this blob. Getting the blob would allow you to decrypt it and get the actual connection string. So the solution is to derive CDatabase, provide a method to return the connection string, and in your code replace CDatabase with this derived class and the call to GetConnect() to this new method.

, , , , Hits for this post: 31560 .

It is possible to host WPF controls in a Win32 application, and the other way around, but because of the differences betweeb these technologies there are various issues that can appear. One of these is handling of keyboard input. Without diving too much into differences between WPF and Win32, I will show how to provide keyboard input for WPF controls hosted in a Win32 applications. For reading about the differences and the interoping between the two I suggest WPF and Win32 Interoperation.

Hosting a WPF Control in Win32

To host a WPF control in a Win32 application you need to follow several steps.

  • Create a new HwndSource, setting the parent window as it’s parent. This is a key object, that enables displaying of WPF content in a Win32 window.
  • Instantiate the WPF control or window
  • Assign the reference to this instance of the WPF control or window RootVisual property of the HwndSource object.

To simplify this process, I have this small helper class:

With this class I can create WPF controls like this:

Enabling Keyboard Input

While you can use the mouse with these WPF controls added like this, the keyboard in not enabled. To provide keyboard input for the WPF controls, we need to hook the HwndSource, adding a handler that receives all window messages. We must handle the WM_GETDLGCODE message to let the system know what kind of messages we want to handle on our own (in the WPF control).

This is how we add the hook:

And this is how the hook procedure looks (defined as a static member of my CWpfControlWrapper):

By returning all these dialog codes will let the system know that the window wants to process arrow keys, tab keys, all keys and receive the WM_CHAR message.

Enabling TAB Navigation

Even though the WPF controls now have keyboard input, it turns our that navigating with TAB (forward) or TAB+SHIFT (backwards) does not work.

Here is an example where I have an MFC application with four WPF controls, two buttons and two text boxes. One button and one text box, as well as the OK and CANCEL buttons have tab stops.

The sample dialog box looks like this:

Pressing the TAB key should allow navigating from button 1 to edit 1, then button OK, button CANCEL and then back to button 1. Button 2 and edit 2, not having the tab stop style defined, should not be included in the navigation.

As already mentioned, this does not work, however. After reading about a solution for this problem, it looked like the key lied in the IKeyboardInputSink interface, that both HwndSource and HwndHost implement. This interface provides a keyboard sink for components that manage tabbing, accelerators, and mnemonics across interop boundaries and between HWNDs. Apparently the solution was to:

  • derive the HwndSource class
  • override the TabInto method (actually, since this is a sealed method you’d have to define a new override for it) and implement there the tabbing logic
  • use this derived HwndSource to present WPF content in a Win32 window

Though I tried several things I didn’t manage to make it work. However, since I already had a hook for all window messages, and explicitly asked for receiving WM_CHAR, it was possible to use this to handle TAB and TAB+SHIFT. So here is an addition to the ChildHwndSourceHook above:

So if we get a WM_CHAR and the wParam is VK_TAB, then we query the parent for the next tab stop (for forward navigation if SHIFT was not pressed, or backwards navigation if SHIFT was also pressed). If there is such a tab stop we set focus on that window.

The FindNextTabStop method (added as a member of the CWpfControlWrapper class) looks like this:

It does the following:

  • it gets the next/previous window in the z-order (which defines the tab stop order)
  • when it reaches the end/top of the z-order, it starts all over again, which enables looping through the child windows of the parent
  • if the next child the in z-order is the current control, then it finished looping through the children of the parent and it stops
  • if the current child in the z-order has the WS_TABSTOP style set, then this is the window we are looking for

With this defined, it is possible to use the TAB key to navigate between the WPF controls on a Win32 window.

Here is the MFC demo application that you can try: Mfc-Wpf Tabbing (1228).

, , , , , Hits for this post: 51983 .

Visual Studio 11 Beta was made available today (See Jason Zander’s announcement). It can be downloaded from here. These are my first impressions after downloading and trying it.

The New UI
I have already talked about the new Chrome theme. I find it awful, you don’t know what’s enabled and what is not. I wish they change it, and at least give us the possibility to opt for this theme or the classic colored theme.

Startup time
It takes Visual Studio 2010 about a whole minute to start on my machines, so I didn’t have great expectations for Visual Studio 11. However, I am impressed with the startup time, which is about 3 seconds. Excellent.

Opening projects created with a previous version
When I opened a solution build with VS2010 it did not prompt me the classic question about upgrading to the new version. That’s because the project file schemas were not changed between VS2010 and VS11. This is the first time this happens. As for the solution file, it just updated the format version without prompting for anything.

Microsoft Visual Studio Solution File, Format Version 12.00
# Visual Studio 11

Quick launch window
The first thing I do when I install Visual Studio is changing the fonts. But sometimes finding such windows or commands is cumbersome. A new window called Quick launch is now available in the top right corner. You can type for commands and it searches through menus, options, tool windows, etc. displaying a list of results. When you press on a result it executes the command.

Solution Explorer
This is now a hub for functionality previously available in Solution Explorer, Class View, Object Browser, Call Hierarchy, Navigate To, and Find References tool windows.


You can search in the solution explorer, view the call graph, hierarchy types etc. As you do this it creates new views kept in a stack. It is possible to navigate between these views with two buttons, Back and Forward that are available in the left side of the Solution Explorer toolbar.

The other buttons are:

  • Home: brings back to the home view of the solution explorer
  • Collapse all: collapses all the items in the Solution explorer three view
  • Sync with Active Document
  • Preview selected items: when this is enabled, as you select files in the tree they are displayed in a special document window, docked on the left of the documents bar. This is excellent because it helps viewing the file (or a method in a file) immediately, yet without opening lots of files (since they are all displayed, one at a time, in the same document window).
  • Properties: opens the properties window for the current item
  • Show all files: as in previous versions
  • View class diagram: shows the class diagram (or creates a new one if one does not exist) for the current item
  • Create a new window containing a copy of the content of this window: this duplicates the solution explorer window, just in case you want multiple views

If you want to quickly find something in the solution explorer, you can use the search control. As you type, the content is filtered to show only the elements that contained the type text. This includes source files, references, images and everything else in the tree.

Search and Replace
There is a new quick window for search and replace. This window is displayed in the top-right corner of the active document window. This window is specific for each document; when you switch to another document, it closes.

It is possible though to open the classic window, which looks like this:

Symbol selection
A nice IntelliSense feature is highlighting in the entire document the symbol under the cursors selection. This helps a lot figuring where else in the code the symbol is used. And also helps when you have variables with the same name in different scopes, because it only highlights the symbols that are visible in the scope of the block where the cursor is.

References Window
The window for adding references has also been redesign. You can see a list of the available components that can be referred. As you hover the mouse over them a check box is displayed on the left, so you can check that component for being added.

NuGet Package Manager
For .NET projects a NuGet package manager is available. You can open it from context menu for the solution or the project.

It opens a dialog where you can search for packages, install, update or remove.

XML Doc comments for VC++
A great feature that was finally added for VC++ is XML doc comments. You can add them to C++ types and methods and generate XML doc files. For generating the output file the /doc switch must be set.

For this sample

The following output file was generated:

The gotcha is that so far it does not work in the automatic way as for C# or VB.NET. When you type /// it does not automatically generate the stubs, you have to add everything manually.

You can use these files to generate MSDN-style documentation using for instance the Sandcastle compiler.

Additional readings

, , , Hits for this post: 33814 .

I’m working on a project to port a 32-bit application for the x64 platform. The first errors that came up when building for x64 were related to inline ASM code, which is no longer supported in VC++ for x64. VC++ has an inline assembler built within the compiler, so you could write assembly code directly in C++ without the need of an external assembler (such as MASM). However, this works only on x86. For x64 and IA64 this is no longer possible. There are several workaround for this:

  • put the assembly code into a separate file and use MASM for x64
  • use compiler intrinsics, which are functions that basically wrap assembly instructions or sequence of intructions
  • rewrite in C++, use Windows APIs, etc.

One error that I had was related to this assembly code:

This was used to generate a breakpoint. This can be easily replaced with compiler intrinsic __debugbreak(), which has an identical effect, except that is available on all platforms.

Other errors I had were due to assembly code used to retrieve the value of the EIP and EBP registers. They were used for walking the stack.

The naked specifier is another thing that is not supported on x64. One way to retrieve the value of these registers that works both with x86 and x64 is using RtlCaptureContext, except that this won’t work on operating system previous to Windows XP. In you don’t care about those operating systems, you could write something like this:

Attention, on x64, register EBP (actually RBP) is no longer used. You should use RSP for getting the stack frame.

However, if you want to build a portable stack walking, use StackWalk64. Despite the 64 suffix, this function works on all platforms (x86, x64, IA64). Here is an article that shows how to walk the stack using StackWalk64.

, , , Hits for this post: 44962 .

If you want to port an existing 32-bit application for the x64 platform (especially since 32-bit processors will soon be history), or if you want to target x64 for a new application, the first step in building for x64 is setting up your solution. In this post I will explain what are the steps in configuring x64 as target platform for your projects. Of course you must have the 64-bit compiler and tools installed to make this possible.

Here is an example of a solution with two VC++ project (a Win32 DLL and a console application).

The VC++ wizards add only Win32 (i.e. x86) as target platform for your projects and for your solution (I believe this will change in the future). You can see this by expanding the platforms combo.

If you open the Configuration Manager window for the solution you can see the available solution platforms, and for each project, the available project platforms (these might not be the same).

The configuration manager allows you to set for each pair of solution configuration and solution platform the platform for each individual project. So in theory you can configure for Debug with Win32 at solution level to have, in my demo solution, DemoProject targeting Win32 and DemoLibrary targeting x64. Of course, in practice you probably want to have all projects targeting Win32 in this case, and for the pair Debug with x64 at solution level, have all projects targeting the x64 platform.

To make this platform available for the solution, expand the Active solution platform combo and select . The New Solution Platform dialog will open and allow you to define a new target platform for the solution. Select x64 and for Copy settings from select Win32.

Then make sure you check the Create new project platforms checkbox. In this case the x64 platform will also be defined for every project included in the solution.

After you do this, the x64 platform will be available in the configuration manager for the solution and the projects, so that you can configure the relationships.

Also, the solution platforms combo from the toolbar now displays both Win32 and x64.

But now let’s say you add a new project to the solution. Let’s call this DemoLibrary2.

Since the project was added after defining x64 as a target for the solution and all the projects, the x64 platform won’t be defined for this project (remember, by default, the VC++ wizards don’t add x64 as target platform). You can see this in the configuration manager, where only Win32 is available for the new project.

To define the x64 target for the new project, use the project platform combo and select (see the image above) to open the New Project Platform dialog. Select x64, as new platform, but make sure the checkbox Create new solution platforms remains unselected. Otherwise you’ll get an error, since the platform is already available at the solution level.

After that, the x64 platform will be available for the new project too, and you can make the appropriate configurations in the Configuration Manager window.

And with that you’re done. All you have to do now is configure the settings for each project, for each configuration and platform.

, , Hits for this post: 42231 .

I this post I will talk about the deployment changes in VC++ 2010. When you deploy an application to another machine you have to install not only the application but all the libraries that it depends on. When you build with VC++, you have dependencies on CRT (C/C++ runtime) and possible on MFC and/or ATL.

Visual Studio 2005 introduced a new deployment model for Windows client applications based on isolated applications and side-by-side assemblies. Assemblies can be either shared (globally registered in the system, installed in the Global Assembly Cache – GAC folder in Windows – and available to all applications) or side-by-side (described with a manifest, distributed with the application and available only to that application).

In Visual C++ 2005, library assemblies (such as MFC, ATL, CRT) have been rebuilt as shared side-by-side assemblies and installed in the native assembly cache, WinSxS folder in Windows. That means they are not globally registered in the system, but are globally available to the applications that specify a dependency with a manifest file.

With VC++ 2005 or 2008 there are several options for deployment:

  • static linking: when you link your application statically against VC++ libraries (CRT, MFC or ATL) the application doesn’t have any dependencies so you don’t have to deploy any other VC++ DLLs to the target machine
  • shared side-by-side assemblies: the VC++ DLLs are deployed in the WinSxS folder; this can be done either with the Visual C++ Redistributable Merge Modules or the Visual C++ Redistributable Package; the application requires a manifest file that describes the dependent DLLs and their version
  • private assemblies: the VC++ DLLs are all installed in the same folder with the application; the application requires a manifest file

When you deploy an application built with Visual Studio 2005 or 2008 a manifest file that describes the dependencies, whether you deployed these VC++ DLLs in the local folder or they where installed in the WinSxS folder. If the manifest is missing you get an error. The next image shows the error received when running an MFC application (called Wordpad2008) build with VC++ 2008 on another machine without a manifest.

Though the purpose of this change was to simplify deployment, the result was probably the opposite. As a result Microsoft changed deployment requirements in Visual C++ 2010. You can now deploy applications without a Fusion or satellite manifest. All you need to do is copy the VC++ dependent DLLs to the application folder and run. The next image shows an MFC application (called Wordpad2010) built with VC++ 2010 running on another machine, without a satellite assembly. No error occurs any more when trying to start the application, because local deployment no longer require a satellite manifest.

With VC++ 2010 there are several options for deployment:

  • static linking: same as earlier
  • central deployment: the VC++ DLLs are deployed in the system32 folder; this is useful for updates, because Windows automatically identifies and updates the DLLs that are deployed here
  • local deployment: the application executable and its dependent DLLs are all installed in the same folder; no manifest file is required.

To find more information about deployment and manifest files I suggest these links:

, , Hits for this post: 48789 .

VC++ Feature Pack that came with Visual Studio 2008 SP1 introduced support for the Office Fluent Ribbon. However, developers had to create ribbons entirely from code, because there was no support in the resource editor for that. Visual Studio 2010 comes with a visual designer for the ribbon.

You can choose whether to use a ribbon or a classical menu and toolbar when you create an application.

By default, the created ribbon has one category (Home) and two panels with several commands.

The ribbon can be opened from the resource editor. There is a new category called Ribbon. By default the ribbon resource is called IDR_RIBBON. The description of the ribbon is kept in an XML file called ribbon.mfcribbon-ms, located in the res folder.

When the ribbon is opened, the toolbar displays controls that can be dragged and drop into the ribbon, including categories, context categories, panels, and a series of controls such as buttons, checkbox, edits, progress bar, slider, etc.

There is support for several styles, Office like and Windows 7. These different styles can be seen in the following image.

The designer provides support for quick testing of the ribbon. On the Ribbon Editor toolbar there is a button called Test Ribbon that opens window with the ribbon. You can quickly see how it will look in the application, however, the commands are not available; clicking on the ribbon commands does not have any effect.

You can add handlers for the ribbon commands just like you do for a menu or a toolbar. In Visual Studio 2010 this can be done with the class wizard.

You can read more about the ribbon designed in MSDN or the VC++ Team’s Blog.

, , Hits for this post: 45001 .