When you change the SelectedItem in the editor it sets the bound property multiple times.
It sets it to null and then it sets it to the value that was selected.
If an item is selected and the user sets focus on the control and then tabs out of the control without changing the item then the bound property is set to null and then to the item displayed.
This behaviour is creating a problem for me because I can't ignore null values. If I put a test for the value being null and ignore it, it is all ok, but unfotunately I need to perform certain actions if the user clears the selected item (sets to null).
This means I have no way of knowing whether the item was set to null due to the control behaviour or was actually set to null by the user.
I would consider this a bug.
I would have thought that if the user hasn't changed the selected item then the binding of SelectedItem should not be update either.
When the user changes the value from one item to another I woudl have thought there would be one binding update from the old value to the new. Not from the old value to null then to the new.
The standard silverlight combobox does not behave in ths manner. The SelectedItem only gets set when it actually changes
Even when I turn AllowFiltering and IsEditible off so that it is like a standard combobox it still sets it to null and then to the item the user selected.
This is definitely a bug.
This is a show stopper for me at the moment
Ok thanks. In my solution I have DisplayMemberPath set but I need IsEditable to be true so that I can autocomplete/filter the items.
Thanks for looking into this so quickly.
Hi,
if you have DisplayMemberPath set and IsEditable=true and you still encounter this issue you could try to install the latest service release of 10.3 in order to get the fix that was made to the similar issue I've mention. Basically if you don't have a build including that fix the workaround i suggested might not be working.
In order to get the SR(patch) for 10.3 you need to contact the out Developer support team and request the patch. If you want just to test if the workaroud works you could download the 11.1 release and test with it - the fix should be included in it.
HTH
I have verified that this has been fixed in the 11.1 release. I will find out what license details the company I am consulting for has and see if they have access to the latest version. If they don't then I will contact the support team for the patch to 10.3.
Thank you for your quick resolution of this issue.
Looks like this is not fixed in 11.1 version. I am using the latest version (11.1). I am binding the list of strings to the comboeditor box and IsEditable= true. Do i have to set displaymemberpath?
binding to collections of strings(simple types i.e. int, double, etc.) is not supported. Could you try if this behavior is reproducible when binding to a collection of complex type?
Regards,