Microsoft ComCtrls and Delphi/C++Builder version 6

By: Eddie Churchill

Abstract: Eddie Churchill describes the pitched battle to maintain compatibility with the XP version of ComCtrls, and also discusses Themes

by Eddie Churchill, RAD group R&D

The ongoing ComCtrls battle

(Also known as "Here we go again")

The compatibility battle between Delphi/C++Builder and Microsoft® ComCtrls (and its Image List) has been going on for years. For each new release of ComCtrls we have had to rework our support for it and ComCtrls v6 is no different. In fact this new version of ComCtrls is even a bigger leap for everybody. Microsoft knew this was going to be the case and went out of their way to prevent an application from accidentally using it. Alas, it is possible for the user to tell the OS to make an application use the new version without the application having any say in the matter, which can produce strange results. Those results can range from simple cosmetic changes all the way to data corruption. There are a number of ways to support the new version of ComCtrls. We are still researching the best route to take, but most of them will result in "interface" changes which cannot be done in an inline update. Thus we have opted to wait until the next major release (Delphi/C++Builder v7.0) to support ComCtrls v6.

What does ComCtrls v6 do?

First, ComCtrls v6 requires Windows XP or better. It doesn't run on anything else. Period. It completely reworks how controls are implemented and behave, not just the traditional ComCtrls controls (TListView, TTreeView, etc) but also those that used to live in User32 (TButton, TEdit, etc). And while the new ComCtrls introduces a few new control types, its real claim to fame is Themes. Themes are all the rage so to speak (or were a while back, things have calmed down a bit on that front). With it you can "change" the look of your application without recompiling, even your users can do it. Well ... "change" is a strong word.

Theming engines have traditionally affected controls by adjusting how controls look (by changing their rendering and in turn possibly size) and possibly where they appear. The latter is not implemented by ComCtrls, but who knows even that might appear in the future. This brings us back to controlling how a control looks. If ComCtrls only changed how controls render that would be one thing but that change may affect the size of the control. The size changing issue mostly shows up in the window border. Themes can make your window's client real estate smaller or bigger than when it was originally designed. If your application isn't prepared to deal with this its forms might look a little amateurish or "cheesy". Judicious use the alignment and anchor properties can fix most of those problems for you.

But what about the actual render of the controls? Most controls automatically render or theme correctly. VCL is for the most part a thin veneer over the controls in User32 and ComCtrls. Alas there are times when it does its own custom render. Mostly this is related to the render of the background of the control. VCL tend to render backgrounds as a solid opaque instead of the theme's background pattern. VCL will need to call the theming engine to render those cases when using the new version ComCtrls. We are currently planning to attack this problem at the custom control level and most of the descendent classes will simply inherit this new behavior. There are a few cases where the actual foreground render of a control will have to be adjusted (TSpeedButton for example) and those too will have to render through the theming engine.

Which brings us to custom controls; those are controls that in part or whole perform custom rendering. If your control simply descends from a standard control and does something logically different but leaves the render alone then you should not have any problem. But if you do your own render then themes will be something that you have to deal with. We currently plan to wrap the theming engine used by ComCtrls and that wrapping will be available to your custom control render code. We'll have more details on this wrapper for you, after we figure out what exactly it is or needs to be.

So I don't have to worry about it right now, right?

This is one of those good news/bad news things. First the good news: your application won't automatically get ComCtrls v6 just because it runs on Windows XP. In fact you have to go out of your way to get it. To do so you have to add a manifest to your application. A manifest is simply a XML snippet that tells the library loader to load a specific version of a library. The manifest can be added via a resource or as a file. The file will always trump the attached resource. Alas here comes the bad news (with ComCtrls there is always bad news): the user can add a manifest without your knowledge.

Did you mention data corruption?

As some of you know there is more to ComCtrls than simply controls. There is the Image List. Much has been written about the Image List, most of it not good. It would take more prose than I care to write to fully describe our history with Image List. It gives me the heebie-jeebies just thinking about it. So I will just limit this to what is different with ComCtrls v6. With this new version of ComCtrls a new Image List format has been introduced. This new format supports a number of image formats that the older format simply could not be extended to support. The library methods that we normally call will not generate a stream that is compatible with the older libraries. This means if the IDE (or your application for that matter) is manifested, and uses the new ComCtrls, it will generate Image List instance streams (for example DFMs) that cannot be read by older versions of ComCtrls. Microsoft has provided a set of new functions that will read and write the older stream format but for some reason they choose to not make them the default.

We have two options that we are currently researching; first we could simply call those new functions or we could come up with our own format that is a bit more portable. Neither is really all that appealing but sometimes that is the way things are.

So in conclusion...

We are planning to support the new ComCtrls in the next major release. Until then please don't add a manifest to Delphi or C++Builder itself or it will start using the new ComCtrls and in turn start writing out Image List streams that are wholly incompatible with anything except Windows XP's ComCtrls v6. You will regret it, trust me.

But I want themes support now! Darn it!

If you want to experiment with themes until then, there are a number of third party solutions that you can use right now. They can be classified in two groups: those built on top of Windows XP theming system and those that are not. Obviously if you want your application to be themeable on something other than just Windows XP, I would recommend the latter group. The following list is not meant to be exhaustive and my apologies to anyone I forgot to list. You can include yourself by commenting on this article.

Windows XP solutions

Windows XP Theme Manager, Mike Lischke

Generic solutions

Theme Engine, KS Development
Skin Form, FriendSoft
Skin Factory, TMS Software
Dynamic Skin Form, Almediadev
Cool Controls, CoolDev
Organic Shape, Praktical
Form Skin, Greatis Software
JfControls Library Suite, JfActiveSoft

Server Response from: ETNASC04