What's the reasoning behind this?  System colors are widely use by us and very usable in general.

Hi Klaus, 

It has been our experience and the experience of many of our customers that system colors are NOT widely used. In fact, they can be very confusing for end-users who don't realize that when you choose a system color it may appear as a completely different color on another machine. This is not intuitive or obvious to most users and we received many requests over the years for a way to turn off the system colors in the original (VisualStudio) style of the color picker. 

I guess it depends on the context, of course. I suppose there are some cases where your users might want to use system colors in certain situations, like maybe if they are styling the application being run. But that's why we left you the option of reverting to the older (VisualStudio) style. 

System colors also don't relate to the RGB or palette that is displayed in the new color picker style - those have no meaning for system colors. 

So it was decided that the new color picker style should not support them.

If you really wanted to, you could create your own grid palette that includes the system colors and I think that might work.

I would think having it supported as an option, and turned off by default, would be the best option and serve a wider range of uses, it's a .NET standard after all. Just my opinion.

Thank you for the detailed response.

Hi Klaus, 

What do you mean by "it's a DotNet standard?" I mean... I guess if you are writing applications for developers, it might makes sense, depending on the application, to provide a user with a list of system colors. But as a general rule, desktop applications don't really do this. You won't find system colors as an option in MS Office, for examples. Or any Windows application that I am aware of, in fact.

Visual Studio provides them, because Visual Studio is for developing applications that will run on many different end-user machines and so it makes sense for an application to pick up the colors on the system that the user choose.

But generally speaking, it would make sense to create  Word document and use a system color for the content. 

I don't know what kinds of applications you are creating, of course, so maybe system colors are perfectly valid in your case. So: 

Klaus Timmermann said:

I would think having it supported as an option, and turned off by default, would be the best option and serve a wider range of uses

This is exactly what we have done. :)

Named colors are a part of the .NET Colors class, hence a .NET standard, not just a VS feature.

Our solution allows users (you could call them high-level developers) to freely design forms and default colors use named colors (system colors) so the forms will follow Windows's colors.

Named colors is not an option for the new palette style which is default, only for the old style which we have now reverted to.

Hm, I think there's some confusion here. You are using the term "Named colors", and "Known colors" interchangeably. KnownColors is just a class that returns a list of both the named colors and the system colors. 

Named colors are supported. You could type a color name into the control and it will recognize that color. 

If you do this, it works fine: 

this.ultraColorPicker1.Color = Color.FromKnownColor(KnownColor.Green);

The only thing the new style does not support is System Colors. In the case above, where I am using Green, Color.FromKnownColor returns a System.Drawing.Color object. In your example: 

this.ultraColorPicker1.Color = Color.FromKnownColor(KnownColor.WindowText);

Color.FromKnownColor returns a System color. System Colors are special colors that do not have RGB Values. Instead, DotNet replaces them with the colors defined by the operating system. So if you are providing a user with a list of KnownColors which include the system colors, and the user chooses WindowText - that color will appear differently depending on the Operating system. So if you change your system settings, you will be changing that color.

Since there are no RGB values for System colors, the new style of the ColorPicker doesn't make sense. None of those values would have any meaning, nor would the gradient color palette. I guess, in theory, the color picker could try to interpret the color for the current system stings and use those values for the defaults. That would, at least, allow you to assign a System color to the control instead of it simply reverting to red. But that might not be feasible since the control would have to deal with round-tripping the color, also. I suppose we could look into it. 

Would that be what you want? For the color to be converted from the system color into a normal RGB color that picks up the settings from the current system? 

If that is what you want, you could work around the issue by converting the System color into a regular color: 

            Color color = Color.FromKnownColor(KnownColor.WindowText);
            if (color.IsSystemColor)
                color = Infragistics.Win.Utilities.GetNonSystemColor(color);
            this.ultraColorPicker1.Color = color;