How to make Custom Types XAML-Friendly?

[fitdev]

Considering a simple custom type like for example:

public record struct IntRange(int From, int To) { }

What attributes does this type need to have or what interfaces should it implement, so that in XAML I can simply just write:

<myxmlns:MyCustomControl IntRangeProperty="(100, 500)" />

Where (100, 500) is the syntax understood by my IntRange custom type.

EDIT: Looking for a solution in the context of compiled bindings.

[maxkatz6]

You need to implement TypeConverter. Or, you can add Parse method to your struct.

[fitdev]

Thank you for your suggestion! I should have clarified that I was looking for a solution in the context of compiled bindings. In other words, XAML compiler should know either how to convert a string to my custom type at compile time, or pass the string at runtime to my type's Parse method or type converter, however this second option is less desirable due to performance impact.

So, do any of the two approaches you suggested work with compiled bindings, so that XAML compiler won't complain?

[stevemonaco]

IntRangeProperty="(100, 500)" is a compile-time literal. There are no bindings here. The type is a mutable struct which doesn't support INPC anyways so there probably isn't a point even if you did want individual values. You'd have to show an example of what you're trying to accomplish with bindings here.

For things like this, I make a fully observable type or fully immutable so the entire instance is replaced at once. I'm not sure you can do the former as a struct.

I also tend to not use aggregate types for control properties.

[maxkatz6]

If you want string to be parsed and set completely compile-time, then it's not possible and probably won't be.
At best we can support built-in types (like, Avalonia.Point or StreamGeometry) to be parsed compile time, but supporting arbitrary types is out of the scope of XAML compiler.

[fitdev]

@stevemonaco It was just an example. Most of the custom types would be small readonly structs. Aggregate types can save quite a lot of boiler plate and most UI frameworks including Avalonia have a handful of them like Rect for Bounds for example. I was simply looking for a way to make Avalonia's XAML Compiler understand my types "natively" so that it would generate MSIL that directly calls my type's constructor or factory method with the arguments it took from XAML as strings.

[fitdev]

@maxkatz6
Thank you for the explanation. Yes, that's actually exactly what I was hoping for. Pity it is not on the horizon, as I heavily use small domain specific structs like Ranges and other types to be able to reduce a lot of boiler plate code.
I ended up going with your Parse method suggestion and it worked just fine, except of course parsing happens during run-time.
I am wondering if and how serious of a bad practice it would be to use this approach. I mean there is obviously an extra cost of doing all this parsing at runtime. But is it happening just once per xaml-containing view? Or is it happening every time such a view / user control is requested?
I think it would be nice to somehow provide an extension to the Xaml compiler so you can opt-in some of your own types to be compiled just as Avalonia's built-in types.