Setting ItemsSource from ListBox Derived Catastrophic Crash

Question

I am developing for Windows 8 WinRT. The following code example throws an exception:

Catastrophic failure (Exception from HRESULT: 0x8000FFFF (E_UNEXPECTED))

Is this another mistake in the current WinRT environment (I use VS11 and Consumer Preview)? Does anyone know how to solve this problem?

Btw: I tested the same code with Windows Phone 7.5 Silverlight and it works without problems ...

Thanks for your help.

 public class MyListBox : ListBox { } public sealed partial class BlankPage : Page { public BlankPage() { this.InitializeComponent(); } protected override void OnNavigatedTo(NavigationEventArgs e) { var box1 = new ListBox(); box1.ItemsSource = new List<Object> { new Object() }; // works without problems Content = box1; var box2 = new MyListBox(); box2.ItemsSource = new List<Object> { new Object() }; // throws exception Content = box2; } } 

Answer 1

I ran into a similar problem when subclassing ListView. In my case, the following approach partially helped: I stopped trying to set the ItemsSource of my ListView directly in the code behind, but instead I created a CollectionViewSource in XAML, for example:

 <UserControl.Resources> <CollectionViewSource x:Name="myCollectionViewSource"/> </UserControl.Resources> ... ... <ListView ... ItemsSource="{Binding Source={StaticResource myCollectionViewSource}}" /> 

And in the code behind, I set

 this.myCollectionViewSource.Source = new List<Object> { new Object() }; // The real data source respectively 

However, this only puts off the problem. At least in my case. In my real-life example, I use the ObservableVector as a data source. And as soon as any change to the ObservableVector collection is done (e.g. Clear), I also crash (0x8000FFFF). As soon as I use the original ListView (and not my subclass version), everything works fine again - exactly the same as in your case. Therefore, my answer cannot be understood as a solution to the problem, but perhaps this is a hint that is worth a try. In my case, the original assignment works fine, problems occur first after the observed collection tries to update. I experimented with an ObservableCollection (should work in CP, this is not in DP), but there I ran into other problems. It would be interesting to hear if you were able to advance along this path ...