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).

[jevansaks]

Saying I'm "looking at it" is maybe a bit strong. :)

[DarranRowe]

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.

Given that Windows.UI.Color is a structure, this usually ends up with a non trivial conversion. C++ could technically get away with it trivially using reinterpret_cast, but that requires that the memory layout be the same, and it is in the murky depths of implementation defined behaviour. But this really needs a memberwise copy to convert.

[michael-hawker]

With C#14 extension methods coming with .NET 10's release in a couple of weeks, it gives us a lot of flexibility in the .NET space to add helpers like FromArgb in more commonly used places as well (though I don't think this would have helped this specific case with the wrong return type regardless).

I know there's the whole Color/struct revamp proposal going on in .NET land too, I hope. So, that could go far to maybe standardize some ideas and then use said extensions for better interop with Windows.

[Gavin-Williams]

@michael-hawker "Can you let me know why you didn't try clicking on it or thought it was "missing" or "wrong"?"

• Windows.UI is UWP, I'm using WinUI 3. It's a different framework. Do you think if VS recommended I pull in some WPF types I'd do it?

• Top copilot response comparing the frameworks... WinUI is the latest UI framework for Windows applications, offering modern features and flexibility, while UWP is an older platform that is being phased out.

• Top copilot response to the question... can i mix WinUI 3 and UWP in a desktop application? Mixing WinUI 3 and UWP in a desktop application is not directly supported by Microsoft

Further, I have had experiences in the past where I've accidentally used Windows.UI in a WinUI app and I've painted myself into a corner and had trouble debugging the application after running into problems. They should generally not be mixed. And if they should be specifically mixed, then that's on the library vendor, not the user AFAIC.

When I'm using WinUI, I expect to use 'Microsoft.UI.Color', certainly not something from UWP. And if I was in control, I would have the 'Colors' definitions in the Color struct. I don't see the point of having them in their own static type.

You could ask the C# team to provide namespace hijacking, so that it looks like Microsoft.UI.Color to the user.

[DarranRowe]

Windows.UI is UWP, I'm using WinUI 3. It's a different framework. Do you think if VS recommended I pull in some WPF types I'd do it?

That is your fundamental misunderstanding. Windows.UI is Windows Runtime, not just UWP. It is pretty well documented that Windows Runtime functionality is usable from any desktop application with exceptions that are UWP only.

There have been pleanty of functionality that was in the Windows Runtime namespace that was usable in desktop applications right from the start, even back as far as Windows 8. Originally, the DualApiPartition attribute was used for this. One of the earliest examples of this is the Bluetooth LE functionality, BluetoothLEDevice. While the current documentation doesn't show this, it is still in the metadata.

What's more, desktop only functionality is in the Windows Runtime namespaces, under Windows.UI too. Windows.UI.Composition.Desktop.DesktopWindowTarget is a desktop only runtime class, so it just cannot be UWP only. This uses a dekstop window handle to enable composition for a desktop window. It is like DirectComposition, but it has better functionality. Also, look into the DispatcherQueue and the Windows API function, CreateDispatcherQueueController.