Introduction

This article is about exploring the ability to create custom controls in the .NET platform, that make use of Windows XP's visual styles and themes. To that end I have included a couple of fairly simple controls that mimic some of the behaviors that Windows Explorer implements in XP.

Background

This work is really an extension of what I'm doing at my day job. The project I'm working on right now is a new, .NET version of an existing application. The existing version is your standard MFC app and has all of the familiar Windows 95 era GUI idioms. As part of the new version, we are attempting to add a much-needed update to the user interface.

Part of this effort is the desire to conform to Windows XP user interface styles and guidelines in all parts of the application.

The nice thing about writing a user interface in .NET is the ease with which controls can be created and wired together. Compared to MFC, with its message maps, SubclassDlgItems and WndProcs, concentrating on the needs of the user rather than the needs of the compiler is finally a possibility.

As much as I prefer this new way of creating robust user interface features, I do feel that there is one glaring omission from the .NET framework's System.Windows.Forms namespace: support for themes.

Sure, the Button class will pick the correct look and many of the other controls will take on a themed appearance, but as other articles on Code Project have pointed out, the support for themeing in .NET controls is only superficial.

This is especially true if you are creating your own controls, that need to define there own graphical features.

Using the code

The trick to creating a theme aware custom control is that, you really have to take two paths through the painting process. One has to work on non-XP operating systems and on XP when themes are not enabled. The other has to work when the application is being themed on Windows XP.

The controls ExplorerBar, ExplorerGroup, SideBar and their common base class ThemeablePanel demonstrate this approach.

They all override OnPaintBackgournd and/or OnPaint and decide what sort of rendering to do, based on whether themeing is currently enabled. If it is not, they basically just call the base class functionality, and everything works as normal. If it is, they use the managed theme API to get the correct ThemePart objects that they want to use for their themed representation, and use it to draw the appropriate background and foreground features.

To do this the painting code finds the correct theme part and state, and renders itself using that object:

You'll also notice that these controls also take over the rendering of some of their constituent controls by doing custom rendering in their Paint events. One could go an extra step, and make those constituent controls do their own theme rendering, by creating some derived classes. That is probably the direction I will head as things get more complex, but both approaches work.

Another thing you'll notice right away is that, there a number of classes derived from the common .NET controls like Label and PictureBox with names like ThemeLabel and ThemePictureBox. The reason for this is that, the .NET control classes don't like rendering themselves on a theme textured window (or at least I haven't been able to figure out how to get them to do so). Even when set to be transparent, there are visible artifacts around their edges when rendered over a themed background.

To correct this, you'll notice that all of these controls have a single method that overrides OnPaintBackground:

This override paints the control correctly on a themed background by rendering the background of the parent window rather than the window itself.

Another important point is that the user can change or disable themes at any point during the lifetime of your control. For this reason it is dangerous to hold on to any WindowTheme, ThemePart or ThemePartState object for any longer than a single paint operation. This ensures that your control will always paint correctly even if the environment changes. If it imposes a performance issue with reacquiring these objects with every paint, attach to the Microsoft.Win32.SystemEvents.DisplaySettingsChanged event, and dispose off and refresh your theme objects there.

Points of interest

The first control I worked on was the ExplorerBar class. After working on it an entire weekend (when I should have been outside enjoying the last of a beautiful Minnesota summer), I thought I pretty much had it nailed. I had been switching between the standard XP Blue Luna theme and the non-themed version of XP. So just to see how it looked in the green version of Luna, I switched over to the Olive color scheme.

And guess what! My ExplorerBar was still blue. After hours of scratching my head, digging and re-digging through the API it, began to dawn on me: Windows Explorer doesn't use UxTheme to render its ExplorerBar, even though the theme API defines parts and states for that type of control. Well it turns out that Windows Explorer uses yet another DLL named ShellStyles.dll to render its ExplorerBar, apparently bypassing UxTheme altogether.

My suspicion is that UxTheme is really not really fully cooked, and that it wasn't up to the requirements of Windows Explorer at the time they were developing it, and perhaps still isn't.

Regardless, this leaves the rest of us kind of out in the cold, because most of the custom themes I've looked at don't bother to redefine the ExplorerBar themes defined in UxTheme, but rather use the ones defined by VisualStyles.dll. So no matter what theme you choose, the ExplorerBar in this library will look like the Blue Luna version.

Is this a bug in my implementation? I'd like to say, no it isn't, because there's obviously an abstraction leak in the UxTheme API and it's really a bug there and in Windows Explorer. But I don't have $49 billion in cash reserves, so in reality the answer is probably yes from a user's perspective.

The fix, unfortunately, is to figure out how to dig the bitmaps out of VisualStyles.dll and render them in the correct places (if anybody's already done this and would like to share the code I'd love to see it).

Comments and Discussions

Chuck Norris has the greatest Poker-Face of all time. He won the 1983 World Series of Poker, despite holding only a Joker, a Get out of Jail Free Monopoloy card, a 2 of clubs, 7 of spades and a green #4 card from the game UNO.In the movie "The Matrix", Chuck Norris is the Matrix. If you pay close attention in the green "falling code" scenes, you can make out the faint texture of his beard.Chuck Norris actually owns IBM. It was an extremely hostile takeover.

Have you tried making a 2005 solution and then just add the files for the current project into the 2005 solution. Then you can attempt to run the program and if it gives you a bunch of errors see if you can fix them. If this doesn't help you I don't know what to say. I would try to do this myself, but on the computer that I am using at the time I only have VS.NET 2003.

Regards,
1tg46

Check out 3D Game Development with Dark Basic Professional [^]programming.

Users of this article may want to take a look at the free library here, http://www.skybound.ca/developer/visualstyles/default.aspx[^] (Please note that I am not affiliated in any way with the company that produces this library.) It has support for painting with themes and like the article, provides a wrapper around the UxTheme stuff.

I use the library mainly to get tab pages and numeric up/down controls to paint properly when theme-ing is enabled.

I downloaded the demo project and tried to reproduce the effect outlined by the author in the last part of his article.
Has this already been fixed? I've discovered no problems after switching to the green theme. It seems to be displayed correctly.

Glad you like it. This was an early exploration of WinForms and there a couple of other mistakes in there as well:
- Using event rather than overrides in derived classes
- Not disposing pens, brushes etc.
- Not detaching from child control events
- Using a namespace that I don't control

Just add the following override to the ThemeablePanel object to get rid of those pesky graphic artifacts that sometimes appear when resizing it (I noticed these artifacts particularly when playing with the ExplorerGroup controls):

Thanks for the suggestion. I haven't been in this code for awhile but here's a quick thought:
Does a call to SetStyle( ControlStyles.ResizeRedraw, true ) also fix the problem?
Might be a better way of solving it.

dzCepheus wrote:Oh, and I'm curious -- if I were to use this code in a commercial application, would you mind?

If by "in a commercial application" you mean something unrelated to the re-selling components and conrols, then I would be flattered. I'll just expect a free copy . (Seriously I'd be curious to hear more about the app if you do decide to use this.)

No that isn't by design. In truth, none of these controls shoulg be in System.Windows.Forms since that is a namespace which I do not control (unless I take over Microsoft some day ). I'm not sure what I was thinking when I did that.