Version 1.1 of the .NET framework introduced the method
System.Windows.Forms.Application.EnableVisualStyles. Calling this method prior to the creation of any Forms or Controls, will cause Windows XP to apply a theme when rendering Windows Common Controls and many of the native .NET controls like Buttons and CheckBoxes.
Using .NET 1.0, MFC, WTL or VB6, it is necessary to include a manifest, either in the same directory as the executable, or compiled into it as a resource, in order to make use of Windows XP visual styles. While not overly difficult, providing a manifest for every executable one creates is tedious, and Visual Studio has very little tool support for helping you to do so.
The introduction of
EnableVisualStyles to v1.1 of the framework is a nice addition because it allows WinForms applications to easily adopt the new look and feel of Windows XP styles.
The problem is that there is bug in the implementation of
EnableVisualStyles that interferes with
Images stored in an
ImageList component and Window Common Controls, like the
Toolbar classes. The effect is that if you call
EnableVisualStyles, all of the images will disappear from your toolbars, treeviews and listviews.
To reproduce the bug:
- Create a WinForms application in VS.NET 2003
- Add a
- Add an image to the
ImageList and a button to the
- Assign the image to the button
- In the
Main method add a call to
Application.EnableVisualStyles just before the call to
When you run the app on Windows XP, with a Visual Style active, there will be no image on the toolbar button.
After some searching through Google groups I found some discussion of this issue and a work around that seems to work and hasn't caused any problems in my applications. (To read more about the work-around go here)
A call to
Application.DoEvents just after
EnableVisualStyles, seems to fix the problem. How or why, who knows. Most likely it causes some message that was sent via
PostMessage to get flushed out to the correct place, before the creation of the first WinForms based window.
So the work around code looks like this:
As of yet, I haven't seen any ill effect from the work-around and it seems to always work.