WinForms - Skin Colors and LookAndFeel (v18.2)

12 October 2018

Our upcoming v18.2 release brings changes to the way control background colors are handled in conjunction with skins.

In v18.1 we introduced the Project Settings page which includes a skin selector. This mechanism replaced most use cases of the DefaultLookAndFeel component. For many applications, applying a skin globally is the way to go – it’s easy to do and results in overall consistency.

However, most individual DevExpress WinForms controls also have their own LookAndFeel properties, which have been around for many years. The properties enable per-control configuration of skins and individual styles. Unfortunately this mechanism can be confusing to new users and there are few use cases where per-control settings make sense.

Colors to highlight UI elements

Why would you want to break design consistency and override global skin settings for individual controls? As far as we’re aware, there’s only one important scenario: highlighting specific UI elements using special colors. If you customize control LookAndFeel settings for reasons not covered by this use case, please feel free to let us know in the comments on this post, or by sending email to

In the past, there was no straight-forward approach to apply highlight colors to UI elements. Custom background colors were only used when skinning was switched off for a control, and it took lots of conditional code to coordinate colors with runtime skin configuration.

Custom colors everywhere in v18.2

This is the first big news: starting with v18.2, you can now apply custom foreground and background colors without deactivating skins. To be clear, this means that the setting Appearance.BackColor is honored even when LookAndFeel.Style = DevExpress.LookAndFeel.LookAndFeelStyle.Skin – this combination of settings was ignored up to and including v18.1.

And it gets even better, because we also have…

Skin-coordinated highlight colors

You can now choose special values for control foreground and background colors, which are interpreted differently per skin.

Skin Colors

There are five special color values: Primary, Info, Warning, Danger and Success. Depending on the current skin (and palette, in case of vector skins), these colors use different hues to remain consistent with the skin.

By configuring colors of a control to these special values, you can easily achieve a highlighted appearance for the control that combines nicely with the current skin colors.

Custom Edit Form

For example, to implement the appearance of this custom Edit Form, you would select the skin color Info for the background of the Update button and Danger for the Cancel button. Here’s an illustration of button appearance with these settings in different Bezier palettes.

Skin Color Flexibility

Of course skin colors can also be assigned from code:

colId.AppearanceHeader.BackColor =

You can currently assign skin color special values as backgrounds for these UI elements:

  • Grid Control: Column and Band headers, LayoutView and CardView card captions
  • Simple Button
  • Tabs
  • Group Control
  • Dock Panels
  • Layout Control groups
  • Tree List: Column and Band headers

Support for Pivot Grid column headers will be available by release time. Please let us know if you think we missed an important item here!

Skin color special values can be used for foreground colors without limitations. However, we recommend not to set background and foreground colors to skin color special values at the same time! When such values are assigned to background color properties, they automatically change related foreground color hues to improve readability.

Skin Foreground and Background Colors

Per-control LookAndFeel is deprecated

The LookAndFeel properties on individual controls are not needed anymore with the changes in v18.2. They will remain available for now, but we show a warning message in the editing dialog:

LookAndFeel Deprecation

For future versions, we intend to hide the properties from design-time view.

A word of caution

There is one potential issue with the change detailed above: you may have configured Appearance.BackColor properties in the past while LookAndFeel.Style was set to Skin. Such setups could be leftovers from quick “tests” for look&feel configuration, or from previous UI styles that were superseded by skins. In such cases, you may see unexpected control background colors after upgrading the project to v18.2.

To help you find any such issues in your projects, we have extended our diagnostics API that is described on this page about DirectX. For many cases it will be helpful to set the PaintApiDiagnosticsLevel.Throw mode, like this:


As a result you will see an exception thrown when a control renders a background color that is not a skinned color (i.e. not a DevExpress.LookAndFeel.DXSkinColors.FillColors value). This is the recommended approach, since it leads you quickly to the code location where the custom color is used.

Alternatively, or if you don’t like dealing with many individual exceptions, you can take advantage of the Trace mode to generate log output into a file or to the console:

  (apiLevel, api) => {
    Console.WriteLine(apiLevel.ToString() + ": " + api);

The api parameter of the lambda expression will contain a string like AppearanceHeader.BackColor. With this in hand, you can search your code for occurrences of each relevant property and evaluate how it is being set.

Your thoughts are always welcome

As always, we are very interested in your feedback. Are you looking forward to using the new features in your projects? Which other controls do you need to support background skin colors?

21 comment(s)
Christopher Jay

I'm pretty sure this is going to wreak havoc on our huge application, which is a real shame because I was looking forward to 18.2 for the Google calendar sync.

Please provide a global flag we can set on startup to NOT apply this behavior.

12 October, 2018
Christopher Jay

When we started our application, we programmed foreground and background colors manually for each theme, so since you are recommending not applying both at the same time, we're probably going to be all messed up.

12 October, 2018
Dmitry Babich (DevExpress)

Hi Christopher,

From your description, it's not clear why this change should break anything in your application. The only reason we do not recommend setting background and foreground colors manually, because our new Skin Colors engine can do this for you automatically - this means that foreground adapts to skinned background. If you disabled skins for some controls and are using hardcoded colors, everything should work as before.

If you have a more complex scenario, feel free to submit a new ticket in our Support Center or email us at

12 October, 2018
Simon Hewitt

In, Andrew Fraser asked a pertinent question about changing the skin according to user choice. Can you confirm this won't be a problem with the new system.

Also, after just doing a quick search in my projects, I see a number of places where we use the LookAndFeel property you are planning to deprecate - these two in particular:

1) Changing the Style to be Ultraflat (mainly on scrollbars)

2) Using an alternate skin on a RichEditControl to control PageIndentHeight**

So whilst removing it from design-time view seems appropriate to meet your goals in para 3 of this blog, if the long time aim is to remove it altogether then please give enough notice to allow alternatives to be found.

**The latter was suggested as a workaround in T182351 until T183319 is implemented.

12 October, 2018
Dmitry Babich (DevExpress)

Hi Simon,

We hide the LookAndFeel component and LookAndFeel properties only at design time to avoid possible confusion for developers. We don't have plans to remove these classes completely - they will be accessible from code. Using the UserLookAndFeel.Default.SkinName property is still a valid way to change a skin at runtime. Moreover, we added a couple of SetSkinStyle method overloads into the UserLookAndFeel class to simplify the code.

12 October, 2018
Sven Heitmann (Theasoft)

Our application is not using Skins by default. We have a mix of winforms and devexpress all over and wanted to keep the default winforms style by microsoft. However some controls do not look good without a skin, like the Schedule control and the DocumentView control. In this case we use an Office skin.

12 October, 2018
Christopher Jay

We also use different skins in different places, like our AlertControl always uses the same theme no matter which is selected so it stands out from the rest of the themed app better.

12 October, 2018

Thanks for another fabulous addition to Winforms. These colors (esp. for buttons) can give the forms a more modern look.

12 October, 2018

I also use different skins for different components at the same time.

In my opinion, removing the LookAndFeel property and offering to specify it through code is not the best solution. Are there any other alternatives for assigning different skins to components? Of course without creating custom skins ;)

13 October, 2018
Dmitry Babich (DevExpress)


The recommended solution depends on the task. Would you please describe your scenario - why do you use different skins in your application?

You can post this information here in comments, email us at, or just submit a new ticket in our Support Center.

15 October, 2018
Juan Antonio Trujillo Montenegro

Nice to see skin-coordinated highlight colors feature coming to 18.2.

We currently use special colors for canceled, active, etc states and it was an exhausting task to have a color state that plays nice with most of the skins.

Is this feature also coming to WPF and XAF?

15 October, 2018
Alex Chuev (DevExpress)


Starting with v18.2, you will be able to reference any palette color in WPF applications as follows:

<Border BorderBrush="{DynamicResource {dxt:PaletteBrushThemeKey ResourceKey=Border}}" BorderThickness="1" />

As for special color values (Danger, Info, Warning, etc.), I will pass your request to our developers.

P.S. XAF applications use WinForms controls, and all the features described in this blog post will be available there.



19 October, 2018

Thats perfects. I like button skin and these changes will be usefull.

22 October, 2018
Reischek Florian

Is Appearance.BorderColor also working even if we use Svg Skinned components ?

26 October, 2018
Dmitry Babich (DevExpress)

@Reischek Florian

Currently, it's possible to change a skinned component border color only by modifying a corresponding skin element. Would you please describe your scenario in greater detail? Please submit a new ticket in our Support Center or email us at

29 October, 2018
Chuck Bass

I have a lot of code that does an OK job of handling colors, I will happily modify my code to handle this.  Your 5 "states" map very well into my application.  Nice work!

10 December, 2018
Ben Ernest-Jones

We have developed a demo prototype of our application, and in the same running process we have multiple "top level" forms (all ribbon based and using DockManagers) that represent different types of users that might use our application. Each form has slightly different functions available, and classically we have used different colored skins to make it clear during a demo to clients that we are showing screens used by different types of users. It is a shame if this is no longer easy to do through setting different LookAndFeel settings for each top level form.

27 December, 2018
Dmitry Babich (DevExpress)


We didn't remove this property. If you changed the LookAndFeel property in your application, it will continue working as before. For new forms, you will be able to access it in code.

28 December, 2018
Ben Ernest-Jones

I tried this in the constructor of my form where I want to use a different color palette than the rest of the application, but it still changes the color of the rest of the application, and setting the global skin elsewhere still changes the form that should be separate:

this.LookAndFeel.UseDefaultLookAndFeel = false;

this.LookAndFeel.SetSkinStyle(UserLookAndFeel.Default.SkinName, SkinSvgPalette.Bezier.Fireball);

Sorry to get technical in comments... happy to open a support ticket to dig deeper if you think this sounds like incorrect behavior or I'm doing something wrong.

28 December, 2018
Dmitry Babich (DevExpress)

Yes, it still should be possible to apply different skins to different forms. Feel free to post a new ticket in our Support Center and we will do our best to help you.

28 December, 2018
Ben Ernest-Jones

To follow up for anyone interested, my problem was that I was trying to only change color palettes for the same skin on a different form, which is not supported, but I was indeed able to use completely different skins on different forms (Bezier vs Office2019Colorful in our case).

2 January, 2019

Please login or register to post comments.