Color class is missing from WindowsUI

[Gavin-Williams]

Describe the bug

We are meant to be able to use the Color class...

Color.FromArgb(...)

But Color class is not available in WindowsUI. The only options I have are...
System.Drawing
ABI.Windows.UI
Windows.UI

We only have access to Colors static color definitions.

Why is this important?

This is important because my audience expects to see colors other than the predefined colors.

Steps to reproduce the bug

Type Color, right click to bring in the reference. No option is available.

[ghost1372]

Be Smart, Use
Microsoft.UI.ColorHelper.FromArgb

or

Windows.UI.Color myColor = Windows.UI.Color.FromArgb(255, 128, 64, 0);

[ghost1372]

also i can see your method return Microsoft.UI.Colors, but you are trying to return a Windows.UI.Color

[Gavin-Williams]

That doesn't really matter at this point, because the API is missing. That was really just to show that I can see Colors but not Color.

But thanks for pointing out the workaround.

[michael-hawker]

@Gavin-Williams as you pointed out yourself in the provided options in VS is to include Windows.UI. That's the namespace you should use, as ghost also pointed out for you. Can you let me know why you didn't try clicking on it or thought it was "missing" or "wrong"?

Your function should be:

using Microsoft.UI.Xaml;

namespace WinUITestApp2;

public sealed partial class MainWindow : Window
{
    private Windows.UI.Color GetColor()
    {
        return Windows.UI.Color.FromArgb(255, 0, 0, 0);
    }
    ...

Which of course can be simplified by including the namespace:

using Microsoft.UI.Xaml;
using Windows.UI;

namespace WinUITestApp2;

public sealed partial class MainWindow : Window
{
    private Color GetColor()
    {
        return Color.FromArgb(255, 0, 0, 0);
    }
    ...

However, in your screenshot you're trying to return a Microsoft.UI.Colors which never makes sense to return, as all the Colors within that class still return a Windows.UI.Color instance. That error message points you in the right direction that the return type is mismatched:

Same also when you include the Windows.UI namespace to have the proper access to the Color class:

Which given your original code is the provided suggestion in VS which would lead you down this path if you had actually tried to include the missing Windows.UI namespace:

I believe the suggested namespace list from VS is just alphabetical.

@Gavin-Williams can you let me know that this makes sense and if you had different expectations? What would have helped lead you down the right path?

FYI @jevansaks, as I don't know what more we could expect from the compiler or VS to help in this type of scenario. So, curious about your thoughts on the above.

[jevansaks]

Maybe C#/WinRT can generate some implicit conversions into the Color class so that you can use other Color types without getting into too much trouble? There's a lot that intellisense could do better as well, maybe it's worth a conversation with the VS folks on how we can offer some better fixers for problems like this? CsWin32 has similar discoverability problems I'm dealing with that I'd like to figure out how to solve.

[michael-hawker]

Thanks @jevansaks for the input. Glad to know it's not the only area and you're already looking at improvements. Is there a VS Community item or something else tracking that we can link to?

I was talking to @marcelwgn about this more a bit offline too.

We use the underlying Windows.UI type from the system still. We could duplicate it, but then if there's probably system APIs that return a Color (or could in the future) but if we duplicated it we'd still have a weird type conversion boundary still somewhere; so it just moves the problem elsewhere.

Microsoft.UI.Colors does exist so that we can add new Colors and such in the lifted library, but it still returns the correct type (which leads towards the happy path correctly about the mismatch in return vs. signature of the method itself). Ultimately at some point you'd need to click and try options to include the right missing namespace though. But maybe VS could be smarter in these suggestions by knowing what type of project you're working on and which suggestions are most likely to be the right ones you actually want (like the ABI one is never the right choice, it'd be great if those just were hidden).