Support nested types in DataTemplate.DataType

[FoggyFinder]

Currently TypeResolver goes crazy - raises exception (for 0.8.x version [clarification: only for F# modules that don't have namespace]) and gives error in compile time from the master branch.

Just to show some sample. This kind of code is perfectly valid in WPF:

        <ItemsControl ItemsSource="{Binding Items}">
            <ItemsControl.ItemTemplate>
                <DataTemplate DataType="{x:Type local:SomeClass+Data}">
                    <TextBlock Text="{Binding Value}" />
                </DataTemplate>
            </ItemsControl.ItemTemplate>
        </ItemsControl>

    public partial class MainWindow : Window
    {
        public MainWindow()
        {
            InitializeComponent();
            DataContext = this;
        }

        public IEnumerable<Data> Items { get => Enumerable.Range(0, 10).Select(_ => new Data()); }
    }

    public static class SomeClass
    {
        public class Data
        {
            public string Value { get; } = "Hello World";
        }
    }

While this is a rare use-case for C# in F# world it's common. Instead (or additional to) of using namespace, types are grouped in modules, like this:

module Test = 
    type SomeType = { Id : int; Value : string }

So I think it would be very nice to have support for this scenario.

[FoggyFinder]

Slightly changed code:

  <ItemsControl Items="{Binding Items}">
    <ItemsControl.ItemTemplate>
      <DataTemplate DataType="{x:Type local:SomeClass+Data}">
        <TextBlock Text="{Binding Value}" />
      </DataTemplate>
    </ItemsControl.ItemTemplate>
  </ItemsControl>

is works in 0.8 but doesn't for latest version (0.8.999-cibuild0003188-beta).

[FoggyFinder]

Any updates?

[FoggyFinder]

Any news? :-)

[BAndysc]

+1, it prevents from using CompiledBindings in few places :(

[grokys]

Investigating this now, looks like this works fine in unit tests, which makes it harder to fix...

Update: yep, seems to be our Mono.Cecil backend that's not handling this correctly.

[yankun]

Using 11.0.4 I've auto completion for the + syntax, but getting a compile error that the type can't be found. Still not solved?

[timunie]

@yankun issue is open and milestone is 11.x, so guess, no it's not available yet and doesn't have high priority seems like.

[nuc134r]

I have written a replacement x:Static markup extension which supports nested classes. It uses WPF code. Can be used in the meantime

https://gist.github.com/nuc134r/a28efe6363ac5228df7d12d97af03f8d

Just remove the x: in your code and let autocomplete import it's XAML namespace (wherever you put it) and you're ready to go

Didn't look into x:Type but maybe it can be worked around in the same way

[timunie]

@nuc134r if you have an idea how to properly support this, consider to file a PR instead of relying on a workaround. Community support is appreciated as far as I can tell.

[nuc134r]

@nuc134r if you have an idea how to properly support this, consider to file a PR instead of relying on a workaround. Community support is appreciated as far as I can tell.

It looks like PRs which seem to exactly (and properly) fix the issue are already filed

#7354
kekekeks/XamlX#54

[maxkatz6]

@nuc134r keep in mind, that this workaround will use reflection, and these static members might be trimmed out from the assembly if they are not used compile time.

[Dragorn421]

Just to make sure, is the current state of things in Avalonia that you cannot use a nested class to set DataType explicitly?

[DmitriiShamrikov]

I'm using Avalonia 11.2.3 but this is still not working. Any idea when the fix going to be published?

[timunie]

if 11.2 doesn't have it, please try nightly, In this case should be shipped with 11.3