Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ColorConverter in System.ComponentModel.TypeConverters does not handle SystemColors #34252

Closed
DustinCampbell opened this Issue Dec 26, 2018 · 7 comments

Comments

Projects
None yet
6 participants
@DustinCampbell
Copy link
Member

commented Dec 26, 2018

It is not possible to set the BackColor and ForeColor properties of a control to a named value from SystemColors using a PropertyGrid. This is due to the fact that the ColorConverter in .NET Core 3 does not support SystemColors.

There are two versions of ColorConverter in corefx:

The first version does not support SystemColors. Unfortunately, that is also the version that is used for properties of type System.Drawing.Color in property descriptors (link), which is why this causes the PropertyGrid to fail.

Update

Proposal:

Move SystemColors into System.Drawing.Primitives to be part of .NET Core 3.0 inbox and add these colors into ColorTable so that Color.FromName resolves them.

SystemColors lives in System.Drawing.Common and not in System.Drawing.Primitives -- in order to achieve this we need to move the SystemColors type down to System.Drawing.Primitives. The reason why we need to do that instead of just adding a reference to System.Drawing.Common, it is because System.Drawing.Common is an OOB package(it is not part of the shared framework) and System.Drawing.Primitives is part of the shared framework. So it is not allowed to have something that is part of the shared framework (INBOX) take a dependency on something that is not (OOB).

We need to discuss if we're OK with SystemColors being added into .NET Core 3.0 inbox and potentially into .NET Standard 2.1.

This is needed for Winforms. Some previous discussion when we brought these types and we intentionally kept them out from .NET Standard 2.0:
dotnet/standard#240
#33520

cc @Tanya-Solyanik

@danmosemsft

This comment has been minimized.

Copy link
Member

commented Dec 27, 2018

Does this fix it #33520

@DustinCampbell

This comment has been minimized.

Copy link
Member Author

commented Jan 3, 2019

It should, yes.

@danmosemsft

This comment has been minimized.

Copy link
Member

commented Jan 3, 2019

Hopefully the contributor is able to complete that PR .

@DustinCampbell

This comment has been minimized.

Copy link
Member Author

commented Jan 30, 2019

Yes, hopefully, since this blocks a key feature of the WinForms Designer working. 😄

@karelz karelz added this to the 3.0 milestone Mar 15, 2019

@karelz

This comment has been minimized.

Copy link
Member

commented Mar 15, 2019

The PR is in Drawing, so aligning area - @safern do we want to use this issue to tracke the API review?

@terrajobst

This comment has been minimized.

Copy link
Member

commented Mar 15, 2019

Using this issue sounds good me.

Besides the API, I'd love to know what the behavior for SystemColors (and by extension FromName) will be when run on non-Windows computers. Do the properties throw? Do they return a fixed color?

@safern

This comment has been minimized.

Copy link
Member

commented Mar 18, 2019

Besides the API, I'd love to know what the behavior for SystemColors (and by extension FromName) will be when run on non-Windows computers. Do the properties throw? Do they return a fixed color?

They will actually work the same as it works now using System.Drawing.Common package, which returns a Color object with the following properties:

A [byte]:255
B [byte]:180
G [byte]:180
IsEmpty [bool]:false
IsKnownColor [bool]:true
IsNamedColor [bool]:true
IsSystemColor [bool]:true
Name [string]:"ActiveBorder"
R [byte]:180

Right now FromName returns an empty color, because SystemColors are not part of the ColorTable which after adding them into, should return the same as if you do now SystemColors.ActiveBorder.

What we could do is, for non-Windows return false on IsSystemColor but that would be odd, to do SystemColors.ActiveBorder.IsSystemColor and get a false value, when you're accessing it through a SystemColors class.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.