Software Development

#20: Post edited by

elgonzo‭ · 2022-03-29T09:29:16Z (about 2 years ago)

Copy Link

Raw

Markdown

`List<T>` is not observable. In other words, `List<T>` does not offer a mechanism through which it could signal that its content has changed.
If it is possible/permissible to modify the _Demo_ class, then use [`ObservableCollection<T>`](https://docs.microsoft.com/en-us/dotnet/api/system.collections.objectmodel.observablecollection-1), [`BindingList<T>`](https://docs.microsoft.com/en-us/dotnet/api/system.componentmodel.bindinglist-1) or something similar instead. As their type names suggests, using one of them instead of List<T> will allow ListBox to listen to change notifications provided by these collections. This basically allows the ListBox to _automatically_ update whenever items are added to, removed from or replaced in one of these collection types.
While Alexei's answer will work for simple cases, note that replacing the List<T> instance and raising a respective property change event will trigger processing of **all** list items by any UI element the list or a list item is bound to. Depending on the complexity of the GUI (binding relationships, templates, etc...), specifically the work required to arrange and draw the representation(s) of an item in the UI, this approach might possibly have a noticeable performance impact when the list contains more than a few dozen items.
Using `ObservableCollection<T>` or `BindingList<T>` will **not** require raising the property change event. It will normally also not suffer from the same potential performance impact, since the ObservableCollection<T> / BindingList<T> typically tells _which_ items have been added to, removed from or replaced in it, thus the ListBox (and other related UI elements) is able to limit its layout and drawing work to the specific list items that have been added/removed/replaced.
Since the _Value_ property of the _Demo_ class is also participating in data binding while its value can change, property change notifications should be implemented for this property as well. For example by making the _Demo_ class an _Observable_ and implement the getter/setter of the _Value_ property accordingly; as i did in my Demo class example here:
```C#
public class Demo : Observable
{
public int Value
{
get => _value;
set => SetProperty(ref _value, value);
}
private int _value;
~~public ObservableCollection<int> AllValues { get; set; } = new ObservableCollection<int> { 1, 2 };~~
}
```
Finally, the _DoIncrement()_ method could get rid of the (now pointless) OnPropertyChanged notification:
```C
private void DoIncrement()
{
_demo.Value++;
_demo.AllValues.Add(_demo.Value);
}
```
If however an alteration of the _Demo_ class is not possible, but creating a new _Demo_ instance in the view model is okay, then instead of making a copy of the list (relatively expensive when the list becomes larger) i would perhaps rather opt for making a copy of the _Demo_ instance (remains relatively cheap regardless of list size):
```C#
private void DoIncrement()
{
var updatedValue = Demo.Value + 1;
var updatedList = Demo.AllValues;
updatedList.Add(updatedValue);
Demo = new Demo
{
Value = updatedValue,
AllValues = updatedList
};
// the setter of the Demo property should take care of
// property change notifications, so no OnPropertyChanged here...
}
```
The possible performance implications i mentioned above still apply to this approach, though, so choose your "poison" well...

`List<T>` is not observable. In other words, `List<T>` does not offer a mechanism through which it could signal that its content has changed.
If it is possible/permissible to modify the _Demo_ class, then use [`ObservableCollection<T>`](https://docs.microsoft.com/en-us/dotnet/api/system.collections.objectmodel.observablecollection-1), [`BindingList<T>`](https://docs.microsoft.com/en-us/dotnet/api/system.componentmodel.bindinglist-1) or something similar instead. As their type names suggests, using one of them instead of List<T> will allow ListBox to listen to change notifications provided by these collections. This basically allows the ListBox to _automatically_ update whenever items are added to, removed from or replaced in one of these collection types.
While Alexei's answer will work for simple cases, note that replacing the List<T> instance and raising a respective property change event will trigger processing of **all** list items by any UI element the list or a list item is bound to. Depending on the complexity of the GUI (binding relationships, templates, etc...), specifically the work required to arrange and draw the representation(s) of an item in the UI, this approach might possibly have a noticeable performance impact when the list contains more than a few dozen items.
Using `ObservableCollection<T>` or `BindingList<T>` will **not** require raising the property change event. It will normally also not suffer from the same potential performance impact, since the ObservableCollection<T> / BindingList<T> typically tells _which_ items have been added to, removed from or replaced in it, thus the ListBox (and other related UI elements) is able to limit its layout and drawing work to the specific list items that have been added/removed/replaced.
Since the _Value_ property of the _Demo_ class is also participating in data binding while its value can change, property change notifications should be implemented for this property as well. For example by making the _Demo_ class an _Observable_ and implement the getter/setter of the _Value_ property accordingly; as i did in my Demo class example here (and i did it for the _AllValues_ property too, because it also has a setter):
```C#
public class Demo : Observable
{
public int Value
{
get => _value;
set => SetProperty(ref _value, value);
}
private int _value;
public ObservableCollection<int> AllValues
{
get => _allValues;
set => SetProperty(ref _allValues, value);
}
private ObservableCollection<int> _allValues = new ObservableCollection<int> { 1, 2 };
}
```
Finally, the _DoIncrement()_ method could get rid of the (now pointless) OnPropertyChanged notification:
```C
private void DoIncrement()
{
_demo.Value++;
_demo.AllValues.Add(_demo.Value);
}
```
If however an alteration of the _Demo_ class is not possible, but creating a new _Demo_ instance in the view model is okay, then instead of making a copy of the list (relatively expensive when the list becomes larger) i would perhaps rather opt for making a copy of the _Demo_ instance (remains relatively cheap regardless of list size):
```C#
private void DoIncrement()
{
var updatedValue = Demo.Value + 1;
var updatedList = Demo.AllValues;
updatedList.Add(updatedValue);
Demo = new Demo
{
Value = updatedValue,
AllValues = updatedList
};
// the setter of the Demo property should take care of
// property change notifications, so no OnPropertyChanged here...
}
```
The possible performance implications i mentioned above still apply to this approach, though, so choose your "poison" well...

#19: Post edited by

elgonzo‭ · 2022-03-29T09:26:29Z (about 2 years ago)

Copy Link

Raw

Markdown

`List<T>` is not observable. In other words, `List<T>` does not offer a mechanism through which it could signal that its content has changed.
If it is possible/permissible to modify the _Demo_ class, then use [`ObservableCollection<T>`](https://docs.microsoft.com/en-us/dotnet/api/system.collections.objectmodel.observablecollection-1), [`BindingList<T>`](https://docs.microsoft.com/en-us/dotnet/api/system.componentmodel.bindinglist-1) or something similar instead. As their type names suggests, using one of them instead of List<T> will allow ListBox to listen to change notifications provided by these collections. This basically allows the ListBox to _automatically_ update whenever items are added to, removed from or replaced in one of these collection types.
While Alexei's answer will work for simple cases, note that replacing the List<T> instance and raising a respective property change event will trigger processing of **all** list items by any UI element the list or a list item is bound to. Depending on the complexity of the GUI (binding relationships, templates, etc...), specifically the work required to arrange and draw the representation(s) of an item in the UI, this approach might possibly have a noticeable performance impact when the list contains more than a few dozen items.
Using `ObservableCollection<T>` or `BindingList<T>` will **not** require raising the property change event. It will normally also not suffer from the same potential performance impact, since the ObservableCollection<T> / BindingList<T> typically tells _which_ items have been added to, removed from or replaced in it, thus the ListBox (and other related UI elements) is able to limit its layout and drawing work to the specific list items that have been added/removed/replaced.
Basically, the Demo class could perhaps look like this:
```C#
public class Demo : Observable
{
public int Value
{
get => _value;
set => SetProperty(ref _value, value);
}
private int _value;
public ObservableCollection<int> AllValues { get; set; } = new ObservableCollection<int> { 1, 2 };
}
```
Since the _Value_ property is also participating in data binding while its value can change, property change notifications should be implemented for this property as well. (For example by making the Demo class an Observable and implement the getter/setter of the _Value_ property accordingly; as i did in my Demo class example here.)
Finally, the _DoIncrement()_ method could get rid of the (now pointless) OnPropertyChanged notification:
```C
private void DoIncrement()
{
_demo.Value++;
_demo.AllValues.Add(_demo.Value);
}
```
If however an alteration of the _Demo_ class is not possible, but creating a new _Demo_ instance in the view model is okay, then instead of making a copy of the list (relatively expensive when the list becomes larger) i would perhaps rather opt for making a copy of the _Demo_ instance (remains relatively cheap regardless of list size):
```C#
private void DoIncrement()
{
var updatedValue = Demo.Value + 1;
var updatedList = Demo.AllValues;
updatedList.Add(updatedValue);
Demo = new Demo
{
Value = updatedValue,
AllValues = updatedList
};
// the setter of the Demo property should take care of
// property change notifications, so no OnPropertyChanged here...
}
```
The possible performance implications i mentioned above still apply to this approach, though, so choose your "poison" well...

`List<T>` is not observable. In other words, `List<T>` does not offer a mechanism through which it could signal that its content has changed.
If it is possible/permissible to modify the _Demo_ class, then use [`ObservableCollection<T>`](https://docs.microsoft.com/en-us/dotnet/api/system.collections.objectmodel.observablecollection-1), [`BindingList<T>`](https://docs.microsoft.com/en-us/dotnet/api/system.componentmodel.bindinglist-1) or something similar instead. As their type names suggests, using one of them instead of List<T> will allow ListBox to listen to change notifications provided by these collections. This basically allows the ListBox to _automatically_ update whenever items are added to, removed from or replaced in one of these collection types.
While Alexei's answer will work for simple cases, note that replacing the List<T> instance and raising a respective property change event will trigger processing of **all** list items by any UI element the list or a list item is bound to. Depending on the complexity of the GUI (binding relationships, templates, etc...), specifically the work required to arrange and draw the representation(s) of an item in the UI, this approach might possibly have a noticeable performance impact when the list contains more than a few dozen items.
Using `ObservableCollection<T>` or `BindingList<T>` will **not** require raising the property change event. It will normally also not suffer from the same potential performance impact, since the ObservableCollection<T> / BindingList<T> typically tells _which_ items have been added to, removed from or replaced in it, thus the ListBox (and other related UI elements) is able to limit its layout and drawing work to the specific list items that have been added/removed/replaced.
Since the _Value_ property of the _Demo_ class is also participating in data binding while its value can change, property change notifications should be implemented for this property as well. For example by making the _Demo_ class an _Observable_ and implement the getter/setter of the _Value_ property accordingly; as i did in my Demo class example here:
```C#
public class Demo : Observable
{
public int Value
{
get => _value;
set => SetProperty(ref _value, value);
}
private int _value;
public ObservableCollection<int> AllValues { get; set; } = new ObservableCollection<int> { 1, 2 };
}
```
Finally, the _DoIncrement()_ method could get rid of the (now pointless) OnPropertyChanged notification:
```C
private void DoIncrement()
{
_demo.Value++;
_demo.AllValues.Add(_demo.Value);
}
```
If however an alteration of the _Demo_ class is not possible, but creating a new _Demo_ instance in the view model is okay, then instead of making a copy of the list (relatively expensive when the list becomes larger) i would perhaps rather opt for making a copy of the _Demo_ instance (remains relatively cheap regardless of list size):
```C#
private void DoIncrement()
{
var updatedValue = Demo.Value + 1;
var updatedList = Demo.AllValues;
updatedList.Add(updatedValue);
Demo = new Demo
{
Value = updatedValue,
AllValues = updatedList
};
// the setter of the Demo property should take care of
// property change notifications, so no OnPropertyChanged here...
}
```
The possible performance implications i mentioned above still apply to this approach, though, so choose your "poison" well...

#18: Post edited by

elgonzo‭ · 2022-03-29T09:24:57Z (about 2 years ago)

Copy Link

Raw

Markdown

`List<T>` is not observable. In other words, `List<T>` does not offer a mechanism through which it could signal that its content has changed.
If it is possible/permissible to modify the _Demo_ class, then use [`ObservableCollection<T>`](https://docs.microsoft.com/en-us/dotnet/api/system.collections.objectmodel.observablecollection-1), [`BindingList<T>`](https://docs.microsoft.com/en-us/dotnet/api/system.componentmodel.bindinglist-1) or something similar instead. As their type names suggests, using one of them instead of List<T> will allow ListBox to listen to change notifications provided by these collections. This basically allows the ListBox to _automatically_ update whenever items are added to, removed from or replaced in one of these collection types.
While Alexei's answer will work for simple cases, note that replacing the List<T> instance and raising a respective property change event will trigger processing of **all** list items by any UI element the list or a list item is bound to. Depending on the complexity of the GUI (binding relationships, templates, etc...), specifically the work required to arrange and draw the representation(s) of an item in the UI, this approach might possibly have a noticeable performance impact when the list contains more than a few dozen items.
Using `ObservableCollection<T>` or `BindingList<T>` will **not** require raising the property change event. It will normally also not suffer from the same potential performance impact, since the ObservableCollection<T> / BindingList<T> typically tells _which_ items have been added to, removed from or replaced in it, thus the ListBox (and other related UI elements) is able to limit its layout and drawing work to the specific list items that have been added/removed/replaced.
Basically, the Demo class could perhaps look like this:
```C#
~~public class Demo~~
{
~~public int Value { get; set; } = 2;~~
public ObservableCollection<int> AllValues { get; set; } = new ObservableCollection<int> { 1, 2 };
}
```
Since the _Value_ property is also participating in data binding while its value can change, property change notifications should be implemented for this property as well (for example by making the Demo class an Observable and implement the getter/setter of the _Value_ property accordingly).
Finally, the _DoIncrement()_ method could get rid of the (now pointless) OnPropertyChanged notification:
```C
private void DoIncrement()
{
_demo.Value++;
_demo.AllValues.Add(_demo.Value);
}
```
If however an alteration of the _Demo_ class is not possible, but creating a new _Demo_ instance in the view model is okay, then instead of making a copy of the list (relatively expensive when the list becomes larger) i would perhaps rather opt for making a copy of the _Demo_ instance (remains relatively cheap regardless of list size):
```C#
private void DoIncrement()
{
var updatedValue = Demo.Value + 1;
var updatedList = Demo.AllValues;
updatedList.Add(updatedValue);
Demo = new Demo
{
Value = updatedValue,
AllValues = updatedList
};
// the setter of the Demo property should take care of
// property change notifications, so no OnPropertyChanged here...
}
```
The possible performance implications i mentioned above still apply to this approach, though, so choose your "poison" well...

`List<T>` is not observable. In other words, `List<T>` does not offer a mechanism through which it could signal that its content has changed.
If it is possible/permissible to modify the _Demo_ class, then use [`ObservableCollection<T>`](https://docs.microsoft.com/en-us/dotnet/api/system.collections.objectmodel.observablecollection-1), [`BindingList<T>`](https://docs.microsoft.com/en-us/dotnet/api/system.componentmodel.bindinglist-1) or something similar instead. As their type names suggests, using one of them instead of List<T> will allow ListBox to listen to change notifications provided by these collections. This basically allows the ListBox to _automatically_ update whenever items are added to, removed from or replaced in one of these collection types.
While Alexei's answer will work for simple cases, note that replacing the List<T> instance and raising a respective property change event will trigger processing of **all** list items by any UI element the list or a list item is bound to. Depending on the complexity of the GUI (binding relationships, templates, etc...), specifically the work required to arrange and draw the representation(s) of an item in the UI, this approach might possibly have a noticeable performance impact when the list contains more than a few dozen items.
Using `ObservableCollection<T>` or `BindingList<T>` will **not** require raising the property change event. It will normally also not suffer from the same potential performance impact, since the ObservableCollection<T> / BindingList<T> typically tells _which_ items have been added to, removed from or replaced in it, thus the ListBox (and other related UI elements) is able to limit its layout and drawing work to the specific list items that have been added/removed/replaced.
Basically, the Demo class could perhaps look like this:
```C#
public class Demo : Observable
{
public int Value
{
get => _value;
set => SetProperty(ref _value, value);
}
private int _value;
public ObservableCollection<int> AllValues { get; set; } = new ObservableCollection<int> { 1, 2 };
}
```
Since the _Value_ property is also participating in data binding while its value can change, property change notifications should be implemented for this property as well. (For example by making the Demo class an Observable and implement the getter/setter of the _Value_ property accordingly; as i did in my Demo class example here.)
Finally, the _DoIncrement()_ method could get rid of the (now pointless) OnPropertyChanged notification:
```C
private void DoIncrement()
{
_demo.Value++;
_demo.AllValues.Add(_demo.Value);
}
```
If however an alteration of the _Demo_ class is not possible, but creating a new _Demo_ instance in the view model is okay, then instead of making a copy of the list (relatively expensive when the list becomes larger) i would perhaps rather opt for making a copy of the _Demo_ instance (remains relatively cheap regardless of list size):
```C#
private void DoIncrement()
{
var updatedValue = Demo.Value + 1;
var updatedList = Demo.AllValues;
updatedList.Add(updatedValue);
Demo = new Demo
{
Value = updatedValue,
AllValues = updatedList
};
// the setter of the Demo property should take care of
// property change notifications, so no OnPropertyChanged here...
}
```
The possible performance implications i mentioned above still apply to this approach, though, so choose your "poison" well...

#17: Post edited by

elgonzo‭ · 2022-03-28T11:48:04Z (about 2 years ago)

Copy Link

Raw

Markdown

`List<T>` is not observable. In other words, `List<T>` does not offer a mechanism through which it could signal that its content has changed.
If it is possible/permissible to modify the _Demo_ class, then use [`ObservableCollection<T>`](https://docs.microsoft.com/en-us/dotnet/api/system.collections.objectmodel.observablecollection-1), [`BindingList<T>`](https://docs.microsoft.com/en-us/dotnet/api/system.componentmodel.bindinglist-1) or something similar instead. As their type names suggests, using one of them instead of List<T> will allow ListBox to listen to change notifications provided by these collections. This basically allows the ListBox to _automatically_ update whenever items are added to, removed from or replaced in one of these collection types.
While Alexei's answer will work for simple cases, note that replacing the List<T> instance and raising a respective property change event will trigger processing of **all** list items by any UI element the list or a list item is bound to. Depending on the complexity of the GUI (binding relationships, templates, etc...), specifically the work required to arrange and draw the representation(s) of an item in the UI, this approach might possibly have a noticeable performance impact when the list contains more than a few dozen items.
Using `ObservableCollection<T>` or `BindingList<T>` will **not** require raising the property change event. It will normally also not suffer from the same potential performance impact, since the ObservableCollection<T> / BindingList<T> typically tells _which_ items have been added to, removed from or replaced in it, thus the ListBox (and other related UI elements) is able to limit its layout and drawing work to the specific list items that have been added/removed/replaced.
Basically, the Demo class could perhaps look like this:
```C#
public class Demo
{
public int Value { get; set; } = 2;
public ObservableCollection<int> AllValues { get; set; } = new ObservableCollection<int> { 1, 2 };
}
```
Since the _Value_ property is also participating in data binding while its value can change, property change notifications should be implemented for this property as well (for example by making the Demo class an Observable and implement the getter/setter of the _Value_ property accordingly).
Finally, the _DoIncrement()_ method could get rid of the (now pointless) OnPropertyChanged notification:
```C
private void DoIncrement()
{
_demo.Value++;
_demo.AllValues.Add(_demo.Value);
}
```
If however an alteration of the _Demo_ class is not possible, but creating a new _Demo_ instance in the view model is okay, then instead of making a copy of the list (relatively expensive when the list becomes larger) i would perhaps rather opt for making a copy of the _Demo_ instance (remains relatively cheap regardless of list size):
```C#
private void DoIncrement()
{
var updatedValue = Demo.Value + 1;
var updatedList = Demo.AllValues;
updatedList.Add(updatedValue);
Demo = new Demo
{
Value = updatedValue,
AllValues = updatedList
};
~~// the setter of the Demo propert should take care of~~
// property change notifications, so no OnPropertyChanged here...
}
```
The possible performance implications i mentioned above still apply to this approach, though, so choose your "poison" well...

`List<T>` is not observable. In other words, `List<T>` does not offer a mechanism through which it could signal that its content has changed.
If it is possible/permissible to modify the _Demo_ class, then use [`ObservableCollection<T>`](https://docs.microsoft.com/en-us/dotnet/api/system.collections.objectmodel.observablecollection-1), [`BindingList<T>`](https://docs.microsoft.com/en-us/dotnet/api/system.componentmodel.bindinglist-1) or something similar instead. As their type names suggests, using one of them instead of List<T> will allow ListBox to listen to change notifications provided by these collections. This basically allows the ListBox to _automatically_ update whenever items are added to, removed from or replaced in one of these collection types.
While Alexei's answer will work for simple cases, note that replacing the List<T> instance and raising a respective property change event will trigger processing of **all** list items by any UI element the list or a list item is bound to. Depending on the complexity of the GUI (binding relationships, templates, etc...), specifically the work required to arrange and draw the representation(s) of an item in the UI, this approach might possibly have a noticeable performance impact when the list contains more than a few dozen items.
Using `ObservableCollection<T>` or `BindingList<T>` will **not** require raising the property change event. It will normally also not suffer from the same potential performance impact, since the ObservableCollection<T> / BindingList<T> typically tells _which_ items have been added to, removed from or replaced in it, thus the ListBox (and other related UI elements) is able to limit its layout and drawing work to the specific list items that have been added/removed/replaced.
Basically, the Demo class could perhaps look like this:
```C#
public class Demo
{
public int Value { get; set; } = 2;
public ObservableCollection<int> AllValues { get; set; } = new ObservableCollection<int> { 1, 2 };
}
```
Since the _Value_ property is also participating in data binding while its value can change, property change notifications should be implemented for this property as well (for example by making the Demo class an Observable and implement the getter/setter of the _Value_ property accordingly).
Finally, the _DoIncrement()_ method could get rid of the (now pointless) OnPropertyChanged notification:
```C
private void DoIncrement()
{
_demo.Value++;
_demo.AllValues.Add(_demo.Value);
}
```
If however an alteration of the _Demo_ class is not possible, but creating a new _Demo_ instance in the view model is okay, then instead of making a copy of the list (relatively expensive when the list becomes larger) i would perhaps rather opt for making a copy of the _Demo_ instance (remains relatively cheap regardless of list size):
```C#
private void DoIncrement()
{
var updatedValue = Demo.Value + 1;
var updatedList = Demo.AllValues;
updatedList.Add(updatedValue);
Demo = new Demo
{
Value = updatedValue,
AllValues = updatedList
};
// the setter of the Demo property should take care of
// property change notifications, so no OnPropertyChanged here...
}
```
The possible performance implications i mentioned above still apply to this approach, though, so choose your "poison" well...

#16: Post edited by

elgonzo‭ · 2022-03-28T11:45:05Z (about 2 years ago)

Copy Link

Raw

Markdown

`List<T>` is not observable. In other words, `List<T>` does not offer a mechanism through which it could signal that its content has changed.
If it is possible/permissible to modify the _Demo_ class, then use [`ObservableCollection<T>`](https://docs.microsoft.com/en-us/dotnet/api/system.collections.objectmodel.observablecollection-1), [`BindingList<T>`](https://docs.microsoft.com/en-us/dotnet/api/system.componentmodel.bindinglist-1) or something similar instead. As their type names suggests, using one of them instead of List<T> will allow ListBox to listen to change notifications provided by these collections. This basically allows the ListBox to _automatically_ update whenever items are added to, removed from or replaced in one of these collection types.
While Alexei's answer will work for simple cases, note that replacing the List<T> instance and raising a respective property change event will trigger processing of **all** list items by any UI element the list or a list item is bound to. Depending on the complexity of the GUI (binding relationships, templates, etc...), specifically the work required to arrange and draw the representation(s) of an item in the UI, this approach might possibly have a noticeable performance impact when the list contains more than a few dozen items.
Using `ObservableCollection<T>` or `BindingList<T>` will **not** require raising the property change event. It will normally also not suffer from the same potential performance impact, since the ObservableCollection<T> / BindingList<T> typically tells _which_ items have been added to, removed from or replaced in it, thus the ListBox (and other related UI elements) is able to limit its layout and drawing work to the specific list items that have been added/removed/replaced.
Basically, the Demo class could perhaps look like this:
```C#
public class Demo
{
public int Value { get; set; } = 2;
public ObservableCollection<int> AllValues { get; set; } = new ObservableCollection<int> { 1, 2 };
}
```
Since the _Value_ property is also participating in data binding while its value can change, property change notifications should be implemented for this property as well (for example by making the Demo class an Observable and implement the getter/setter of the _Value_ property accordingly).
Finally, the _DoIncrement()_ method could get rid of the (now pointless) OnPropertyChanged notification:
```C
private void DoIncrement()
{
_demo.Value++;
_demo.AllValues.Add(_demo.Value);
}
```
If however an alteration of the _Demo_ class is not possible, but creating a new _Demo_ instance in the view model is okay, then instead of making a copy of the list (relatively expensive when the list becomes larger) i would perhaps rather opt for making a copy of the _Demo_ instance (remains relatively cheap regardless of list size):
```C#
private void DoIncrement()
{
~~var updatedValue = _demo.Value + 1;~~
~~var updatedList = _demo.AllValues;~~
updatedList.Add(updatedValue);
~~_demo = new Demo~~
{
Value = updatedValue,
AllValues = updatedList
};
}
```
The possible performance implications i mentioned above still apply to this approach, though, so choose your "poison" well...

`List<T>` is not observable. In other words, `List<T>` does not offer a mechanism through which it could signal that its content has changed.
If it is possible/permissible to modify the _Demo_ class, then use [`ObservableCollection<T>`](https://docs.microsoft.com/en-us/dotnet/api/system.collections.objectmodel.observablecollection-1), [`BindingList<T>`](https://docs.microsoft.com/en-us/dotnet/api/system.componentmodel.bindinglist-1) or something similar instead. As their type names suggests, using one of them instead of List<T> will allow ListBox to listen to change notifications provided by these collections. This basically allows the ListBox to _automatically_ update whenever items are added to, removed from or replaced in one of these collection types.
While Alexei's answer will work for simple cases, note that replacing the List<T> instance and raising a respective property change event will trigger processing of **all** list items by any UI element the list or a list item is bound to. Depending on the complexity of the GUI (binding relationships, templates, etc...), specifically the work required to arrange and draw the representation(s) of an item in the UI, this approach might possibly have a noticeable performance impact when the list contains more than a few dozen items.
Using `ObservableCollection<T>` or `BindingList<T>` will **not** require raising the property change event. It will normally also not suffer from the same potential performance impact, since the ObservableCollection<T> / BindingList<T> typically tells _which_ items have been added to, removed from or replaced in it, thus the ListBox (and other related UI elements) is able to limit its layout and drawing work to the specific list items that have been added/removed/replaced.
Basically, the Demo class could perhaps look like this:
```C#
public class Demo
{
public int Value { get; set; } = 2;
public ObservableCollection<int> AllValues { get; set; } = new ObservableCollection<int> { 1, 2 };
}
```
Since the _Value_ property is also participating in data binding while its value can change, property change notifications should be implemented for this property as well (for example by making the Demo class an Observable and implement the getter/setter of the _Value_ property accordingly).
Finally, the _DoIncrement()_ method could get rid of the (now pointless) OnPropertyChanged notification:
```C
private void DoIncrement()
{
_demo.Value++;
_demo.AllValues.Add(_demo.Value);
}
```
If however an alteration of the _Demo_ class is not possible, but creating a new _Demo_ instance in the view model is okay, then instead of making a copy of the list (relatively expensive when the list becomes larger) i would perhaps rather opt for making a copy of the _Demo_ instance (remains relatively cheap regardless of list size):
```C#
private void DoIncrement()
{
var updatedValue = Demo.Value + 1;
var updatedList = Demo.AllValues;
updatedList.Add(updatedValue);
Demo = new Demo
{
Value = updatedValue,
AllValues = updatedList
};
// the setter of the Demo propert should take care of
// property change notifications, so no OnPropertyChanged here...
}
```
The possible performance implications i mentioned above still apply to this approach, though, so choose your "poison" well...

#15: Post edited by

elgonzo‭ · 2022-03-28T11:42:33Z (about 2 years ago)

Copy Link

Raw

Markdown

`List<T>` is not observable. In other words, `List<T>` does not offer a mechanism through which it could signal that its content has changed.
If it is possible/permissible to modify the _Demo_ class, then use [`ObservableCollection<T>`](https://docs.microsoft.com/en-us/dotnet/api/system.collections.objectmodel.observablecollection-1), [`BindingList<T>`](https://docs.microsoft.com/en-us/dotnet/api/system.componentmodel.bindinglist-1) or something similar instead. As their type names suggests, using one of them instead of List<T> will allow ListBox to listen to change notifications provided by these collections. This basically allows the ListBox to _automatically_ update whenever items are added to, removed from or replaced in one of these collection types.
While Alexei's answer will work for simple cases, note that replacing the List<T> instance and raising a respective property change event will trigger processing of **all** list items by any UI element the list or a list item is bound to. Depending on the complexity of the GUI (binding relationships, templates, etc...), specifically the work required to arrange and draw the representation(s) of an item in the UI, this approach might possibly have a noticeable performance impact when the list contains more than a few dozen items.
Using `ObservableCollection<T>` or `BindingList<T>` will **not** require raising the property change event. It will normally also not suffer from the same potential performance impact, since the ObservableCollection<T> / BindingList<T> typically tells _which_ items have been added to, removed from or replaced in it, thus the ListBox (and other related UI elements) is able to limit its layout and drawing work to the specific list items that have been added/removed/replaced.
Basically, the Demo class could perhaps look like this:
```C#
public class Demo
{
public int Value { get; set; } = 2;
public ObservableCollection<int> AllValues { get; set; } = new ObservableCollection<int> { 1, 2 };
}
```
Since the _Value_ property is also participating in data binding while its value can change, property change notifications should be implemented for this property as well (for example by making the Demo class an Observable and implement the getter/setter of the _Value_ property accordingly).
Finally, the _DoIncrement()_ method could get rid of the (now pointless) OnPropertyChanged notification:
```C
private void DoIncrement()
{
_demo.Value++;
_demo.AllValues.Add(_demo.Value);
}
```
If however an alteration of the _Demo_ class is not possible, but creating a new Demo instance in the view model is okay, then instead of making a copy of the list (relatively expensive when the list becomes larger) i would perhaps rather opt for making a copy of the _Demo_ instance (remains relatively cheap regardless of list size):
```C#
private void DoIncrement()
{
var updatedValue = _demo.Value + 1;
var updatedList = _demo.AllValues;
updatedList.Add(updatedValue);
_demo = new Demo
{
Value = updatedValue,
AllValues = updatedList
};
}
```
The possible performance implications i mentioned above still apply to this approach, though, so choose your "poison" well...

`List<T>` is not observable. In other words, `List<T>` does not offer a mechanism through which it could signal that its content has changed.
If it is possible/permissible to modify the _Demo_ class, then use [`ObservableCollection<T>`](https://docs.microsoft.com/en-us/dotnet/api/system.collections.objectmodel.observablecollection-1), [`BindingList<T>`](https://docs.microsoft.com/en-us/dotnet/api/system.componentmodel.bindinglist-1) or something similar instead. As their type names suggests, using one of them instead of List<T> will allow ListBox to listen to change notifications provided by these collections. This basically allows the ListBox to _automatically_ update whenever items are added to, removed from or replaced in one of these collection types.
While Alexei's answer will work for simple cases, note that replacing the List<T> instance and raising a respective property change event will trigger processing of **all** list items by any UI element the list or a list item is bound to. Depending on the complexity of the GUI (binding relationships, templates, etc...), specifically the work required to arrange and draw the representation(s) of an item in the UI, this approach might possibly have a noticeable performance impact when the list contains more than a few dozen items.
Using `ObservableCollection<T>` or `BindingList<T>` will **not** require raising the property change event. It will normally also not suffer from the same potential performance impact, since the ObservableCollection<T> / BindingList<T> typically tells _which_ items have been added to, removed from or replaced in it, thus the ListBox (and other related UI elements) is able to limit its layout and drawing work to the specific list items that have been added/removed/replaced.
Basically, the Demo class could perhaps look like this:
```C#
public class Demo
{
public int Value { get; set; } = 2;
public ObservableCollection<int> AllValues { get; set; } = new ObservableCollection<int> { 1, 2 };
}
```
Since the _Value_ property is also participating in data binding while its value can change, property change notifications should be implemented for this property as well (for example by making the Demo class an Observable and implement the getter/setter of the _Value_ property accordingly).
Finally, the _DoIncrement()_ method could get rid of the (now pointless) OnPropertyChanged notification:
```C
private void DoIncrement()
{
_demo.Value++;
_demo.AllValues.Add(_demo.Value);
}
```
If however an alteration of the _Demo_ class is not possible, but creating a new _Demo_ instance in the view model is okay, then instead of making a copy of the list (relatively expensive when the list becomes larger) i would perhaps rather opt for making a copy of the _Demo_ instance (remains relatively cheap regardless of list size):
```C#
private void DoIncrement()
{
var updatedValue = _demo.Value + 1;
var updatedList = _demo.AllValues;
updatedList.Add(updatedValue);
_demo = new Demo
{
Value = updatedValue,
AllValues = updatedList
};
}
```
The possible performance implications i mentioned above still apply to this approach, though, so choose your "poison" well...

#14: Post edited by

elgonzo‭ · 2022-03-28T11:41:55Z (about 2 years ago)

Copy Link

Raw

Markdown

`List<T>` is not observable. In other words, `List<T>` does not offer a mechanism through which it could signal that its content has changed.
Use [`ObservableCollection<T>`](https://docs.microsoft.com/en-us/dotnet/api/system.collections.objectmodel.observablecollection-1), [`BindingList<T>`](https://docs.microsoft.com/en-us/dotnet/api/system.componentmodel.bindinglist-1) or something similar instead. As their type names suggests, using one of them instead of List<T> will allow ListBox to listen to change notifications provided by these collections. This basically allows the ListBox to _automatically_ update whenever items are added to, removed from or replaced in one of these collection types.
While Alexei's answer will work for simple cases, note that replacing the List<T> instance and raising a respective property change event will trigger processing of **all** list items by any UI element the list or a list item is bound to. Depending on the complexity of the GUI (binding relationships, templates, etc...), specifically the work required to arrange and draw the representation(s) of an item in the UI, this approach might possibly have a noticeable performance impact when the list contains more than a few dozen items.
Using `ObservableCollection<T>` or `BindingList<T>` will **not** require raising the property change event. It will normally also not suffer from the same potential performance impact, since the ObservableCollection<T> / BindingList<T> typically tells _which_ items have been added to, removed from or replaced in it, thus the ListBox (and other related UI elements) is able to limit its layout and drawing work to the specific list items that have been added/removed/replaced.
Basically, the Demo class could perhaps look like this:
```C#
public class Demo
{
public int Value { get; set; } = 2;
public ObservableCollection<int> AllValues { get; set; } = new ObservableCollection<int> { 1, 2 };
}
```
Since the _Value_ property is also participating in data binding while its value can change, property change notifications should be implemented for this property as well (for example by making the Demo class an Observable and implement the getter/setter of the _Value_ property accordingly).
Finally, the _DoIncrement()_ method could get rid of the (now pointless) OnPropertyChanged notification:
```C
private void DoIncrement()
{
_demo.Value++;
_demo.AllValues.Add(_demo.Value);
}
```
If however an alteration of the _Demo_ class is not possible, but creating a new Demo instance in the view model is okay, then instead of making a copy of the list (relatively expensive when the list becomes larger) i would perhaps rather opt for making a copy of the _Demo_ instance (remains relatively cheap regardless of list size):
```C#
private void DoIncrement()
{
var updatedValue = _demo.Value + 1;
var updatedList = _demo.AllValues;
updatedList.Add(updatedValue);
_demo = new Demo
{
Value = updatedValue,
AllValues = updatedList
};
}
```
The possible performance implications i mentioned above still apply to this approach, though, so choose your "poison" well...

`List<T>` is not observable. In other words, `List<T>` does not offer a mechanism through which it could signal that its content has changed.
If it is possible/permissible to modify the _Demo_ class, then use [`ObservableCollection<T>`](https://docs.microsoft.com/en-us/dotnet/api/system.collections.objectmodel.observablecollection-1), [`BindingList<T>`](https://docs.microsoft.com/en-us/dotnet/api/system.componentmodel.bindinglist-1) or something similar instead. As their type names suggests, using one of them instead of List<T> will allow ListBox to listen to change notifications provided by these collections. This basically allows the ListBox to _automatically_ update whenever items are added to, removed from or replaced in one of these collection types.
While Alexei's answer will work for simple cases, note that replacing the List<T> instance and raising a respective property change event will trigger processing of **all** list items by any UI element the list or a list item is bound to. Depending on the complexity of the GUI (binding relationships, templates, etc...), specifically the work required to arrange and draw the representation(s) of an item in the UI, this approach might possibly have a noticeable performance impact when the list contains more than a few dozen items.
Using `ObservableCollection<T>` or `BindingList<T>` will **not** require raising the property change event. It will normally also not suffer from the same potential performance impact, since the ObservableCollection<T> / BindingList<T> typically tells _which_ items have been added to, removed from or replaced in it, thus the ListBox (and other related UI elements) is able to limit its layout and drawing work to the specific list items that have been added/removed/replaced.
Basically, the Demo class could perhaps look like this:
```C#
public class Demo
{
public int Value { get; set; } = 2;
public ObservableCollection<int> AllValues { get; set; } = new ObservableCollection<int> { 1, 2 };
}
```
Since the _Value_ property is also participating in data binding while its value can change, property change notifications should be implemented for this property as well (for example by making the Demo class an Observable and implement the getter/setter of the _Value_ property accordingly).
Finally, the _DoIncrement()_ method could get rid of the (now pointless) OnPropertyChanged notification:
```C
private void DoIncrement()
{
_demo.Value++;
_demo.AllValues.Add(_demo.Value);
}
```
If however an alteration of the _Demo_ class is not possible, but creating a new Demo instance in the view model is okay, then instead of making a copy of the list (relatively expensive when the list becomes larger) i would perhaps rather opt for making a copy of the _Demo_ instance (remains relatively cheap regardless of list size):
```C#
private void DoIncrement()
{
var updatedValue = _demo.Value + 1;
var updatedList = _demo.AllValues;
updatedList.Add(updatedValue);
_demo = new Demo
{
Value = updatedValue,
AllValues = updatedList
};
}
```
The possible performance implications i mentioned above still apply to this approach, though, so choose your "poison" well...

#13: Post edited by

elgonzo‭ · 2022-03-28T11:40:58Z (about 2 years ago)

Copy Link

Raw

Markdown

`List<T>` is not observable. In other words, `List<T>` does not offer a mechanism through which it could signal that its content has changed.
Use [`ObservableCollection<T>`](https://docs.microsoft.com/en-us/dotnet/api/system.collections.objectmodel.observablecollection-1), [`BindingList<T>`](https://docs.microsoft.com/en-us/dotnet/api/system.componentmodel.bindinglist-1) or something similar instead. As their type names suggests, using one of them instead of List<T> will allow ListBox to listen to change notifications provided by these collections. This basically allows the ListBox to _automatically_ update whenever items are added to, removed from or replaced in one of these collection types.
While Alexei's answer will work for simple cases, note that replacing the List<T> instance and raising a respective property change event will trigger processing of **all** list items by any UI element the list or a list item is bound to. Depending on the complexity of the GUI (binding relationships, templates, etc...), specifically the work required to arrange and draw the representation(s) of an item in the UI, this approach might possibly have a noticeable performance impact when the list contains more than a few dozen items.
Using `ObservableCollection<T>` or `BindingList<T>` will **not** require raising the property change event. It will normally also not suffer from the same potential performance impact, since the ObservableCollection<T> / BindingList<T> typically tells _which_ items have been added to, removed from or replaced in it, thus the ListBox (and other related UI elements) is able to limit its layout and drawing work to the specific list items that have been added/removed/replaced.
Basically, the Demo class could perhaps look like this:
```C#
public class Demo
{
public int Value { get; set; } = 2;
public ObservableCollection<int> AllValues { get; set; } = new ObservableCollection<int> { 1, 2 };
}
```
~~and the _DoIncrement()_ method would get rid of the (now pointless) OnPropertyChanged notification:~~
```C
private void DoIncrement()
{
_demo.Value++;
_demo.AllValues.Add(_demo.Value);
}
```

`List<T>` is not observable. In other words, `List<T>` does not offer a mechanism through which it could signal that its content has changed.
Use [`ObservableCollection<T>`](https://docs.microsoft.com/en-us/dotnet/api/system.collections.objectmodel.observablecollection-1), [`BindingList<T>`](https://docs.microsoft.com/en-us/dotnet/api/system.componentmodel.bindinglist-1) or something similar instead. As their type names suggests, using one of them instead of List<T> will allow ListBox to listen to change notifications provided by these collections. This basically allows the ListBox to _automatically_ update whenever items are added to, removed from or replaced in one of these collection types.
While Alexei's answer will work for simple cases, note that replacing the List<T> instance and raising a respective property change event will trigger processing of **all** list items by any UI element the list or a list item is bound to. Depending on the complexity of the GUI (binding relationships, templates, etc...), specifically the work required to arrange and draw the representation(s) of an item in the UI, this approach might possibly have a noticeable performance impact when the list contains more than a few dozen items.
Using `ObservableCollection<T>` or `BindingList<T>` will **not** require raising the property change event. It will normally also not suffer from the same potential performance impact, since the ObservableCollection<T> / BindingList<T> typically tells _which_ items have been added to, removed from or replaced in it, thus the ListBox (and other related UI elements) is able to limit its layout and drawing work to the specific list items that have been added/removed/replaced.
Basically, the Demo class could perhaps look like this:
```C#
public class Demo
{
public int Value { get; set; } = 2;
public ObservableCollection<int> AllValues { get; set; } = new ObservableCollection<int> { 1, 2 };
}
```
Since the _Value_ property is also participating in data binding while its value can change, property change notifications should be implemented for this property as well (for example by making the Demo class an Observable and implement the getter/setter of the _Value_ property accordingly).
Finally, the _DoIncrement()_ method could get rid of the (now pointless) OnPropertyChanged notification:
```C
private void DoIncrement()
{
_demo.Value++;
_demo.AllValues.Add(_demo.Value);
}
```
If however an alteration of the _Demo_ class is not possible, but creating a new Demo instance in the view model is okay, then instead of making a copy of the list (relatively expensive when the list becomes larger) i would perhaps rather opt for making a copy of the _Demo_ instance (remains relatively cheap regardless of list size):
```C#
private void DoIncrement()
{
var updatedValue = _demo.Value + 1;
var updatedList = _demo.AllValues;
updatedList.Add(updatedValue);
_demo = new Demo
{
Value = updatedValue,
AllValues = updatedList
};
}
```
The possible performance implications i mentioned above still apply to this approach, though, so choose your "poison" well...

#12: Post edited by

elgonzo‭ · 2022-03-28T11:10:30Z (about 2 years ago)

Copy Link

Raw

Markdown

`List<T>` is not observable. In other words, `List<T>` does not offer a mechanism through which it could signal that its content has changed.
Use [`ObservableCollection<T>`](https://docs.microsoft.com/en-us/dotnet/api/system.collections.objectmodel.observablecollection-1), [`BindingList<T>`](https://docs.microsoft.com/en-us/dotnet/api/system.componentmodel.bindinglist-1) or something similar instead. As their type names suggests, using one of them instead of `List<T>` will allow ListBox to listen to change notifications provided by these collections. This basically allows the ListBox to _automatically_ update whenever items are added to, removed from or replaced in one of these collection types.
While Alexei's answer will work for simple cases, note that replacing the List<T> instance and raising a respective property change event will trigger processing of **all** list items by any UI element the list or a list item is bound to. Depending on the complexity of the GUI (binding relationships, templates, etc...), specifically the work required to arrange and draw the representation(s) of an item in the UI, this approach might possibly have a noticeable performance impact when the list contains more than a few dozen items.
Using `ObservableCollection<T>` or `BindingList<T>` will **not** require raising the property change event. It will normally also not suffer from the same potential performance impact, since the ObservableCollection<T> / BindingList<T> typically tells _which_ items have been added to, removed from or replaced in it, thus the ListBox (and other related UI elements) is able to limit its layout and drawing work to the specific list items that have been added/removed/replaced.
Basically, the Demo class could perhaps look like this:
```C#
public class Demo
{
public int Value { get; set; } = 2;
public ObservableCollection<int> AllValues { get; set; } = new ObservableCollection<int> { 1, 2 };
}
```
and the _DoIncrement()_ method would get rid of the (now pointless) OnPropertyChanged notification:
```C
private void DoIncrement()
{
_demo.Value++;
_demo.AllValues.Add(_demo.Value);
}
```

`List<T>` is not observable. In other words, `List<T>` does not offer a mechanism through which it could signal that its content has changed.
Use [`ObservableCollection<T>`](https://docs.microsoft.com/en-us/dotnet/api/system.collections.objectmodel.observablecollection-1), [`BindingList<T>`](https://docs.microsoft.com/en-us/dotnet/api/system.componentmodel.bindinglist-1) or something similar instead. As their type names suggests, using one of them instead of List<T> will allow ListBox to listen to change notifications provided by these collections. This basically allows the ListBox to _automatically_ update whenever items are added to, removed from or replaced in one of these collection types.
While Alexei's answer will work for simple cases, note that replacing the List<T> instance and raising a respective property change event will trigger processing of **all** list items by any UI element the list or a list item is bound to. Depending on the complexity of the GUI (binding relationships, templates, etc...), specifically the work required to arrange and draw the representation(s) of an item in the UI, this approach might possibly have a noticeable performance impact when the list contains more than a few dozen items.
Using `ObservableCollection<T>` or `BindingList<T>` will **not** require raising the property change event. It will normally also not suffer from the same potential performance impact, since the ObservableCollection<T> / BindingList<T> typically tells _which_ items have been added to, removed from or replaced in it, thus the ListBox (and other related UI elements) is able to limit its layout and drawing work to the specific list items that have been added/removed/replaced.
Basically, the Demo class could perhaps look like this:
```C#
public class Demo
{
public int Value { get; set; } = 2;
public ObservableCollection<int> AllValues { get; set; } = new ObservableCollection<int> { 1, 2 };
}
```
and the _DoIncrement()_ method would get rid of the (now pointless) OnPropertyChanged notification:
```C
private void DoIncrement()
{
_demo.Value++;
_demo.AllValues.Add(_demo.Value);
}
```

#11: Post edited by

elgonzo‭ · 2022-03-28T11:09:55Z (about 2 years ago)

Copy Link

Raw

Markdown

`List<T>` is not observable. In other words, `List<T>` does not offer a mechanism through which it could signal that its content has changed.
Use [`ObservableCollection<T>`](https://docs.microsoft.com/en-us/dotnet/api/system.collections.objectmodel.observablecollection-1) instead. As its type name suggests, using it instead of `List<T>` will allow ListBox to listen to change notifications of ObservableCollection<T>. This basically allows the ListBox to _automatically_ update whenever items are added to, removed from or replaced in the ObservableCollection<T>.
While Alexei's answer will work for simple cases, note that replacing the List<T> instance and raising a respective property change event will trigger processing of **all** list items by any UI element the list or a list item is bound to. Depending on the complexity of the GUI (binding relationships, templates, etc...), specifically the work required to arrange and draw the representation(s) of an item in the UI, this approach might possibly have a noticeable performance impact when the list contains more than a few dozen items.
Using `ObservableCollection<T>` will **not** require raising the property change event. It will normally also not suffer from the same potential performance impact, since the ObservableCollection<T> typically tells _which_ items have been added to, removed from or replaced in it, thus the ListBox (and other related UI elements) is able to limit its layout and drawing work to the specific list items that have been added/removed/replaced.
~~Basically, the Demo class should look like this:~~
```C#
public class Demo
{
public int Value { get; set; } = 2;
public ObservableCollection<int> AllValues { get; set; } = new ObservableCollection<int> { 1, 2 };
}
```
~~and get rid of the (now pointless) OnPropertyChanged notification:~~
```C
private void DoIncrement()
{
_demo.Value++;
_demo.AllValues.Add(_demo.Value);
}
```

`List<T>` is not observable. In other words, `List<T>` does not offer a mechanism through which it could signal that its content has changed.
Use [`ObservableCollection<T>`](https://docs.microsoft.com/en-us/dotnet/api/system.collections.objectmodel.observablecollection-1), [`BindingList<T>`](https://docs.microsoft.com/en-us/dotnet/api/system.componentmodel.bindinglist-1) or something similar instead. As their type names suggests, using one of them instead of `List<T>` will allow ListBox to listen to change notifications provided by these collections. This basically allows the ListBox to _automatically_ update whenever items are added to, removed from or replaced in one of these collection types.
While Alexei's answer will work for simple cases, note that replacing the List<T> instance and raising a respective property change event will trigger processing of **all** list items by any UI element the list or a list item is bound to. Depending on the complexity of the GUI (binding relationships, templates, etc...), specifically the work required to arrange and draw the representation(s) of an item in the UI, this approach might possibly have a noticeable performance impact when the list contains more than a few dozen items.
Using `ObservableCollection<T>` or `BindingList<T>` will **not** require raising the property change event. It will normally also not suffer from the same potential performance impact, since the ObservableCollection<T> / BindingList<T> typically tells _which_ items have been added to, removed from or replaced in it, thus the ListBox (and other related UI elements) is able to limit its layout and drawing work to the specific list items that have been added/removed/replaced.
Basically, the Demo class could perhaps look like this:
```C#
public class Demo
{
public int Value { get; set; } = 2;
public ObservableCollection<int> AllValues { get; set; } = new ObservableCollection<int> { 1, 2 };
}
```
and the _DoIncrement()_ method would get rid of the (now pointless) OnPropertyChanged notification:
```C
private void DoIncrement()
{
_demo.Value++;
_demo.AllValues.Add(_demo.Value);
}
```

#10: Post edited by

elgonzo‭ · 2022-03-28T10:56:19Z (about 2 years ago)

Copy Link

Raw

Markdown

`List<T>` is not observable. In other words, `List<T>` does not offer a mechanism through which it could signal that its content has changed.
Use [`ObservableCollection<T>`](https://docs.microsoft.com/en-us/dotnet/api/system.collections.objectmodel.observablecollection-1) instead. As its type name suggests, using it instead of `List<T>` will allow ListBox to listen to change notifications of ObservableCollection<T>. This basically allows the ListBox to _automatically_ update whenever items are added to, removed from or replaced in the ObservableCollection<T>.
While Alexei's answer will work for simple cases, note that replacing the List<T> instance and raising a respective property change event will trigger processing of **all** list items by any UI element the list or a list item is bound to. Depending on the complexity of the GUI (binding relationships, templates, etc...), specifically the work required to arrange and draw the representation(s) of an item in the UI, this approach might possibly have a noticeable performance impact when the list contains more than a few dozen items.
Using `ObservableCollection<T>` will **not** require raising the property change event. It also will normally also not suffer from the same potential performance impact, since the ObservableCollection<T> typically tells _which_ items have been added to, removed from or replaced in it, thus the ListBox (and other related UI elements) is able to limit its layout and drawing work to the specific list items that have been added/removed/replaced.
Basically, the Demo class should look like this:
```C#
public class Demo
{
public int Value { get; set; } = 2;
public ObservableCollection<int> AllValues { get; set; } = new ObservableCollection<int> { 1, 2 };
}
```
and get rid of the (now pointless) OnPropertyChanged notification:
```C
private void DoIncrement()
{
_demo.Value++;
_demo.AllValues.Add(_demo.Value);
}
```

`List<T>` is not observable. In other words, `List<T>` does not offer a mechanism through which it could signal that its content has changed.
Use [`ObservableCollection<T>`](https://docs.microsoft.com/en-us/dotnet/api/system.collections.objectmodel.observablecollection-1) instead. As its type name suggests, using it instead of `List<T>` will allow ListBox to listen to change notifications of ObservableCollection<T>. This basically allows the ListBox to _automatically_ update whenever items are added to, removed from or replaced in the ObservableCollection<T>.
While Alexei's answer will work for simple cases, note that replacing the List<T> instance and raising a respective property change event will trigger processing of **all** list items by any UI element the list or a list item is bound to. Depending on the complexity of the GUI (binding relationships, templates, etc...), specifically the work required to arrange and draw the representation(s) of an item in the UI, this approach might possibly have a noticeable performance impact when the list contains more than a few dozen items.
Using `ObservableCollection<T>` will **not** require raising the property change event. It will normally also not suffer from the same potential performance impact, since the ObservableCollection<T> typically tells _which_ items have been added to, removed from or replaced in it, thus the ListBox (and other related UI elements) is able to limit its layout and drawing work to the specific list items that have been added/removed/replaced.
Basically, the Demo class should look like this:
```C#
public class Demo
{
public int Value { get; set; } = 2;
public ObservableCollection<int> AllValues { get; set; } = new ObservableCollection<int> { 1, 2 };
}
```
and get rid of the (now pointless) OnPropertyChanged notification:
```C
private void DoIncrement()
{
_demo.Value++;
_demo.AllValues.Add(_demo.Value);
}
```

#9: Post edited by

elgonzo‭ · 2022-03-28T10:54:51Z (about 2 years ago)

Copy Link

Raw

Markdown

`List<T>` is not observable. In other words, `List<T>` does not offer a mechanism through which it could signal that its content has changed.
Use [`ObservableCollection<T>`](https://docs.microsoft.com/en-us/dotnet/api/system.collections.objectmodel.observablecollection-1) instead. As its type name suggests, using it instead of `List<T>` will allow ListBox to listen to change notifications of ObservableCollection<T>. This basically allows the ListBox to _automatically_ update whenever items are added to, removed from or replaced in the ObservableCollection<T>.
While Alexei's answer will work for simple cases, note that replacing the List<T> instance and raising a respective property change event will trigger processing of **all** list items by any UI element the list is bound to. Depending on the complexity of the GUI (binding relationships, templates, etc...), specifically the work required to arrange and draw the representation(s) of an item in the UI, this approach might possibly have a noticeable performance impact when the list contains more than a few dozen items.
Using `ObservableCollection<T>` will **not** require raising the property change event. It also will normally also not suffer from the same potential performance impact, since the ObservableCollection<T> typically tells _which_ items have been added to, removed from or replaced in it, thus the ListBox (and other related UI elements) is able to limit its layout and drawing work to the specific list items that have been added/removed/replaced.
Basically, the Demo class should look like this:
```C#
public class Demo
{
public int Value { get; set; } = 2;
public ObservableCollection<int> AllValues { get; set; } = new ObservableCollection<int> { 1, 2 };
}
```
and get rid of the (now pointless) OnPropertyChanged notification:
```C
private void DoIncrement()
{
_demo.Value++;
_demo.AllValues.Add(_demo.Value);
}
```

`List<T>` is not observable. In other words, `List<T>` does not offer a mechanism through which it could signal that its content has changed.
Use [`ObservableCollection<T>`](https://docs.microsoft.com/en-us/dotnet/api/system.collections.objectmodel.observablecollection-1) instead. As its type name suggests, using it instead of `List<T>` will allow ListBox to listen to change notifications of ObservableCollection<T>. This basically allows the ListBox to _automatically_ update whenever items are added to, removed from or replaced in the ObservableCollection<T>.
While Alexei's answer will work for simple cases, note that replacing the List<T> instance and raising a respective property change event will trigger processing of **all** list items by any UI element the list or a list item is bound to. Depending on the complexity of the GUI (binding relationships, templates, etc...), specifically the work required to arrange and draw the representation(s) of an item in the UI, this approach might possibly have a noticeable performance impact when the list contains more than a few dozen items.
Using `ObservableCollection<T>` will **not** require raising the property change event. It also will normally also not suffer from the same potential performance impact, since the ObservableCollection<T> typically tells _which_ items have been added to, removed from or replaced in it, thus the ListBox (and other related UI elements) is able to limit its layout and drawing work to the specific list items that have been added/removed/replaced.
Basically, the Demo class should look like this:
```C#
public class Demo
{
public int Value { get; set; } = 2;
public ObservableCollection<int> AllValues { get; set; } = new ObservableCollection<int> { 1, 2 };
}
```
and get rid of the (now pointless) OnPropertyChanged notification:
```C
private void DoIncrement()
{
_demo.Value++;
_demo.AllValues.Add(_demo.Value);
}
```

#8: Post edited by

elgonzo‭ · 2022-03-28T10:54:20Z (about 2 years ago)

Copy Link

Raw

Markdown

`List<T>` is not observable. In other words, `List<T>` does not offer a mechanism through which it could signal that its content has changed.
Use [`ObservableCollection<T>`](https://docs.microsoft.com/en-us/dotnet/api/system.collections.objectmodel.observablecollection-1) instead. As its type name suggests, using it instead of `List<T>` will allow ListBox to listen to change notifications of ObservableCollection<T>. This basically allows the ListBox to _automatically_ update whenever items are added to, removed from or replaced in the ObservableCollection<T>.
While Alexei's answer will work for simple cases, note that replacing the List<T> instance and raising a respective property change event will trigger processing of **all** list items by the ListBox. Depending on the complexity of the GUI (binding relationships, templates, etc...), specifically the work required to arrange and draw the representation(s) of an item in the UI, this approach might possibly have a noticeable performance impact when the list contains more than a few dozen items.
Using `ObservableCollection<T>` will **not** require raising the property change event. It also will normally also not suffer from the same potential performance impact, since the ObservableCollection<T> typically tells _which_ items have been added to, removed from or replaced in it, thus the ListBox (and other related UI elements) is able to limit its layout and drawing work to the specific list items that have been added/removed/replaced.
Basically, the Demo class should look like this:
```C#
public class Demo
{
public int Value { get; set; } = 2;
public ObservableCollection<int> AllValues { get; set; } = new ObservableCollection<int> { 1, 2 };
}
```
and get rid of the (now pointless) OnPropertyChanged notification:
```C
private void DoIncrement()
{
_demo.Value++;
_demo.AllValues.Add(_demo.Value);
}
```

`List<T>` is not observable. In other words, `List<T>` does not offer a mechanism through which it could signal that its content has changed.
Use [`ObservableCollection<T>`](https://docs.microsoft.com/en-us/dotnet/api/system.collections.objectmodel.observablecollection-1) instead. As its type name suggests, using it instead of `List<T>` will allow ListBox to listen to change notifications of ObservableCollection<T>. This basically allows the ListBox to _automatically_ update whenever items are added to, removed from or replaced in the ObservableCollection<T>.
While Alexei's answer will work for simple cases, note that replacing the List<T> instance and raising a respective property change event will trigger processing of **all** list items by any UI element the list is bound to. Depending on the complexity of the GUI (binding relationships, templates, etc...), specifically the work required to arrange and draw the representation(s) of an item in the UI, this approach might possibly have a noticeable performance impact when the list contains more than a few dozen items.
Using `ObservableCollection<T>` will **not** require raising the property change event. It also will normally also not suffer from the same potential performance impact, since the ObservableCollection<T> typically tells _which_ items have been added to, removed from or replaced in it, thus the ListBox (and other related UI elements) is able to limit its layout and drawing work to the specific list items that have been added/removed/replaced.
Basically, the Demo class should look like this:
```C#
public class Demo
{
public int Value { get; set; } = 2;
public ObservableCollection<int> AllValues { get; set; } = new ObservableCollection<int> { 1, 2 };
}
```
and get rid of the (now pointless) OnPropertyChanged notification:
```C
private void DoIncrement()
{
_demo.Value++;
_demo.AllValues.Add(_demo.Value);
}
```

#7: Post edited by

elgonzo‭ · 2022-03-28T10:52:09Z (about 2 years ago)

Copy Link

Raw

Markdown

`List<T>` is not observable. In other words, `List<T>` does not offer a mechanism through which it could signal that its content has changed.
Use [`ObservableCollection<T>`](https://docs.microsoft.com/en-us/dotnet/api/system.collections.objectmodel.observablecollection-1) instead. As its type name suggests, using it instead of `List<T>` will allow ListBox to listen to change notifications of ObservableCollection<T>. This basically allows the ListBox to _automatically_ update whenever items are added to, removed from or replaced in the ObservableCollection<T>.
While Alexei's answer will work for simple cases, note that replacing the List<T> instance and raising a respective property change event will trigger processing of **all** list items by the ListBox. Depending on the complexity of the GUI (binding relationships, templates, etc...), specifically the work required to arrange and draw the representation(s) of an item in the UI, this approach possibly might have a noticable performance impact when the list contains more than a few dozen items.
Using `ObservableCollection<T>` will **not** require raising the property change event. It also will normally also not suffer from the same potential performance impact, since the ObservableCollection<T> typically tells _which_ items have been added to, removed from or replaced in it, thus the ListBox (and other related UI elements) is able to limit its layout and drawing work to the specific list items that have been added/removed/replaced.
Basically, the Demo class should look like this:
```C#
public class Demo
{
public int Value { get; set; } = 2;
public ObservableCollection<int> AllValues { get; set; } = new ObservableCollection<int> { 1, 2 };
}
```
and get rid of the (now pointless) OnPropertyChanged notification:
```C
private void DoIncrement()
{
_demo.Value++;
_demo.AllValues.Add(_demo.Value);
}
```

`List<T>` is not observable. In other words, `List<T>` does not offer a mechanism through which it could signal that its content has changed.
Use [`ObservableCollection<T>`](https://docs.microsoft.com/en-us/dotnet/api/system.collections.objectmodel.observablecollection-1) instead. As its type name suggests, using it instead of `List<T>` will allow ListBox to listen to change notifications of ObservableCollection<T>. This basically allows the ListBox to _automatically_ update whenever items are added to, removed from or replaced in the ObservableCollection<T>.
While Alexei's answer will work for simple cases, note that replacing the List<T> instance and raising a respective property change event will trigger processing of **all** list items by the ListBox. Depending on the complexity of the GUI (binding relationships, templates, etc...), specifically the work required to arrange and draw the representation(s) of an item in the UI, this approach might possibly have a noticeable performance impact when the list contains more than a few dozen items.
Using `ObservableCollection<T>` will **not** require raising the property change event. It also will normally also not suffer from the same potential performance impact, since the ObservableCollection<T> typically tells _which_ items have been added to, removed from or replaced in it, thus the ListBox (and other related UI elements) is able to limit its layout and drawing work to the specific list items that have been added/removed/replaced.
Basically, the Demo class should look like this:
```C#
public class Demo
{
public int Value { get; set; } = 2;
public ObservableCollection<int> AllValues { get; set; } = new ObservableCollection<int> { 1, 2 };
}
```
and get rid of the (now pointless) OnPropertyChanged notification:
```C
private void DoIncrement()
{
_demo.Value++;
_demo.AllValues.Add(_demo.Value);
}
```

#6: Post edited by

elgonzo‭ · 2022-03-28T10:51:35Z (about 2 years ago)

Copy Link

Raw

Markdown

`List<T>` is not observable. In other words, `List<T>` does not offer a mechanism through which it could signal that its content has changed.
Use [`ObservableCollection<T>`](https://docs.microsoft.com/en-us/dotnet/api/system.collections.objectmodel.observablecollection-1) instead. As its type name suggests, using it instead of `List<T>` will allow ListBox to listen to change notifications of ObservableCollection<T>. This basically allows the ListBox to _automatically_ update whenever items are added to, removed from or replaced in the ObservableCollection<T>.
While Alexei's answer will work for simple cases, note that replacing the List<T> instance and raising a respective property change event will trigger a **full** re-evaluation of **all** list items by the ListBox. Depending on the complexity of the GUI (binding relationships, templates, etc...), specifically the work required to arrange and draw the representation(s) of an item in the UI, this approach possibly might have a noticable performance impact when the list contains more than a few dozen items.
Using `ObservableCollection<T>` will **not** require raising the property change event. It also will normally also not suffer from the same potential performance impact, since the ObservableCollection<T> typically tells _which_ items have been added to, removed from or replaced in it, thus the ListBox (and other related UI elements) is able to limit its layout and drawing work to the specific list items that have been added/removed/replaced.
Basically, the Demo class should look like this:
```C#
public class Demo
{
public int Value { get; set; } = 2;
public ObservableCollection<int> AllValues { get; set; } = new ObservableCollection<int> { 1, 2 };
}
```
and get rid of the (now pointless) OnPropertyChanged notification:
```C
private void DoIncrement()
{
_demo.Value++;
_demo.AllValues.Add(_demo.Value);
}
```

`List<T>` is not observable. In other words, `List<T>` does not offer a mechanism through which it could signal that its content has changed.
Use [`ObservableCollection<T>`](https://docs.microsoft.com/en-us/dotnet/api/system.collections.objectmodel.observablecollection-1) instead. As its type name suggests, using it instead of `List<T>` will allow ListBox to listen to change notifications of ObservableCollection<T>. This basically allows the ListBox to _automatically_ update whenever items are added to, removed from or replaced in the ObservableCollection<T>.
While Alexei's answer will work for simple cases, note that replacing the List<T> instance and raising a respective property change event will trigger processing of **all** list items by the ListBox. Depending on the complexity of the GUI (binding relationships, templates, etc...), specifically the work required to arrange and draw the representation(s) of an item in the UI, this approach possibly might have a noticable performance impact when the list contains more than a few dozen items.
Using `ObservableCollection<T>` will **not** require raising the property change event. It also will normally also not suffer from the same potential performance impact, since the ObservableCollection<T> typically tells _which_ items have been added to, removed from or replaced in it, thus the ListBox (and other related UI elements) is able to limit its layout and drawing work to the specific list items that have been added/removed/replaced.
Basically, the Demo class should look like this:
```C#
public class Demo
{
public int Value { get; set; } = 2;
public ObservableCollection<int> AllValues { get; set; } = new ObservableCollection<int> { 1, 2 };
}
```
and get rid of the (now pointless) OnPropertyChanged notification:
```C
private void DoIncrement()
{
_demo.Value++;
_demo.AllValues.Add(_demo.Value);
}
```

#5: Post edited by

elgonzo‭ · 2022-03-28T10:50:05Z (about 2 years ago)

Copy Link

Raw

Markdown

`List<T>` is not observable. In other words, `List<T>` does not offer a mechanism through which it could signal that its content has changed.
Use [`ObservableCollection<T>`](https://docs.microsoft.com/en-us/dotnet/api/system.collections.objectmodel.observablecollection-1) instead. As its type name suggests, using it instead of `List<T>` will allow ListBox to listen to change notifications of ObservableCollection<T>. This basically allows the ListBox to _automatically_ update whenever items are added to, removed from or replaced in the ObservableCollection<T>.
While Alexei's answer will work for simple cases, note that replacing the List<T> instance and raising a respective property change event will trigger a **full** re-evaluation of **all** list items by the ListBox. Depending on the complexity of the GUI (binding relationships, templates, etc...) this approach possibly might have a noticable performance impact when the list contains more than a few dozen items.
Using `ObservableCollection<T>` will **not** require raising the property change event. It also will normally also not suffer from the same potential performance impact, since the ObservableCollection<T> typically tells _which_ items have been added to, removed from or replaced in it, thus the ListBox (and other related UI elements) is able to limit its layout and drawing work to the specific list items that have been added/removed/replaced.
Basically, the Demo class should look like this:
```C#
public class Demo
{
public int Value { get; set; } = 2;
public ObservableCollection<int> AllValues { get; set; } = new ObservableCollection<int> { 1, 2 };
}
```
and get rid of the (now pointless) OnPropertyChanged notification:
```C
private void DoIncrement()
{
_demo.Value++;
_demo.AllValues.Add(_demo.Value);
}
```

`List<T>` is not observable. In other words, `List<T>` does not offer a mechanism through which it could signal that its content has changed.
Use [`ObservableCollection<T>`](https://docs.microsoft.com/en-us/dotnet/api/system.collections.objectmodel.observablecollection-1) instead. As its type name suggests, using it instead of `List<T>` will allow ListBox to listen to change notifications of ObservableCollection<T>. This basically allows the ListBox to _automatically_ update whenever items are added to, removed from or replaced in the ObservableCollection<T>.
While Alexei's answer will work for simple cases, note that replacing the List<T> instance and raising a respective property change event will trigger a **full** re-evaluation of **all** list items by the ListBox. Depending on the complexity of the GUI (binding relationships, templates, etc...), specifically the work required to arrange and draw the representation(s) of an item in the UI, this approach possibly might have a noticable performance impact when the list contains more than a few dozen items.
Using `ObservableCollection<T>` will **not** require raising the property change event. It also will normally also not suffer from the same potential performance impact, since the ObservableCollection<T> typically tells _which_ items have been added to, removed from or replaced in it, thus the ListBox (and other related UI elements) is able to limit its layout and drawing work to the specific list items that have been added/removed/replaced.
Basically, the Demo class should look like this:
```C#
public class Demo
{
public int Value { get; set; } = 2;
public ObservableCollection<int> AllValues { get; set; } = new ObservableCollection<int> { 1, 2 };
}
```
and get rid of the (now pointless) OnPropertyChanged notification:
```C
private void DoIncrement()
{
_demo.Value++;
_demo.AllValues.Add(_demo.Value);
}
```

#4: Post edited by

elgonzo‭ · 2022-03-28T09:58:06Z (about 2 years ago)

Copy Link

Raw

Markdown

`List<T>` is not observable. In other words, `List<T>` does not offer a mechanism through which it could signal that its content has changed.
Use [`ObservableCollection<T>`](https://docs.microsoft.com/en-us/dotnet/api/system.collections.objectmodel.observablecollection-1) instead. As its type name suggests, using it instead of `List<T>` will allow ListBox to listen to change notifications of ObservableCollection<T>. This basically allows the ListBox to _automatically_ update whenever items are added to, removed from or replaced in the ObservableCollection<T>.
While Alexei's answer will work for simple cases (i am ignoring a potential issue with your particular OnPropertyChanged invocation here, see the last paragraphs of my answer addressing that particular issue), note that replacing the List<T> instance and raising a respective property change event will trigger a **full** re-evaluation of **all** list items by the ListBox. Depending on the complexity of the GUI (binding relationships, templates, etc...) this approach possibly might have a noticable performance impact when the list contains more than a few dozen items.
Using `ObservableCollection<T>` will **not** require raising the property change event. It also will normally also not suffer from the same potential performance impact, since the ObservableCollection<T> typically tells _which_ items have been added to, removed from or replaced in it, thus the ListBox (and other related UI elements) is able to limit its layout and drawing work to the specific list items that have been added/removed/replaced.
Basically, the Demo class should look like this:
```C#
public class Demo
{
public int Value { get; set; } = 2;
public ObservableCollection<int> AllValues { get; set; } = new ObservableCollection<int> { 1, 2 };
}
```
and get rid of the (now pointless) OnPropertyChanged notification:
```C
private void DoIncrement()
{
_demo.Value++;
_demo.AllValues.Add(_demo.Value);
}
```
~~ ~~
~~The (potential) issue with your OnPropertyChanged invocation~~
Raising the property change notification on the _Demo_ property quite possibly would not have worked anyway, not even with Alexei's answer. If i remember correctly, WPF bindings -- or perhaps rather WPF's UI elements -- are often smart in detecting whether a bound property value has actually changed (to avoid unnecessary and potentially costly UI updates and refreshes). Thus without replacing the actual _Demo_ instance, raising a property change event for the _Demo_ property could quite possibly not trigger anything, simply because the value of the _Demo_ property has not changed (its value being a reference to the given _Demo_ object instance).
Now, in a scenario where you actually want to notify about a change of a property _in_ the Demo object, how would you do it then? By making the Demo class observable by having it implement [`INotifyPropertyChanged`](https://docs.microsoft.com/en-us/dotnet/api/system.componentmodel.inotifypropertychanged) (or let the Demo class derive from a base type that provides the necessary INotifyPropertyChanged implementation) and letting it raise PropertyChange event notifications in the setters of its properties.

`List<T>` is not observable. In other words, `List<T>` does not offer a mechanism through which it could signal that its content has changed.
Use [`ObservableCollection<T>`](https://docs.microsoft.com/en-us/dotnet/api/system.collections.objectmodel.observablecollection-1) instead. As its type name suggests, using it instead of `List<T>` will allow ListBox to listen to change notifications of ObservableCollection<T>. This basically allows the ListBox to _automatically_ update whenever items are added to, removed from or replaced in the ObservableCollection<T>.
While Alexei's answer will work for simple cases, note that replacing the List<T> instance and raising a respective property change event will trigger a **full** re-evaluation of **all** list items by the ListBox. Depending on the complexity of the GUI (binding relationships, templates, etc...) this approach possibly might have a noticable performance impact when the list contains more than a few dozen items.
Using `ObservableCollection<T>` will **not** require raising the property change event. It also will normally also not suffer from the same potential performance impact, since the ObservableCollection<T> typically tells _which_ items have been added to, removed from or replaced in it, thus the ListBox (and other related UI elements) is able to limit its layout and drawing work to the specific list items that have been added/removed/replaced.
Basically, the Demo class should look like this:
```C#
public class Demo
{
public int Value { get; set; } = 2;
public ObservableCollection<int> AllValues { get; set; } = new ObservableCollection<int> { 1, 2 };
}
```
and get rid of the (now pointless) OnPropertyChanged notification:
```C
private void DoIncrement()
{
_demo.Value++;
_demo.AllValues.Add(_demo.Value);
}
```

#3: Post edited by

elgonzo‭ · 2022-03-28T09:57:13Z (about 2 years ago)

Copy Link

Raw

Markdown

`List<T>` is not observable. In other words, `List<T>` does not offer a mechanism through which it could signal that its content has changed.
Use [`ObservableCollection<T>`](https://docs.microsoft.com/en-us/dotnet/api/system.collections.objectmodel.observablecollection-1) instead. As its type name suggests, using it instead of `List<T>` will allow ListBox to listen to change notifications of ObservableCollection<T>. This basically allows the ListBox to _automatically_ update whenever items are added to, removed from or replaced in the ObservableCollection<T>.
While Alexei's answer will work for simple cases (i am ignoring a potential issue with your particular OnPropertyChanged invocation here, see the last paragraphs of my answer addressing that particular issue), note that replacing the List<T> instance and raising a respective property change event will trigger a **full** re-evaluation of **all** list items by the ListBox. Depending on the complexity of the GUI (binding relationships, templates, etc...) this approach possibly might have a noticable performance impact when the list contains more than a few dozen items.
Using `ObservableCollection<T>` will **not** require raising the property change event. It also will normally also not suffer from the same potential performance impact, since the ObservableCollection<T> typically tells _which_ items have been added to, removed from or replaced in it, thus the ListBox (and other related UI elements) is able to limit its layout and drawing work to the specific list items that have been added/removed/replaced.
Basically, the Demo class should look like this:
```C#
public class Demo
{
public int Value { get; set; } = 2;
public ObservableCollection<int> AllValues { get; set; } = new ObservableCollection<int> { 1, 2 };
}
```
and get rid of the (now pointless) OnPropertyChanged notification:
```C
private void DoIncrement()
{
_demo.Value++;
_demo.AllValues.Add(_demo.Value);
}
```
The (potential) issue with your OnPropertyChanged invocation
Raising the property change notification on the _Demo_ property quite possibly would not have worked anyway, not even with Alexei's answer. If i remember correctly, WPF bindings -- or perhaps rather WPF's UI elements -- are often smart in detecting whether a bound property value has actually changed (to avoid unnecessary and potentially costly UI updates and refreshes). Thus without replacing the actual _Demo_ instance, raising a property change event for the _Demo_ property could quite possibly not trigger anything, simply because the value of the _Demo_ property has not changed (its value being a reference to the given _Demo_ object instance).
Now, in a scenario where you actually want to notify about a change of ta property _in_ the Demo object, how would you do it then? By making the Demo class observable by having it implement [`INotifyPropertyChanged`](https://docs.microsoft.com/en-us/dotnet/api/system.componentmodel.inotifypropertychanged) (or let the Demo class derive from a base type that provides the necessary INotifyPropertyChanged implementation) and letting it raise PropertyChange event notifications in the setters of its properties.

`List<T>` is not observable. In other words, `List<T>` does not offer a mechanism through which it could signal that its content has changed.
Use [`ObservableCollection<T>`](https://docs.microsoft.com/en-us/dotnet/api/system.collections.objectmodel.observablecollection-1) instead. As its type name suggests, using it instead of `List<T>` will allow ListBox to listen to change notifications of ObservableCollection<T>. This basically allows the ListBox to _automatically_ update whenever items are added to, removed from or replaced in the ObservableCollection<T>.
While Alexei's answer will work for simple cases (i am ignoring a potential issue with your particular OnPropertyChanged invocation here, see the last paragraphs of my answer addressing that particular issue), note that replacing the List<T> instance and raising a respective property change event will trigger a **full** re-evaluation of **all** list items by the ListBox. Depending on the complexity of the GUI (binding relationships, templates, etc...) this approach possibly might have a noticable performance impact when the list contains more than a few dozen items.
Using `ObservableCollection<T>` will **not** require raising the property change event. It also will normally also not suffer from the same potential performance impact, since the ObservableCollection<T> typically tells _which_ items have been added to, removed from or replaced in it, thus the ListBox (and other related UI elements) is able to limit its layout and drawing work to the specific list items that have been added/removed/replaced.
Basically, the Demo class should look like this:
```C#
public class Demo
{
public int Value { get; set; } = 2;
public ObservableCollection<int> AllValues { get; set; } = new ObservableCollection<int> { 1, 2 };
}
```
and get rid of the (now pointless) OnPropertyChanged notification:
```C
private void DoIncrement()
{
_demo.Value++;
_demo.AllValues.Add(_demo.Value);
}
```
The (potential) issue with your OnPropertyChanged invocation
Raising the property change notification on the _Demo_ property quite possibly would not have worked anyway, not even with Alexei's answer. If i remember correctly, WPF bindings -- or perhaps rather WPF's UI elements -- are often smart in detecting whether a bound property value has actually changed (to avoid unnecessary and potentially costly UI updates and refreshes). Thus without replacing the actual _Demo_ instance, raising a property change event for the _Demo_ property could quite possibly not trigger anything, simply because the value of the _Demo_ property has not changed (its value being a reference to the given _Demo_ object instance).
Now, in a scenario where you actually want to notify about a change of a property _in_ the Demo object, how would you do it then? By making the Demo class observable by having it implement [`INotifyPropertyChanged`](https://docs.microsoft.com/en-us/dotnet/api/system.componentmodel.inotifypropertychanged) (or let the Demo class derive from a base type that provides the necessary INotifyPropertyChanged implementation) and letting it raise PropertyChange event notifications in the setters of its properties.

#2: Post edited by

elgonzo‭ · 2022-03-28T09:55:44Z (about 2 years ago)

Copy Link

Raw

Markdown

`List<T>` is not observable. In other words, `List<T>` does not offer a mechanism through which it could signal that its content has changed.
Use [`ObservableCollection<T>`](https://docs.microsoft.com/en-us/dotnet/api/system.collections.objectmodel.observablecollection-1) instead. As its type name suggests, using it instead of `List<T>` will allow ListBox to listen to change notifications of ObservableCollection<T>. This basically allows the ListBox to _automatically_ update whenever items are added to, removed from or replaced in the ObservableCollection<T>.
While Alexei's answer will work for simple cases (i am ignoring a potential issue with your particular OnPropertyChanged invocation here, see the last paragraphs of my answer addressing that particular issue), note that replacing the List<T> instance and raising a respective property change event will trigger a **full** re-evaluation of **all** list items by the ListBox. Depending on the complexity of the GUI (binding relationships, templates, etc...) this approach possibly might have a noticable performance impact when the list contains more than a few dozen items.
Using `ObservableCollection<T>` will **not** require raising the property change event. It also will normally also not suffer from the same potential performance impact, since the ObservableCollection<T> typically tells _which_ items have been added to, removed from or replaced in it, thus the ListBox (and other related UI elements) is able to limit its layout and drawing work to the specific list items that have been added/removed/replaced.
Basically, the Demo class should look like this:
```C#
public class Demo
{
public int Value { get; set; } = 2;
public ObservableCollection<int> AllValues { get; set; } = new ObservableCollection<int> { 1, 2 };
}
```
and get rid of the (now pointless) OnPropertyChanged notification:
```C
private void DoIncrement()
{
_demo.Value++;
_demo.AllValues.Add(_demo.Value);
}
```
The (potential) issue with your OnPropertyChanged invocation
Raising the property change notification on the _Demo_ property quite possibly would not have worked anyway, not even with Alexei's answer. If i remember correctly, WPF bindings -- or perhaps rather WPF's UI elements -- are often smart in detecting whether a bound property value has actually changed (to avoid unnecessary and potentially costly UI updates and refreshes). Thus without replacing the actual _Demo_ instance, raising a property change event for the _Demo_ property could quite possibly not trigger anything, simply because the value of the _Demo_ property has not changed (its value being a reference to the given _Demo_ object instance).
Now, in a scenario where you actually want to notify about a change of ta property _in_ the Demo object, how would you do it then? By making the Demo class observable by having it implement [`INotifyPropertyChanged`](https://docs.microsoft.com/en-us/dotnet/api/system.componentmodel.inotifypropertychanged) (or let the Demo class derive from a base type that provides the necessary IPropertyChanged implementation) and letting it raise PropertyChange event notifications in the setters of its properties.

`List<T>` is not observable. In other words, `List<T>` does not offer a mechanism through which it could signal that its content has changed.
Use [`ObservableCollection<T>`](https://docs.microsoft.com/en-us/dotnet/api/system.collections.objectmodel.observablecollection-1) instead. As its type name suggests, using it instead of `List<T>` will allow ListBox to listen to change notifications of ObservableCollection<T>. This basically allows the ListBox to _automatically_ update whenever items are added to, removed from or replaced in the ObservableCollection<T>.
While Alexei's answer will work for simple cases (i am ignoring a potential issue with your particular OnPropertyChanged invocation here, see the last paragraphs of my answer addressing that particular issue), note that replacing the List<T> instance and raising a respective property change event will trigger a **full** re-evaluation of **all** list items by the ListBox. Depending on the complexity of the GUI (binding relationships, templates, etc...) this approach possibly might have a noticable performance impact when the list contains more than a few dozen items.
Using `ObservableCollection<T>` will **not** require raising the property change event. It also will normally also not suffer from the same potential performance impact, since the ObservableCollection<T> typically tells _which_ items have been added to, removed from or replaced in it, thus the ListBox (and other related UI elements) is able to limit its layout and drawing work to the specific list items that have been added/removed/replaced.
Basically, the Demo class should look like this:
```C#
public class Demo
{
public int Value { get; set; } = 2;
public ObservableCollection<int> AllValues { get; set; } = new ObservableCollection<int> { 1, 2 };
}
```
and get rid of the (now pointless) OnPropertyChanged notification:
```C
private void DoIncrement()
{
_demo.Value++;
_demo.AllValues.Add(_demo.Value);
}
```
The (potential) issue with your OnPropertyChanged invocation
Raising the property change notification on the _Demo_ property quite possibly would not have worked anyway, not even with Alexei's answer. If i remember correctly, WPF bindings -- or perhaps rather WPF's UI elements -- are often smart in detecting whether a bound property value has actually changed (to avoid unnecessary and potentially costly UI updates and refreshes). Thus without replacing the actual _Demo_ instance, raising a property change event for the _Demo_ property could quite possibly not trigger anything, simply because the value of the _Demo_ property has not changed (its value being a reference to the given _Demo_ object instance).
Now, in a scenario where you actually want to notify about a change of ta property _in_ the Demo object, how would you do it then? By making the Demo class observable by having it implement [`INotifyPropertyChanged`](https://docs.microsoft.com/en-us/dotnet/api/system.componentmodel.inotifypropertychanged) (or let the Demo class derive from a base type that provides the necessary INotifyPropertyChanged implementation) and letting it raise PropertyChange event notifications in the setters of its properties.

#1: Post edited by

elgonzo‭ · 2022-03-28T09:55:15Z (about 2 years ago)

Copy Link

Raw

Markdown

`List<T>` is not observable. In other words, `List<T>` does not offer a mechanism through which it could signal that its content has changed.
Use [`ObservableCollection<T>`](https://docs.microsoft.com/en-us/dotnet/api/system.collections.objectmodel.observablecollection-1) instead. As its type name suggests, using it instead of `List<T>` will allow ListBox to listen to change notifications of ObservableCollection<T>. This basically allows the ListBox to _automatically_ update whenever items are added to, removed from or replaced in the ObservableCollection<T>.
While Alexei's answer will work for simple cases (i am ignoring a potential issue with your particular OnPropertyChanged invocation here, see the last paragraphs of my answer addressing that particular issue), note that replacing the List<T> instance and raising a respective property change event will trigger a **full** re-evaluation of **all** list items by the ListBox. Depending on the complexity of the GUI (binding relationships, templates, etc...) this approach possibly might have a noticable performance impact when the list contains more than a few dozen items.
Using `ObservableCollection<T>` will **not** require raising the property change event. It also will normally also not suffer from the same potential performance impact, since the ObservableCollection<T> typically tells _which_ items have been added to, removed from or replaced in it, thus the ListBox (and other related UI elements) is able to limit its layout and drawing work to the specific list items that have been added/removed/replaced.
Basically, the Demo class should look like this:
```C#
public class Demo
{
public int Value { get; set; } = 2;
public ObservableCollection<int> AllValues { get; set; } = new ObservableCollection<int> { 1, 2 };
}
```
and get rid of the (now pointless) OnPropertyChanged notification:
```C
private void DoIncrement()
{
_demo.Value++;
_demo.AllValues.Add(_demo.Value);
}
```
The (potential) issue with your OnPropertyChanged invocation
Raising the property change notification on the _Demo_ property quite possibly would not have worked anyway, not even with Alexei's answer. If i remember correctly, WPF bindings -- or perhaps rather WPF's UI elements -- are often smart in detecting whether a bound property value has actually changed (to avoid unnecessary and potentially costly UI updates and refreshes). Thus without replacing the actual _Demo_ instance, raising a property change event for the _Demo_ property could quite possibly not trigger anything, simply because the value of the _Demo_ property has not changed (its value being a reference to the given _Demo_ object instance).
Now, in a scenario where you actually want to notify about a change of ta property _in_ the Demo object, how would you do it then? By making the Demo class observable by having it implement `IPropertyChanged` and letting it raise PropertyChange event notifications in the setters of its properties (or let the Demo class derive from a base type that provides the necessary IPropertyChanged implementation).

`List<T>` is not observable. In other words, `List<T>` does not offer a mechanism through which it could signal that its content has changed.
Use [`ObservableCollection<T>`](https://docs.microsoft.com/en-us/dotnet/api/system.collections.objectmodel.observablecollection-1) instead. As its type name suggests, using it instead of `List<T>` will allow ListBox to listen to change notifications of ObservableCollection<T>. This basically allows the ListBox to _automatically_ update whenever items are added to, removed from or replaced in the ObservableCollection<T>.
While Alexei's answer will work for simple cases (i am ignoring a potential issue with your particular OnPropertyChanged invocation here, see the last paragraphs of my answer addressing that particular issue), note that replacing the List<T> instance and raising a respective property change event will trigger a **full** re-evaluation of **all** list items by the ListBox. Depending on the complexity of the GUI (binding relationships, templates, etc...) this approach possibly might have a noticable performance impact when the list contains more than a few dozen items.
Using `ObservableCollection<T>` will **not** require raising the property change event. It also will normally also not suffer from the same potential performance impact, since the ObservableCollection<T> typically tells _which_ items have been added to, removed from or replaced in it, thus the ListBox (and other related UI elements) is able to limit its layout and drawing work to the specific list items that have been added/removed/replaced.
Basically, the Demo class should look like this:
```C#
public class Demo
{
public int Value { get; set; } = 2;
public ObservableCollection<int> AllValues { get; set; } = new ObservableCollection<int> { 1, 2 };
}
```
and get rid of the (now pointless) OnPropertyChanged notification:
```C
private void DoIncrement()
{
_demo.Value++;
_demo.AllValues.Add(_demo.Value);
}
```
The (potential) issue with your OnPropertyChanged invocation
Raising the property change notification on the _Demo_ property quite possibly would not have worked anyway, not even with Alexei's answer. If i remember correctly, WPF bindings -- or perhaps rather WPF's UI elements -- are often smart in detecting whether a bound property value has actually changed (to avoid unnecessary and potentially costly UI updates and refreshes). Thus without replacing the actual _Demo_ instance, raising a property change event for the _Demo_ property could quite possibly not trigger anything, simply because the value of the _Demo_ property has not changed (its value being a reference to the given _Demo_ object instance).
Now, in a scenario where you actually want to notify about a change of ta property _in_ the Demo object, how would you do it then? By making the Demo class observable by having it implement [`INotifyPropertyChanged`](https://docs.microsoft.com/en-us/dotnet/api/system.componentmodel.inotifypropertychanged) (or let the Demo class derive from a base type that provides the necessary IPropertyChanged implementation) and letting it raise PropertyChange event notifications in the setters of its properties.

Communities

Post History