WinForms - Skin Colors and LookAndFeel (v18.2)

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 winformsteam@devexpress.com.

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 =
  DevExpress.LookAndFeel.DXSkinColors.FillColors.Question;

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:

DevExpress.XtraEditors.WindowsFormsSettings.ForcePaintApiDiagnostics(
  DevExpress.Utils.Diagnostics.PaintApiDiagnosticsLevel.Throw);

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:

WindowsFormsSettings.ForcePaintApiDiagnostics(PaintApiDiagnosticsLevel.Trace,
  (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?

12 comment(s)

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

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

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 winformsteam@devexpress.com

12 October, 2018

In community.devexpress.com/.../introducing-devexpress-winforms-project-settings-dropping-global-components.aspx, 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

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

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

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

@Customer37575

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 support@devexpress.com, or just submit a new ticket in our Support Center.

15 October, 2018

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

Juan,

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.

Thanks,

Alex

19 October, 2018

Please login or register to post comments.