Developing for the Microsoft Windows XP Visual Styles
As you probably know, Windows XP is supposed to ship
with a brand new user interface. Judging from pre-TechEd rumours, this
mysterious user interface (code-named Luna) was based on something called
Visual Styles. Discovering what a Visual Style is and how to develop for it,
is the main reason I attended this session.
The key point is that the Windows XP
interface is based on themes. A theme is a consistent, system-wide way to
draw user interface elements. These elements include controls, custom
controls, icons and HTML pages. Visual Styles are merely the content of a
theme – the applied styles that you see on the screen.
From the developer's standpoint, XP Visual
Styles mean interacting with XML manifests, side-by-side components, the new
ComCtl32 6.0 and colour-rich icons.
So, Windows 2000 and Windows XP applications
will end up having two completely different user interfaces. The transition
though, is absolutely codeless and safe. The differences in the XP Visual
Styles when compared to plain old Windows styles can be summarized in
three elements: non-rectangular and irregularly shaped controls, hot states,
and extended alpha support for transparency. These styles are provided by
version 6.0 of the ComCtl32 control library, which now incorporates all
Windows and shell controls. The library isn’t backwards compatible, so
programmers on older platforms will have to use version 5.8 of the DLL if
they want to program for XP styles. However, the earlier version doesn't provide
all the same features or set of controls.
How can you write an application that
exploits Visual Styles? Actually, XP Visual Styles are not something you can
hard-code. You write a plain old Win32 application and then add an XML
manifest to it (mainly boilerplate code), with the name 'program.exe.Manifest.XML'.
In this manifest – a regular presence in XP applications – you specify
the dependencies of your application. Dependencies include all the DLL files
your application needs. This ensures that your application will work side by
side with the components it has been tested with. It also gives you a neat
way to link to the XP Theme Manager to have your Win32 controls rendered the
XP way.
Manifests can also be embedded in an
application as a resource of type RT_MANIFEST. The DLL loader is the module
responsible for locating and loading all the DLLs for a given application.
When it is loading DLLs for an app, it looks for a manifest and, if found,
reads it and behaves accordingly.
The only requirement for using Visual Styles
in a Win32 application is making a call to InitCommonControls before you
start using common controls. While this is normal for C++ developers, it
will not be for those using VB. So if you're writing VB applications for XP,
bear in mind to put a call to InitCommonControls at the very beginning of
your app if you want to exploit Visual Styles.
The key element in the XP visual architecture
is the Theme Manager (uxtheme.dll). In XP, all controls have been separated
into client and non-client parts. The client part is the actual content
that the control is responsible for providing. The non-client part includes
scrollbars, menus and titles. The non-client parts for each window are drawn
by the Theme Manager according to the settings of the Luna theme. Microsoft
is going to ship other themes with the final version of XP, but is not yet
going to release the documentation for third parties to write their own
themes (this has been decided for the sake of system stability).
INPUT tags and other typical HTML controls
can now inherit the XP Visual Styles under XP. This is an interesting shift
since, until version 5.5 of IE, the browser contained code to render HTML
windowless controls. Now the architecture is more modular and consistent
with a neat separation between the logic of the control and its design. The
ComCtl32 v6.0 doesn’t draw controls anymore, limiting the chances that new
versions will break existing applications. If you add this to side-by-side
DLLs you come to the conclusion that XP is inherently more stable.
At this time, there might problems with
applications that utilise third-party extensions, such as shell extensions
and plug-ins not directly under your control. Testing is the only safe way
to go!
Dino Esposito
|
|
