We Keep Coding

WPF ComboBox (with IsEditable) - Prevent selected item from being deleted when removed from the list of choices

I have a ComboBox with IsEditable set to true. If I type in a custom option and then reset the list of choices (or even remove all choices), the displayed text does not change. Which is exactly what I want. However if I select or type in an option that is on the list and then later remove that option from the list, the selected text gets reset to null or empty string. In this second instance I'd like the selected text to not change (essentially turn into a custom entry).
I tried using the SourceUpdated and setting Handled to true but the event doesn't trigger whether I try replacing it with a new ObservableCollection or calling Clear.
Additionally manually managing the value is problematic because of delayed events triggering on the control itself in response to the change. If I use the following code the control responds to the updated list (and resets the value) after everything has finished executing.
string holdValue = SelectedListString;
ListOptions.Clear();
SelectedListString = holdValue;
This is a "nice to have" so I'm hoping for a simple solution and can't use 3rd party libraries for it. Worst case I guess I can do some hacky change tracking that then prevents the value from being modified when the setter is called on the dependency property SelectedListString, but I was hoping for something simpler.

You can bind your 'SelectedListString' property with 'Text' property of the 'ComboBox' like this
<ComboBox IsEditable="True"
ItemsSource="{Binding ListOptions}"
SelectedItem="{Binding SelectedListString}"
Text="{Binding SelectedListString}"/>
And when you clear the list, you hold on the value manually like you did
string holdValue = SelectedListString;
ListOptions.Clear();
SelectedListString = holdValue;

WPF - MVVM - C# Cannot set SelectedItem of combobox after ItemsSource changes

I've been struggling with this problem for several days now.
I have a combobox that gets its ItemsSource twice.
The first time i try to see if i have an offline backup of the data that i am trying to show.
While the offline data is showing, the software needs to download the updated data from the database.
Everything works fine if i don't have any stored data in the offline backup.
The problem arises when i have a list of items backed up, i put it in the combobox itemsSource, and then change that list after a couple seconds.
The list actually shows correctly, but the selectedItem (which is something that i get from the viewmodel) gets reset and i can't set it again from code-behind.
The SelectedItem property in the viewModel is actually properly set, but it doesn't get to the UI.
The list is an ObservableCollection of the same type as the selectedItem.
My combobox
<ComboBox ItemsSource="{Binding SomeList, Mode=OneWay}"
SelectedItem="{Binding ListItem, Mode=TwoWay}"
DisplayMemberPath="ItemProperty"
Margin="10,0,0,0" Width="300" VerticalAlignment="Center"/>
The way i set the selectedItem in both the offline and online methods:
SomeList= await _mainRepository.BackEndOfflineFirst_GetList();
if (SomeList.Count > 0)
{
ListItem = SomeList.SingleOrDefault(list=> list.Property.Equals(SomeVariable.Property));
}
Any help is appreciated.
I should mention that adding IsSynchronizedWithCurrentItem="True" to the combobox always makes the selectedItem the first item of the list.
The check for list.property equals another variable.property ALWAYS returns one single element that is guaranteed to be in the list, and is never null.
Forgot to mention (kinda important, my bad), but i'm using Prism and i implement BindableBase, so the properties are defined as follows:
private ObservableCollection<Type> _someList ;
public ObservableCollection<Type> SomeList
{
get { return _someList ; }
set { SetProperty(ref _someList , value); }
}

It is impossible to infer the cause of the problem from your explanations.
Everything is correct in the code examples - the problem is somewhere else.
Just in case, I ask you to clarify: do you raise PropertyChanged in all properties?
One tip (including as a probable cause), use the ReadOnly property for the observable collection:
public ObservableCollection<...> SomeList {get;}
= new ObservableCollection<...>();
SomeList.Clear();
foreach(var item in await _mainRepository.BackEndOfflineFirst_GetList())
SomeList.Add(item);

Found out why it wasn't working.
BindableBase propertyChanged only gets raised when the value actually changes.
I was getting basically the same object (different objects, same value), so it wasn't actually raising the propertyChanged.
To fix this, i put a
ListItem = null;
SomeList.Clear();
inside a finally clause, before actually giving the value i receive from the DB to the ListItem.
It also does not seem to work if i change properties too quickly (hence the finally clause), so i couldn't just put a
SomeList.Clear();
SomeList = await...
back to back.
Another problem i found was that SomeList.Clear() actually throws a NotSupportedException that wasn't actually showing up, hence skipping some of the code.
This was caused by SomeList being an ObservableCollection. Changed it to a generic List and i can Clear it now.
If you need to clear the ObservableCollection, a simple Collection = null; works too.
Thank you to everyone that helped me.

WPF TwoWay Binding and PropertyChanged

So suppose there is an enum
enum SampleEnum
{
Item1,
Item2
}
Then there is a ComboBox
<ComboBox ItemsSource="{Binding SomeItemSource}"
SelectedItem="{Binding
Path=ItemX,
Mode=TwoWay,
UpdateSourceTrigger=PropertyChanged,
Converter={StaticResource ResourceKey=SomeConverter}}">
Combo box has a ViewModel as its DataContext
ViewModel : INotifyPropertyChanged, ...
{
...
public SampleEnum ItemX
{
get => model.GetItemX();
set
{
model.SetItemX(value);
RaisePropertyChanged();
}
}
...
}
And RaisePropertyChanged([CallerMemberName] string caller = "") invokes PropertyChanged with property's name.
But.
When I run my code, open my CheckBox, select one item, I get following behaviour: my code enters setter, sets value of the model, raises PropertyChanged, then my getter is invoked, value is retrieved, but it never reaches ComboBox. ComboBox displays the value I chose by hand, not the value returned by accessor.
E.g. if you rewrite get => SampleEnum.Item2 to return always the same value, ComboBox will still display the value I picked by my hand in UI, not the one that is returned by accessor, even though I am 100% sure that getter is invoked, than the value travels to Converter and Convrter also returns proper value.
But if RaisePropertyChanged(nameof(ItemX)) is invoked from any other place, ComboBox immediately retrieves the value from accessor and displays it.
In short, ComboBox ignores PropertyChanged if invoked from setter, but in any other case it works perfectly fine. Specifying directly the name of property (instead of relying on compiler services) or invoking several RasiePropertyChanged in a row in setter does not work.
In general, one should expect that the value selected in combo box and the one returned by getter are the same, but sometimes model can reject provided value and instead return a default one. Not the best behaviour, but it is possible. And in this case the user will be misinformed which item of a ComboBox is actually selected.
I am just wondering what is so special about this accessor that ComboBox ignores it.

tl;dr: What you're trying to do is data validation. That's a solved problem: You can implement validation in your viewmodel with IDataErrorInfo, or in your view with ValidationRules. Either one of those works with WPF instead of against it. Working against WPF is almost invariably losing proposition.
You could also write an ItemContainerStyle for the ComboBox that disables invalid items, or your viewmodel could update the ComboBox item collection to exclude any items that are currently unselectable. I prefer that approach: Rather than "here, you can choose any of these options -- BZZZT, LOL, WRONG CHOICE!", it seems friendlier to present them only with the options that they can choose.
And if you'll know which options are valid after they make their choice, you can almost certainly know beforehand as well.
ComboBox ignores PropertyChanged if invoked from setter, but in any other case it works perfectly fine.
That's correct. The ComboBox is still handling the change it got from the user, and won't be finished doing so until some time after your setter is complete. The ComboBox will ignore any PropertyChanged events on a property it's currently updating. This is by design.
The standard workaround is to call BeginInvoke() with ApplicationIdle priority, and raise PropertyChanged in the delegate. That will have the effect of raising PropertyChanged again after the ComboBox is entirely finished with the current selection-change event. But that's nothing a viewmodel should ever be concerning itself with.
As you say, "Not the best behaviour". It would be preferable to write validation which rejects the wrong value in the first place, rather than writing a strange workaround like the above.

WPF ComboBox setting to null after ItemsSource updated

I'm having a struggle with a ComboBox in a WPF app. It's similar to some other questions but the classic solution to this problem don't appear to be working.
Essentially, it's the same problem as this:
WPF ComboBox SelectedItem Set to Null on TabControl Switch
However, my ItemsSource is already in the XAML after the SelectedItem, which is what normally sorts this out.
What is happening is that I have the a view with the combobox on it with data already loaded then an event is fired that updates the data feeding into the ComboBox. The ViewModel consumes the event (fired by a BackgroundWorker that gets the data) and updates its ObservableCollection that is the ItemsSource with the new data. Like this:
int id = (int)Invoice.Customer.DatabaseID;
Customers = new ObservableCollection<Customer>(customers);
Invoice.Customer = Customers.FirstOrDefault(x => x.DatabaseID == id);
As you can see it attempts to set the Customer on the Invoice back to what it was originally. This does occur, observed with a break point, however, as soon as this is completed the Customer gets set back to null from an unidentified source (none of my code appears in the call stack, it's all framework stuff).
The XAML for the ComboBox is this:
<ComboBox DisplayMemberPath="AccountCode"
SelectedItem="{Binding Invoice.Customer, Mode=TwoWay, UpdateSourceTrigger=PropertyChanged, ValidatesOnDataErrors=True}"
ItemsSource="{Binding Customers}"/>
So to summarise, my ComboBox SelectedItem gets set to null after the ItemsSource is updated and ensuring ItemsSource is after SelectedItem does nothing. I really can't figure out why it's getting set to null and I'm not sure where to look. Any pointers or things I can look at in order to find a solution to this would be greatly appreciated.
EDIT: Ok, I've been playing with it a bit more and I suspect it has something to do with the update coming from a BackgroundWorker. I use a Timer and a BackgroundWorker in my data service to periodically update the customer list from the database to ensure the data is relatively current. The BackgroundWorker fires an event when it is finished to inform interested objects that the list has been updated. This appears to mean that when the events are consumed they are in a different thread. When it updates this way the SelectedItem gets set to null after I set it to the correct item and therefore sets Invoice.Customer to null. I quickly added a button to my view to update the customers without using the BackgroundWorker and this appears to work every time. I'd like to keep updating the data periodically but I need to figure this out before I can do so.

Ok, as I suspected in my edit this was to do with threading in some fashion. Updating the ComboBox ItemsSource from after the update was kicked off by a Timer was causing it to get set to null after it had been updated to the correct Customer. I confirmed this behaviour in a fresh app that didn't have all the other bits in it and therefore potentially me setting it to null somewhere I wasn't meant to (even though the call stack seemed to heavily suggest that it wasn't me doing it). When the event fired to update the results I got what looked like exactly the same call stack in the fresh app compared to the real app.
After a bit of playing around with different things the method I've come upon (in my fresh app - not deployed it to the real one yet fingers crossed it works there too!) was to have the event fired by a competed update run through a TaskFactory (idea from here Is it wrong to use the Dispatcher within my ViewModel?).
In the ViewModel declare a TaskFactory:
TaskFactory uiFactory;
In your constructor set it up like this:
uiFactory = new TaskFactory(TaskScheduler.FromCurrentSynchronizationContext());
Then in the event that runs after the data has been updated do something like this:
private void AsyncMethods_TaskCompleted(object sender, EventArgs e)
{
uiFactory.StartNew( () => UpdateResults());
}
And UpdateResults in this context is the same as updating the Customer on the Invoice. It gets the old id, sets the ItemsSource to the new collection and then sets the property bound to SelectedItem to the equivalent item in the new collection. This appears to be working and not giving me the odd behavious I was having before. I'm going to deploy it to the actual app and hope it works there too. If it does I'll come back and accept this answer.

Sometimes when you create a 'new' instance of an Object, it can break your bindings. You can update the existing Collection without calling 'new' OR you can make the ObservableCollection a dependency property.

The issue is caused by these 2 lines.
Customers = new ObservableCollection<Customer>(customers);
Invoice.Customer = Customers.FirstOrDefault(x => x.DatabaseID == id);
Your combobox source is Customers and you're initializing it again. Then you're trying to fetch data from a newly initialized member. A newly initialized member will have no data in it.
ie Customers has no data in it. Hence Invoice.Customer will probably be null.
I don't understand why you initialize it and simply try to get data from it. Did you skip to fill the source?
If you missed to fill the source, then fill the source with data first. Then you can run this code without initializing it again so that Invoice.Customer is not null.
Invoice.Customer = Customers.FirstOrDefault(x => x.DatabaseID == id);

DataGrid won't display data after refresh if ObservableCollection is null at startup

Hopefully I can make this clear. I have a DataGrid
<DataGrid Grid.Row="6" Grid.Column="1"
AutoGenerateColumns="False"
CanUserAddRows="False"
CanUserDeleteRows="False"
ItemsSource="{Binding projectEntriesForEmployee}">
bound to an
public ObservableCollection<ProjectEntry> projectEntriesForEmployee {
get { return (ObservableCollection<ProjectEntry>)GetValue(projectEntriesForEmployeeProperty); }
set { SetValue(projectEntriesForEmployeeProperty, value); }
}
public DependencyProperty projectEntriesForEmployeeProperty = DependencyProperty.Register("projectEntriesForEmployee", typeof(ObservableCollection<ProjectEntry>), typeof(MainWindowVC));
If I set projectEntriesForEmployee before I load my UserControl (which I did to debug), my rows show properly in the DataGrid. If however, projectEntriesForEmployee is null when the UserControl loads, when I set projectEntriesForEmployee to a valid ObservableCollection with items in the list (based on an event), no rows show on the DataGrid. What could be going on?
Edit:
I've tried
CollectionViewSource.GetDefaultView(projectEntriesForEmployee).Refresh();
but no joy.

I'm not sure what's going on, but I would try using Snoop to drill into the DataGrid and make sure that, after you update projectEntriesForEmployeeProperty the DataContext of the DataGrid is still set to the appropriate object and to verify the binding on ItemsSource. If there are any binding errors, Snoop will show them and it'll also let you drill into the object and see the full binding expression. Just a suggestion.

When your control loads, both your OC, and your DataGrid's ItemsSource both point to the same thing: a null piece of memory.
Some time later, your initialize your OC to a collection. Now your OC holds a collection, but your DataGrid's ItemSource still points to the same null piece of memory.
Can you not just initialize your OC in your control's constructor?
EDIT
I'm not a WPF guru, so there might be a reason to do this, but why are you setting your ObservableCollection as a dependency property? If all your doing is binding it to your DataGrid's ItemsSource, a regular, vanilla C# property will work fine, and still provide you all of the automatic updates that occur when you add to, or remove from the collection.

Sorry everyone. I've answered my own question, as it turns out that the problem was the Dependency Property Owner Type. I had it as MainWindowVC. It should have been TimeEntryVC. As soon as I changed that, I commented out the resetting the ItemsSource in the Controller class, and everything worked as it should. So #Tim, you're right that the Binding system takes care of things; I just told it to look for the property in the wrong class. Thanks all regardless, as I understand better what's going on behind the scenes now than I did before.