UWP - binding Enum differences

Question

I have come across a very interesting issue.

Suppose you have the following XAML page content in a UWP app:

<ContentControl Content="{x:Bind ApplicationDataLocalityEnum}" />
<ContentControl Content="{x:Bind FontStyleEnum}" />

And in the code-behind of the page contains the following properties:

    public ApplicationDataLocality ApplicationDataLocalityEnum { get; } =
               ApplicationDataLocality.Local;

    public FontStyle FontStyleEnum { get; } = 
               FontStyle.Normal;

Expected result would be, that the app would display "Local" and "Normal".

Actual result is however the following:

What is the reason behind this? I am very curious about it, but even though I have tried digging into debugger values for a long time, it never revealed anything that could cause this.

You can play around with my sample project on GitHub.

While I can't answer your actual question, if it's causing you a problem and you need a work around then best create a value converter so you can get it to display correctly. Will be very interested to see the real answer though! — mbrdev, Sep 02 '16 at 19:51
Yes, I know ValueConverter works, but I am asking out of curiosity, because I am really unable to figure this out :-D . — Martin Zikmund, Sep 02 '16 at 20:21
I've just been playing around with this and so far i can see it's only happening within a ContentControl. When using a standard TextBlock/TextBox the selected FontStyle is displayed correctly. It may be something to do with the way a ContentControl renders its content, possibly a bug. — mbrdev, Sep 02 '16 at 21:29
But if you try to use a ListView with a ItemTemplate and put a TexBlock inside of it and bind the Text property there - it happens again! I just have bo idea how this can be :-D — Martin Zikmund, Sep 02 '16 at 22:10
Also - if you use type FontStyles and a dot (to get IntelliSense in Visual Studio), you will see that it offers much more methods than other enums, again for unknown reasons. — Martin Zikmund, Sep 02 '16 at 22:15
Please don't use a ValueConverter for something like this. Just create `public string FontStyleString => FontStyleEnum.ToString();` in your code-behind class. — Jerry Nixon, Sep 07 '16 at 21:38
That is the best solution, but I am still struggling to understand why this happens when `ToString()` behaves as expected :-) . — Martin Zikmund, Sep 07 '16 at 21:48

score 3 · Answer 1 · edited Jun 20 '20 at 09:12

Should you look into the source of FontStyle (just hit F12) you will find it is in Windows.Foundation.UniversalApiContract.winmd. This is not a .NET assembly, but a native assembly projected into .NET. MSDN for IReference says:

When programming with .NET, this interface is hidden and developers should use the Nullable class. All Windows Runtime members where the basic IDL signature shows IReference (with a constraint) are instead exposed using the nullable syntax of the nullable value type (for example, ?bool).

So why doesn't it work?

The heart of the answer is, this is not a .NET type and does not behave like a .NET type. Meaning ToString() is not natively implemented as if it is an enum but acts instead like GetType().ToString(), which explains the output you are seeing.

Why don't they make it work?

To correct this on the platform side, the type would need a mechanism to differentiate between numerations, structures and delegates. In the case of structures and delegates, you would expect ToString() to return GetType().ToString() and not a name value; so this generic behavior is the most common choice across the options.

But what makes `FontStyle` different from `ApplicationDataLocality` for example, which according to F12 is also in `Windows.Foundation.UniversalApiContract.winmd`? — Martin Zikmund, Sep 07 '16 at 22:03

UWP - binding Enum differences

1 Answers1

So why doesn't it work?

Why don't they make it work?

Linked