ColorHelper.ToDisplayName still appears to be missing since before 1.0?

[michael-hawker]

@bpulliam ToDisplayName still appear to be missing in the latest release, this never seemed resolved here on how we're supposed to upgrade these code paths. Also see: MicrosoftDocs/winrt-api#2120

This effects our ColorToDisplayNameConverter in the toolkit, so not sure what to do with our comment here:

        // return global::Microsoft.UI.Xaml.ColorDisplayNameHelper.ToDisplayName(color);
        // Removed on Reunion 0.8-RC. Not sure what to replace with.

Originally posted by @michael-hawker in #5260 (comment)

Someone mentioned using the original Windows.UI one, but that doesn't seem to work either.

I get red squiggles trying to use the Windows.UI version explicitly Windows.UI.ColorHelper.ToDisplayName(color):

[DarranRowe]

@michael-hawker
I know it is a silly question, but for C#, wouldn't Color.ToString be how you would do this?
The documentation for ColorHelper itself does state that you should be using members on the Color class due to how C# wraps it.

[jaigak]

@DarranRowe Color.ToString returns the hex representation of the colour, not the display name.

From the docs:

For C# and Microsoft Visual Basic, the language support for the Color structure provides a behavior for ToString that serializes the values of the ARGB data properties into a single string. The string representations of Color values are similar to XAML attribute string syntax for specifying Color values in markup. It is the syntax that is most commonly used by designer tools to specify a (non-named) Color. The string is in the form #AARRGGBB, where each letter pair represents one of the color channels as a value between 00 and FF. Each letter pair is interpreted as if it were a hex value and thus represents a value between 0 and 255. The string always starts with a hash (#). For example, the string form of the color where A=255, R=0, G=128, B=255 is "#FF0080FF". For named colors you get the serialized string and not the constant name; for example calling ToString on Colors.Blue gives "#FF0000FF".

[DarranRowe]

Hmm, well, I have to admit that I'm not exactly that familiar with the C# projection.
Since I am more knowledgeable of the C++ projection, I was messing around with this a little. Interestingly, ToDisplayName seems to just outright crash. Digging into the disassembly a little, this seems to call into Windows.UI.Xaml.dll, and for some reason, at least on Windows 11 22H2, DirectUI::DXamlCore::GetLocalizedResourceString tries to access a null pointer.
So part of me is saying that there is also currently a bug in Windows that would get in the way.

[jaigak]

@DarranRowe Are you running as packaged or unpackaged. Maybe this has to do with it using old MRT (Windows.ApplicationModel.Resources) instead of MRT Core from Windows App SDK (Microsoft.Windows.ApplicationModel.Resources). Or maybe it's dependent on the UWP XAML framework to be initialized, even though the ColorHelper class itself is not under the Windows.UI.Xaml namespace.

[DarranRowe]

@JaiganeshKumaran
I tried both packaged and unpackaged, it had the same behaviour. I also tried it in a plain Windows API application, so that completely ruled out any Windows App SDK interference.
But since Windows Runtime APIs not supported in desktop apps doesn't give any indicator that it shouldn't work, I am inclined to go with bug.

[jaigak]

@DarranRowe Probably the UWP XAML framework needs to be initialised first then.

[DarranRowe]

@JaiganeshKumaran By the looks of it. I dug in a little more and it was getting a null pointer from a TLS slot. I then had the brilliant idea to initialise Xaml Islands for the UI thread and it worked.
But as I stated the documentation doesn't give any indicator that it shouldn't work. The ToDisplayName documentation also doesn't state that UWP Xaml needs to be initialised in order for it to work. If it does require Xaml to be initialised then it needs to be documented. If the intention is to not require it to be initialised then this issue needs to be fixed.

[michael-hawker]

I think this function just needs to be ported/exposed to the new Microsoft.UI.ColorHelper version of the class that does exist in WASDK/WinUI 3?

[Arlodotexe]

This was added in Wasdk 1.6 preview1 https://learn.microsoft.com/en-us/windows/apps/windows-app-sdk/preview-channel#other-notable-changes

[duncanmacmichael]

Fixed in 1.6.0; closing issue.