Themes Fixed in .NET Framework 2.0 Beta 2

Themes Fixed in .NET Framework 2.0 Beta 2

  • Comments 7

Surely by now you've seen the news on the Blogs.msdn.com homepage that both .NET Framework 2.0 Beta 2 and Visual Studio 2005 Beta 2 (both also known as "Whidbey Beta 2") have been released, so I won't mention it. ;)

I do want to share, however, after having written an article a long time ago entitled Windows XP Visual Styles for Windows Forms1, that themes have been fixed for both TabPage and GroupBox classes. Previously, the container portion of a TabPage did not "inherit" the theme applied to the TabPage, and a GroupBox within a TabPage lead to its child controls not being drawn using theme data. Many people went to a lot of work to P/Invoke the Theme APIs to fix this, and complicated scenarios often arose.

The bug that required a call to Application.DoEvents() has also been fixed so that you can simply call Application.EnableVisualStyles() and Application.Run() in succession.

1Please note that the original article was written and published before 1.1 was released, so the technique may be obsolete but still presents an alternative to supporting Themes for pre-1.1 installations.

Leave a Comment
  • Please add 5 and 8 and type the answer here:
  • Post
  • Could you please explain to me why .NET doesn't simply use the theme glyphs of XP when the winforms app is run on a themed XP and it doesn't when themes are switched off on XP? Why do developers have to add code to enable it and set the controls to flatstyle = system? Why isn't it automatic and only NON automatic for the few who want to run win2k oldstyle theme nomatterwhot?

    As if ANYONE wants to run his winforms gui unthemed on a themed XP!
  • Frans, the theming is a result of binding to Common Controls 6 (comctl32 v6), which requires an application manifest. Comctl32 v6 is a WinSxS (Windows side-by-side) component. If an application doesn't provide a manifest to bind to it, it uses the latest Common Controls (comctl32) installed on the system. This is for backward compatibility. Applications may not look right if they are automatically directed to make calls into comctl32 v6. For this flexibility, Application.EnableVisualStyles() performs this version redirection itself by creating and activating an activation context using "XPThemes.manifest" in the .NET installation directory.

    Realizing that this is a most desirable effect, however, Visual Studio does make this call by default for new Windows Forms projects.
  • Ok thanks for the explanation.

    So frankly it's a windows thing.. :). Let's hope in longhorn it's the other way around ;)
  • Frans, it's actually a backward compatibility issue. Applications should be forced to redirect to new SxS components if they are not designed to work with them. SxS is an opt-in mechanism and requires testing. Function calls in SxS components may change behavior and unless an application - perhaps one written before SxS was even a plausible concept - is expecting it problems could arise.
  • Add Windows XP Visual Styles to your .NET Windows Forms
  • XP Themes Issue

Page 1 of 1 (7 items)