Thursday, August 17, 2006

Using XP Styles in Windows Forms 2.0 controls hosted in IE

As part of my investigation for an upcoming project at work, I've done some work to determine whether and how Windows Forms controls hosted in Internet Explorer can be made to use Windows XP Styles without having to use a .manifest file on the client machine. (We make an effort to minimize or eliminate client-based requirements for our application, so that clients can simply point their copy of IE to the app and have everything "just work.")

I found that including a call to Application.EnableVisualStyles() causes the control to be rendered using Visual Styles. For example, a simple Windows Forms 2.0 test control that I put together is normally rendered by IE 6 as show in the image on the left; with the call to Application.EnableVisualStyles() placed in the control's constructor method, the control renders like the image on the right:

Control with XP Styles disabled
XP Styles Disabled
Control with XP Styles enabled
XP Styles Enabled
This behavior may be different from previous .NET framework versions; my boss (the team's former technical lead -- a guy who knows his stuff) reported to me that he spent a fair amount of time back when we first migrated to using Windows Forms controls hosted in IE trying to get XP Styles enabled, when we were using the 1.1 .NET framework, without success.

The behavior is also directly contrary to the Microsoft documentation of the EnableVisualStyles method, which states:

This method will have no effect for controls hosted in Internet Explorer.
This makes me nervous about depending on this behavior, since Microsoft might decide to change it as a "bug fix" to make the behavior be in line with the documentation. (However, why making a change to create a difference in behavior between Windows Forms controls hosted in IE and WinForms controls hosted elsewhere would be a desirable change, I'm not sure, so perhaps no change is likely to be made.)

I also found that if the EnableVisualStyles() method is called for any particular control in a given IE window, it affects all controls on the page. (This does make sense, given that the method being called is a member of the Application object, with the application in this case being the IE instance itself.) Even controls which were rendered to the control calling the method are affected -- in the case I tested, a control which was already rendered in the IE window prior to the control calling EnableVisualStyles() repainted itself to use the XP styles, which it wasn't using when it was initially painted.

This isn't a major concern since my company's controls will be the only Windows Forms controls in any IE window where they appear, so inadvertently affecting any 3rd-party controls which might be present on the page shouldn't be an issue. (And generally, using the functionality of IE hosting WinForms controls at all seems to be a pretty rare practice!) We will need to be careful to coordinate the change among our own various controls, though, to make sure everything looks right when using the new styles.

Update 8/18/2006: This morning, I tested the same control using Internet Explorer 7 (beta 3), and it also does display the XP styles/themes. (I did hit a snag where at first, I thought that it wasn't working in IE7; however, this was because the test machine where IE7 was installed was set to have XP styles disabled OS-wide. When I enabled XP styles in the operating system display settings, the control as displayed in the IE7 window immediately updated to use the XP styles.)

2 comments:

  1. hi~
    help me...

    Windows7 or windows2003,
    Visual Studio 2008, IE8

    VisualStudio Process Attach windows Forms2.0 hosted in IE....

    how to Debug..??

    ReplyDelete
  2. this is contents good!

    thank's

    ReplyDelete