Explorer Breadcrumbs in Vista

This is a sample that displays the Breadcrumbs control in the Windows Explorer shipped with Windows Vista.

One of the things that really annoyed me with the release of the latest version of Microsoft Windows, Windows Vista, was the lack of documentation and access to some of the features that Microsoft would readily list as the most exciting news in their OS.
Most notably, the ability to replicate the new Explorer controls, and specifically to make use of the word-wheel search control that is featured in both Windows Explorer, Internet Explorer and a range of other Microsoft products. Well, Microsoft did in fact "document" how to create the new Explorer widgets. You can read the explanation here. If you read the Using Theme Subclasses article on MSDN you'll realize that it is not a document written for developers, but rather a document designed to fend off lawyers and anti-trust lawsuits.

The MSDN document doesn't give you any real insight on how to go about and create the new controls. It does however explain that the word-wheel and new breadcrumb control in Windows Explorer is somehow known by the Windows Theme engine. It also mentions that this is considered an internal control that could be deprecated as new Windows versions appear. It doesn't explain what to do with the theme subclass names, nor how they relate. In fact the list of subclasses isn't even complete. It appears that someone hacked the msstyle file and was able to extract a better list. On this new list, the theme subclass BreadcrumbBar turns up. And this is in fact the missing item we need to begin recreating the new Explorer look.

The Source Code

This sample will only attempt to recreate the visuals of the Breadcrumb Bar. It does not attempt to hook up the bar with real path information or navigation behaviour. That is something you must do yourself.
This control only works in Windows Vista or better because it uses the theme styles only available in these versions of Windows.

The theme information in the MSDN article tells us that we can somehow paint or instruct some of the native controls (such as the ToolBar control) to render with a special theme. When we need to manually paint using a theme, we can use the UxTheme APIs. Some of the class names in the list are subclasses of existing common controls and we can activate them simply by using the SetWindowTheme() API.
To make use of the new theme subclass information we need to first inspect how the real Windows Explorer controls are constructed. The real Breadcrumbs and word-wheel controls consist of several layers of child windows on top of each other. It turns out that to make use of the new theme styles, we must recreate the window layers exactly as Explorer does. The Breadcrumb is kind of special as it sits on an Aero (glass) window, and it also knows how to draw a progress bar indicator as a semi-transparent layer. Additionally, both controls display with a whitish barely transparent colour when they do not have focus.

The good news is that you don't have to custom paint much to replicate the controls in Vista. The bad news is that the controls' window hierarchy is a bit complicated. Let's have the Container element layout:

1. Navigation Container. This container window is actually a ReBar control. It is assigned the theme subclass NavbarComposited.
2. Travel Root View. The parent window of the Forward/Back navigation buttons.
3. Address Root View. The parent window of the Breadcrumb control.
4. Search Root View. The parent window of the Search (Word-wheel) field.

The Navigation Container embeds the three controls, each as a ReBar panel. Each Root View is comprised of one or more child windows that make up the actual Breadcrumb and Word-wheel controls. These three Root Views are important because they draw the exterior and fill of the actual toolbar and edit controls as we'll see later.

We'll examine the Word-wheel Search Root View layout:

1. Search Root View. The parent window of the Search field. The root view uses the theme class SearchBoxComposited::SearchBox to paint itself.
2. Word-wheel Edit. The actual Edit control. It is assigned the SearchBoxEditComposited theme subclass. The italic font cue-banner is drawn by the theme engine.
3. Search Button. This is actually a toolbar control. It is assigned the SearchButtonComposited theme subclass.

The Root View of the Search control is the one painting the Edit control exterior (border) and fill. So the Edit window itself is created without the WS_BORDER style. The Root View is able to paint the whitish fill colour when the child controls are used on a glass window. The toolbar that make up the Search (Refresh) button is assigned its own theme style too, and it automatically paints the toolbar buttons with the familiar blue-shaded background. Because the Root View paints the fill, I assume that the theme we apply to the edit and toolbar control actually makes them paint their child area with a transparent colour (with the parent rectangle brush probably).

The only manual preparation for this control is that we must monitor mouse movements so when the mouse hovers over any child control, we can repaint the parent window, which will in turn toggle between the opaque white and whitish transparent colour on a glass window. The Root View does not derive from any common control so we must do the painting by overriding the WM_PAINT handler.
The toolbar contains exactly one button for which we switch button image depending on whether the edit field contains text or not.

And now for the Address Root View layout:

1. Address Root View. This is the parent window of the Breadcrumb control. This root view uses the theme class: ABComposited::AddressBand.
2. Progress Bar. A common control Progress Bar which is used to give indications on a slow-going task. The control is only allowed to draw itself when a value is assign to the progress indicator, otherwise the entire window is transparent.
3. Address Parent. This window acts as the parent to the Breadcrumb toolbar. It paints itself with the BreadcrumbBarComposited::BreadcrumbBar theme class.
4. Breadcrumb Bar. This is actually a toolbar control, and this is the control that paints the path segments. Each segment is added as a separate toolbar button. The toolbar is assigned the BBComposited theme subclass.
5. Go Button. Also known as the Refresh button. This is equally a toolbar control. This one is assigned the GoComposited theme subclass.

The Breadcrumb control has a slightly more complicated layout, with several child windows that act merely as parent to the toolbar and progress bar controls. Most likely the theme engine needs these windows to contain the correct transparency through control notifications.

The Breadcrumb toolbar draws the buttons on its own. When you need the little expander symbol to the right of a button, you just provide the BTNS_DROPDOWN style for it. On the very left of the toolbar, a folder icon is usually displayed as well as a shortcut menu-button (overflow chevron) that allows you to navigate further back in the path structures. These are actually toolbar buttons too and they must be custom-painted. The folder icon is just a static icon, while the shortcut menu-button has a separate style with the UxTheme API (also not documented on MSDN).

Just like the Search button in the word-wheel control, the Go (Refresh) button on the right is implemented as a toolbar control, which paints itself bluish once it is assigned the proper theme subclass.

Through experimentation I have found that there is a slight difference in how to conduct the theme class manual painting process. When Aero is active, it is better to do the background painting in WM_PRINTCLIENT and WM_PAINT message handlers. When Aero is not active, painting only in the WM_ERASEBKGND message handler seems to produce the best result. I'm not entirely sure why that would matter.

Notes

Source Code Dependencies

Windows Vista
Microsoft Visual Studio.NET 2008
Microsoft WTL 8.0 Library

Download Files

Source Code (45 Kb)