One of the things that really annoyed me with the release of the latest version of 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 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 CodeThis 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
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:
- Navigation Container. This container window is actually a ReBar control.
It is assigned the theme subclass
- Travel Root View. The parent window of the Forward/Back navigation buttons.
- Address Root View. The parent window of the Breadcrumb control.
- Search Root View. The parent window of the Search (Word-wheel) field.
We'll examine the Word-wheel Search Root View layout:
- Search Root View. The parent window of the Search field.
The root view uses the theme class
SearchBoxComposited::SearchBoxto paint itself.
- Word-wheel Edit. The actual Edit control.
It is assigned the
SearchBoxEditCompositedtheme subclass. The italic font cue-banner is drawn by the theme engine.
- Search Button. This is actually a toolbar control.
It is assigned the
WS_BORDERstyle. 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
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:
- Address Root View. This is the parent window of the Breadcrumb control.
This root view uses the theme class:
- 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.
- Address Parent. This window acts as the parent to the Breadcrumb toolbar.
It paints itself with the
- 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
- Go Button. Also known as the Refresh button. This is equally a toolbar control.
This one is assigned the
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
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
handlers. When Aero is not active, painting only in the
handler seems to produce the best result. I'm not entirely sure why that would matter.
Source Code DependenciesWindows Vista
Microsoft Visual Studio.NET 2008
Microsoft WTL 8.0 Library
|Source Code (45 Kb)|