This bug https://bugzilla.xamarin.com/show_bug.cgi?id=57912 was not moved to GitHub.
My ViewModel is bound to a Xamarin Forms picker. When my Model updates the ViewModel with a new ItemSource and SelectedItem, the ItemSource is correctly set and the SelectedItem is set initially, and then there is an erroneous call setting the SelectedItem to null. Switching the order of the XAML did not fix this issue. My ItemSource is a List of type string.
This occurs on WPF and Android emulator. I did not check on IOS
picker binding:
<Picker x:Name="ItemPickList"
BindingContext="{Binding Path=TestViewModel}"
ItemsSource="{Binding DisplayStrings}"
SelectedItem="{Binding SelectedItem}"/>
Example:
Picker Bound to VM with Data Item 1
ItemSource = "a", "b", "c" SelectedItem = "a"
switch Picker Binding to Data Item 2
ItemSouce = "red", "orange", "yellow" SelectedItem ="yellow"
switch Picker Binding back to Data Item 1
EXPECTED: ItemSource = "a", "b", "c" SelectedItem = "a"
ACTUAL: ItemSource = "a", "b", "c" SelectedItem = null
The Model's SelectedItem will update the Picker's SelectedItem after switching ItemSource. Switching one picker between multiple ItemSources will not clear corresponding ItemSources SelectedValue.
The SelectedItem in the Model is cleared upon switch back to a previous Model(item source)
In the screenshot you can see in the emulator the selected item (first dropdown) is empty. In the Debug window you can see the new SelectedItem bound to the Picker is null. The SelectedItem of the Data is set to "b". If you look at the code, the only place where the ViewModel's SelectedItem is set is in the DataItem which is loaded before the ViewModel in the constructor, but the ViewModel's SelectedItem is still set to null.
Repository:
https://github.com/rachelmoor/XamarinFormsPickerBug/tree/master/TestPickerBug
zip file:
TestPickerBug.zip
@samhouts @rmarinho Why was this removed?
Its already in the enhancements board :)
I'm sorry but I'm having issues finding it! Would you mind linking it?
Its awaiting triage in the board :)
Hello,
Would anyone be able to give an update on when this will be fixed? It is quite a critical issue for us and I would appreciate any detail on when the fix will be available.
Thanks
@josesimas I have fixed this issue along with numerous others with the Picker, I just havent had time to cleanup the code and make a PR. After we get out our release I will make a PR.
Thanks Brad, looking forward to it.
Is this one still planning to be worked on? Just hit the issue myself thinking i had done something wrong, but reading this I realise i'm hitting the same bug.
I think I've got the same, or a similar issue, although I never change the ItemsSource
(array of type InternalInspector[]
) after setting it in my view model's constructor. I've got a property SelectedInspector
(of type InternalInspector
) on my view model which is bound to the SelectedItem
field of the picker.
In the constructor I set the SelectedInspector
property to one of the InternalInspector
s from the same property that the picker uses for its ItemsSource
. Yet the picker is blank, any attempt to select a different option from the picker appears to have no effect - the picker is still blank.
When I put a break point in the setter of my SelectedInspector
property I see that every time I pick an option in the picker it first sets the SelectedInspector
to the selected InternalInspector
object (as expected) but then immediately after is sets the SelectedInspector
to _null_ :(
I believe that's the same behaviour as described in this issue.
I'm using Xamarin Forms 3.6.0.293080 and have experienced the issue on both iOS 12.2 and Android 8.
My issue may actually be #2032 or #2751 but I'll leave it here for now.
Are there any workarounds? Besides not using a picker...?
I am running into the same issue. I know the root cause. Not sure if's because of bad code on my side not following the standards.
WHEN you reset the Itemsource. The pickers goes through a process of resetting it self. I see this on the call stack.
I see on the call stack a call function Xamarin.Forms.Picker.ResetItems , which triggers it to set the SelectedItem == null. But this happens AFTER I set the source AND the I SET the SelectedItemPropery. It Looks like it is going out of sequence.
I am having the same problem as @greektreat. I change the ItemsSource and update SelectedItem to a valid value, but it later gets reset to null. Is there at least a workaround for this? I am surprised by how long this issue has been open.
I personnaly found a workaround, ItemsSource must be set BEFORE SelectedItem in order to work properly
@Nico04 Thanks for the suggestion. As far as I can tell, I am doing that both in the view model and in the XAML, but the problem persists.
Yeah most of these workarounds don't work, the value still gets set to null. I ended up setting SelectedItem in OnBindingContextChanged in the meantime.
@kwacks @kmcclive try using the picker mentioned here:
This solved the problem for me!
@rachelmoor Thanks for the suggestion. I'll give that a try!
@rachelmoor it works for me, thanks!
In my case the Picker control works OK in iOS but in Android I get the SelectedItem null.
This issue doesn't seem to have had any activity in a long time. We're working on prioritizing issues and resolving them as quickly as we can. To help us get through the list, we would appreciate an update from you to let us know if this is still affecting you on the latest version of Xamarin.Forms, since it's possible that we may have resolved this as part of another related or duplicate issue. If we don't see any new activity on this issue in the next 30 days, we'll evaluate whether this issue should be closed. Thank you!
I'm still seeing some similar behavior, but don't know what is expected. If SelectedItem is set and I change the ItemsSource to a collection that still contains the SelectedItem, SelectedItem is then set to null. Is this expected? Do I need to explicitly set SelectedItem whenever I change the ItemsSource?
Most helpful comment
Hello,
Would anyone be able to give an update on when this will be fixed? It is quite a critical issue for us and I would appreciate any detail on when the fix will be available.
Thanks