StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>Don't create a collection of model objects, and don't implement <code>IntType</code> and <code>Description</code> properties on your (current) view model. And unless you have some other reason to do so, don't implement property-change notification in your model.</p> <p>Instead, make <code>IntTypes</code> a collection of <code>InterestTypeEntityViewModel</code> objects.</p> <p>This class wraps <code>InterestTypeEntity</code>. It exposes <code>IntType</code> and <code>Description</code> properties that a) wrap the underlying <code>InterestTypeEntity</code> properties and b) performs property change notification. If you make its constructor take an <code>InterestTypeEntity</code> argument, it's easy to populate in your view model:</p> <pre><code>IntTypes = new ObservableCollection<InterestTypeEntityViewModel>( DataRepository.InterestTypeEntities.Select(x => new InterestTypeEntityViewModel(x)); </code></pre> <p>Bind the <code>ItemsSource</code> to this collection. (Also, make <code>CurrentIntType</code> a property of type <code>InterestTypeEntityViewModel</code> and raise <code>PropertyChanged</code> when it changes.)</p> <p><strong>Edit:</strong></p> <p>If the owning view model needs to be notified when properties change on the items in its collection, it's pretty simple to make it handle the <code>PropertyChanged</code> events they're raising. In your constructor, add:</p> <pre><code>foreach (InterestTypeEntityViewModel vm in IntTypes) { vm.PropertyChanged += InterestTypeEntityViewModel_PropertyChanged; } </code></pre> <p>and this method:</p> <pre><code>private void InterestTypeEntityViewModel_PropertyChanged(object sender, PropertyChangedEventArgs e) { InterestTypeEntityViewModel vm = (InterestTypeEntityViewModel) sender; // check e.PropertyName and do whatever you need to do here. } </code></pre> <p>Don't forget to unregister the event handler if you remove an object from your collection; otherwise, the child view model objects won't get disposed until the parent one does.</p> <p>Note, by the way, that by implementing the view models this way, you can exercise a lot of control over your updates to the underlying entity model. For instance, you can implement a command in your parent view model that does all of the updates in a single operation, and another one that lets the user discard all of the changes they've made in the UI without performing an update. And all of this logic is very nicely decoupled from the actual presentation layer.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload