views:

9713

answers:

6

Related to my previous question: http://stackoverflow.com/questions/855519/binding-combobox-selecteditem-in-silverlight

I have a ComboBox bound like so:

<ComboBox x:Name="PART_CommentaryList" 
    HorizontalAlignment="Left" 
    Margin="3" 
    ItemsSource="{Binding Path=CurrentVideo.Commentaries}" 
    SelectedItem="{Binding Path=CurrentCommentary, Mode=TwoWay}">

Both the CurrentVideo and CurrentCommentary property change regularly. After a few times, I get this error:

Category: ManagedRuntimeError       
Message: System.ArgumentException: Value does not fall within the expected
   range.
   at MS.Internal.XcpImports.MethodEx(IntPtr ptr, String name, 
       CValue[] cvData)
   at MS.Internal.XcpImports.MethodPack(IntPtr objectPtr, String methodName, 
       Object[] rawData)
   at MS.Internal.XcpImports.UIElement_TransformToVisual(UIElement element, 
       UIElement visual)
   at System.Windows.UIElement.TransformToVisual(UIElement visual)
   at System.Windows.Controls.Primitives.Selector.IsOnCurrentPage(
       Int32 index, Rect& itemsHostRect, Rect& listBoxItemRect)
   at System.Windows.Controls.Primitives.Selector.ScrollIntoView(
       Int32 index)
   at System.Windows.Controls.Primitives.Selector.SetFocusedItem(
       Int32 index, Boolean scrollIntoView)
   at System.Windows.Controls.ComboBox.PrepareContainerForItemOverride(
       DependencyObject element, Object item)
   at System.Windows.Controls.ItemsControl.UpdateContainerForItem(
       Int32 index)
   at System.Windows.Controls.ItemsControl.RecreateVisualChildren()
   at System.Windows.Controls.ItemsControl.RecreateVisualChildren(
       IntPtr unmanagedObj)

This seems like a ComboBox bug to me. I can verify that CurrentVideo changes before CurrentCommentary, so the selected item should always be an item which is in the list.

Related, I really don't want the Mode=TwoWay, because when the ItemsSource is changed, the SelectedItem is temporarily null, which gets set back in my model, which I don't actually want. But the binding doesn't work at all otherwise (which seems like another bug).

A: 

Are you checking to make sure that the CurrentCommentary is still in the CurrentVideo.Commentaries list, because if it's not, then you'll get this error.

Correl
I injected a converter into both bound properties in order to inspect whether or not the selected item is indeed in the itemssource. The issue seems to be: ItemsSource changes. That change causes SelectedItem to become null. SelectedCommentary changes to null because it's a two way binding. SelectedCommentary is set to the proper value by the app, this value is definitely within ItemsSource. Error happens. If the binding mode is not TwoWay, there is no error, but then the proper item is never selected.
Josh Santangelo
A: 

Combobox is a quite buggy SL control :-(.

In my case I gave up with the selected item declarativa binding and use the nasty coding approach... ugly but works:

http://blogs.msdn.com/mikehillberg/archive/2009/03/26/implementing-selectedvalue-with-the-silverlight-combobox.aspx

HTH Braulio

Braulio
Interesting post, but this doesn't seem really relevant to my problem. I did learn about DisplayMemberPath, though. Previously I'd set a new DataTemplate just to display a property of the item.
Josh Santangelo
A: 

I was getting the same issue a while ago and from what I can tell it's a bug in ComboBox when the ItemSource is changed it has an issue with the layout and scrolls badly.

There is a work around by calling ComboBox.UpdateLayout between setting the ItemSource and SelectedItem.

I blogged about the problem a while ago at Gotcha when databinding a ComboBox in Silverlight.

I've yet to verify whether the problem still exists in the Silverlight 3 Beta

Nigel Sampson
Using UpdateLayout is a good approach, but I gave it a shot and still ended up with the same error. I get it when setting SelectedItem in code or via binding.
Josh Santangelo
In the sample in your blog you are binding to a property where the getter is dynamically creating a new OC<T> on get. This will change the pointer used by the ItemsSource binding every time it is evaluated. A more stable approach would be to declare an OC<T>, and add items to it. Also, by dynamically constructing a OC<T>, there is no point in even using an OC<T> you might as well use a List<T>.
markti
Agreed, in the end I moved to a model like that, however it's still a bug to watch out for when changing item sources.
Nigel Sampson
A: 

Thanks for the suggestions above. In my situation I am able to go for the "nuclear option", which is -- whenever the selected item needs to change, I completely destroy the ComboBox, make a new one, and set its SelectedItem appropriately.

Ridiculous, but it works.

Josh Santangelo
A: 

string testVal = (dpComboBox.SelectedItem as ComboBoxItem).Content.ToString();

+5  A: 

This is a bug in the ComboBox control that has to do with the changing pointer of the ItemsSource's binding. The solution that I have found is to:

1) Always bind the ItemsSource to an observable collection and never reset the pointer of the OC.

<ComboBox ItemsSource="{Binding MyList}" SelectedItem="{Binding MyItem}" />

Bad:

MyList = new ObservableCollection();

Good:

MyList.Clear();
MyList.AddRange(...);

2) Set MyItem = null, before Clearing MyList

In your case you are changing the reference of the List whenever you change CurrentView. Therefore, if SelectedItem is not null, there is a brief moment in time where the ItemsSource is being reset, the internals of the ComboBox are attempting to locate the SelectedItem object in the new ItemsSource but the old object is not there.

markti