问题
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.
回答1:
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.
来源：https://stackoverflow.com/questions/39299427/uwp-binding-enum-differences