I used to have several open-source projects available on CodePlex. At the end of 2017, the site was put in read-only mode and it will probably be closed at some point. Therefore, I have decided to move the projects that could still be useful to GitHub.

MFC Collection Utilities
A small library that enables developers to use MFC containers (arrays, lists, maps) with range-based for loops. The library consists of a single header that you include in your MFC projects.



A header-only C++ template library for manipulating the settings of a Windows console (colors, text position, input mode, etc.)


, , , , Hits for this post: 800 .

I have tried to assemble together information about the Visual C++ releases, the compiler and the frameworks (MFC and ATL). You can find these on many places, but it is often incomplete or focused on something particular (Visual Studio, C++ compiler, framework, etc.).

The table below is the result of this effort. It is incomplete because it’s not easy to find information about products released more than two decades ago, but if you can help filling in the gaps please drop a comment with the information you have and I will update the table.

UPDATE: Added information about Visal C++ 2017.

Product Codename Release date C++ version _MSC_VER MFC version _MFC_VER ATL version _ATL_VER
C 1.0 100
C 2.0 200
C 3.0 300
C 4.0 400
C 5.0 500
C 6.0 1990 600
C/C++ 7.0 1992 700 1.0 0x0100
Visual C++ 1.0 Caviar 1993 1.0 800 2.0 0x0200
Visual C++ 1.1 Barracuda 1993 1.1
Visual C++ 1.5 Dolphin 1993 1.5 850 2.5 0x0250
Visual C++ 1.51 1.5
Visual C++ 1.52 1.52
Visual C++ 1.52b 1.52b
Visual C++ 1.52c 1.52c
Visual C++ 2.0 2.0 900 3.0 0x0300
Visual C++ 2.1 2.1
Visual C++ 2.2 2.2
Visual C++ 4.0 Olympus 1995-12-11 4.0 1000 4.0 0x0400
Visual C++ 4.2 4.2 1020 4.2 0x0420
1.0 0x0100
1.1 0x0110
2.0 0x0200
Visual Studio 97 Boston 1997-04-28 5.0 1100 4.21 0x0421 2.1 0x0210
Visual Studio 6.0 Aspen 1998 6.0 1200 6.0 0x0600 3.0 0x0300
Visual Studio .NET 2002 Rainier 2002 7.0 1300 7.0 0x0700 7.0 0x0700
Visual Studio .NET 2003 Everett 2003 7.1 1310 7.1 0x0710 7.1 0x0710
Visual Studio 2005 Whidbey 2005 8.0 1400 8.0 0x0800 8.0 0x0800
Visual Studio 2008 Orcas 2008 9.0 1500 9.0 0x0900 9.0 0x0900
Visual Studio 2010 Dev10 2010 10.0 1600 10.0 0x0A00 10.0 0x0A00
Visual Studio 2012 Dev11 2012-08-15 11.0 1700 11.0 0x0B00 11.0 0x0B00
Visual Studio 2013 Dev12 2013-10-17 12.0 1800 12.0 0x0C00 12.0 0x0C00
Visual Studio 2015 Dev14 2015-07-20 14.0 1900 14.0 0x0E00 14.0 0x0E00
Visual Studio 2017 Dev15 2017-03-07 14.1 1910 14.0 0x0E00 14.0 0x0E00

Several notes on the history of VC++:

  • Visual Studio 97 was the first product that bundled together several products (Visual C++, Visual Basic, Visual J++)
  • Visual Studio 6.0 is the only version of Visual Studio that was not named after the release year, but the version number
  • MFC was first release in 1992 with C/C++ 7.0
  • MFC 6.0 released with Visual Studio 6 did not change the name of the MFC DLLs, that were still named mfc42.dll
  • ATL was first released in between Visual C++ 4.2 and Visual Studio 97. The first release of the framework to be included in a product was ATL 2.1 released with Visual Studio 97
  • Visual C++ version 3.0 was skipped to 4.0 to align the product version with the MFC version, whose next version was 4.0
  • Visual Studio 2015, the compiler and framework version are 14.0 and not 13.0, a number which was skipped (for the good old superstitions)
  • Visual Studio 2017, the compiler version is 14.1, a minor version of 14.0 from Visual Studio 2015, and the runtime is backwards compatible to VC++ 2015. MFC and ATL version remain 14.0 as in Visual Studio 2015.
  • _MFC_VER and _ATL_VER macros were initially incorrectly documented in MSDN as 0x1000 instead of 0x0A00


, , , Hits for this post: 28394 .

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 (1538)
MFC Dynamic Layout Management - demo 2 (1297)
MFC Dynamic Layout Management - demo 3 (1137)

, , , Hits for this post: 26719 .

Visual Studio 2015 is out and comes with lots of new features and improvements (see details here) but it also surprised me with what I call a demoting of C++ again to a second-class citizen, after some years when it looked like it regained importance at Microsoft. I’m saying Microsoft has demoted C++ because they made it an optional component in the installer, unlike C# and VB.NET that you cannot opt out and are installed by default with all configurations.

When you run the installer you can see there are two setup options:

  • Typical installation, that includes C#, VB.NET and desktop features, and
  • Custom installation, that allows you to select what components to install.

The typical configuration requires about 8GB of disk space. However, it only installs .NET based components (and of course other related assets). C++ is not part of those “desktop features” mentioned in the installer description. It does however install the C++ redistributable packages.

However, when you run Visual Studio after installation completes, all VC++ components are missing and require explicit installation.

To install VC++ you need to perform a custom installation. This can be done after a typical installation. A custom installation allows you to select what you want to install. These includes programming languages (VC++, VF# and Python Tools for Visual Studio), Windows and Web Development components, Cross Platform Mobile Development components and common tools. In total these require an additional 13GB of free disk space. However, with a custom installation you cannot opt out C# or VB.NET.

A good thing though is that the MBCS version of the MFC library is no longer a separate download, but made available with the Visual Studio installation. You must select the Microsoft Foundation Classes for C++ in the Custom installation to have it installed.

The conclusion I draw from the Visual Studio installation options is that C++ is not viewed as a first-class citizen language at Microsoft. I suppose they don’t think a “typical” developer using Visual Studio develops in C++ so they didn’t put it in the typical installation. On the other hand, they don’t provide us with the possibility to opt out .NET languages we don’t use. I’ve never developed anything in VB.NET and I don’t plan to. I don’t even see the need for such a language (just for some remote resemblance with VB6).

, , , , Hits for this post: 32939 .
This project has been moved to GitHub.

New location: https://github.com/mariusbancila/mfccollectionutilities

C++11 has provided support for range-based for loops. They allow iterating over the elements of a range without using an index.

However, if you try the following MFC code you get some errors because the compiler is looking for a begin() and end() function that provides access to the first and last element of the range:

1>error C3312: no callable ‘begin’ function found for type ‘CStringArray’
1>error C3312: no callable ‘end’ function found for type ‘CStringArray’

MFC does not define such functions for its containers.

Enter MFC Collection Utilities

Tom Kirby-Green and I have developed a small open-source library that enables the use of all MFC collection types in range-based for loops. The library is called MFC Collection Utilities and is available on codeplex.

The library consists of a single header, called mfciterators.h, that you include in your MFC projects.

Compiler and collections support

The library works in Visual Studio 2012 (the first version of the C++ compiler that supports range-based for loops) or a newer version.

The library enables all the MFC collections, both template and non-template, to be used in range-based for loops. This means arrays, lists and maps. For maps you get access to the content through a key-value pair that has two fields: key and value.

Supported template collections

Arrays Lists Maps
CArray CList CMap
CTypedPtrArray CTypedPtrList CTypedPtrMap

Supported non-template collections

Arrays Lists Maps
CObArray CObList CMapPtrToWord
CByteArray CPtrList CMapPtrToPtr
CDWordArray CStringList CMapStringToOb
CPtrArray CMapStringToPtr
CStringArray CMapStringToString
CWordArray CMapWordToOb
CUIntArray CMapWordToPtr



Version 1.0 can be downloaded from codeplex from here.

For simpler installation you can use the available nuget package.


Let us know if you encounter any issues.

, , , , , , , Hits for this post: 33397 .

CPtrArray is a nasty MFC container that should not be used. However, if you deal with legacy code you may not have a choice and have to work with it. Unfortunately, the Visual Studio debugger is not able to display its elements, since these are pointers to void and that can be anything. In this post I will explain how to write a visualizer for Visual Studio 2012 to address this problem.


Visual Studio 2012 has introduced a new framework for writing debugger visualizers for C++ types. This replaces the old autoexp.dat (that you might be familiar with). The new framework offers xml syntax, better diagnostics, versioning and multiple file support.

Visualizers are defined in XML files with extension .natvis. These visualizers are loaded each time the debugger starts. That means if you make a change to visualizers, it is not necessary to re-start Visual Studio, just re-start the debugger (for instance detach and re-attach the debugger to the process you debug). These files can be located under one of these locations:

  • %VSINSTALLDIR%\Common7\Packages\Debugger\Visualizers (requires admin access)
  • %USERPROFILE%\My Documents\Visual Studio 2012\Visualizers\
  • VS extension folders

You can read how to write visualizers in these articles:

Writing the visualizer

There are two things you must do to enable Visual Studio debugger to display CPtrArrays in a nice way.

The first step is to define a type derived from CPtrArray. This type will not be used in code, but will allow the visualizer to figure what is the type of the array elements.

The second step is to create a .natvis file (let’s call it mfc.natvis) under %USERPROFILE%\My Documents\Visual Studio 2012\Visualizers\ with the following content:

And that’s all. Let’s see how this works. Assume we have the following code:

In the Watch window cast the pointer to the array object to CPtrArray<T>. This is where the template type defined above is used. Even though your array is not an instance of CPtrArray<T> it will still work since the derived type does not add anything.

As you can see in the screenshot, the content of the CPtrArray is nicely expanded.

You probably noticed the nd specifier in the watch expression. This specifier (probably standing for “no derived”) displays only the base class info of the object, and not the derived parts (see Format Specifiers in C++). Without this specifier, when the MFC symbols are loaded (for mfc110xx.dll) the array is not visualized correctly.

A simpler hard-coded solution

If you don’t want (or cannot) add the generic type CPtrArray<T> you can still accomplish the same, but with some drawbacks.

In this case the .natvis file should look like this:

You must change the placeholder TYPE with the actual type of the array elements in ValueNode. Then, all you have to do is add the object in the watch window.

However, the big disadvantage of this solution is that all the CPtrArrays in your code are treated in the same manner, as storing elements of type TYPE*. That means if you want to watch arrays of different types, you have to stop the debugger, change the visualizer and attach again. It is impossible to watch arrays that store different element types in the same debugging session.

, , , , , Hits for this post: 47665 .

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: 48768 .

I was writing recently about an MFC bug in CDatabase class in Visual Studio 2012. In the meanwhile I have stumbled upon an even greater bug (check this report on Connect for the details): when the OpenEx function fails (wrong credentials, service not reachable, machine is shot down etc.) it corrupts memory. What happen next is chance. I don’t know when a fix will be available, but until that happens there is a workaround for this. Just like for the previous bug, you have to derive CDatabase and override OpenEx method, copying the original implementation from the MFC sources and adding one more line to null the pointer to already released memory. So, I’ll extend my previous CDatabaseEx class to the following implementation:

, , , , , Hits for this post: 43170 .

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: 39274 .

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 (1564).

, , , , , Hits for this post: 62584 .