I wonder if WPF infrastructure utilizes INotifyPropertyChanging event on binding or its developers have plans to do it in future releases. Appreciate any link to respective information
Edit:
The idea behind my question was that I was recently being unable to cancel SelectionChanged event in DataGrid. Being bound to something like MySelectedProperty in my view-model it listens (I hope) to PropertyChanged("MySelectedProperty") to actually select different row. So I wonder why couldn't it listen to PropertyChanging("MySelectedProperty") to cancel the selection when I set Cancel to true
Related
Working on custom WPF control which is called "MultiSelectTreeView," which inherits from System.Windows.Controls.TreeView. Its purpose is to allow for multi-selecting and dragging and dropping.
The xaml for the view which contains this MultiSelectTreeView control binds an ObservableCollection that is exposed by the underlying view model.
A drag-and-drop operation might possibly involve many remove/add (or move) operations on the ObservableCollection, however I need to encapsulate all of the operations for a single drag-and-drop operation into a command object to support the undo/redoing of the drag-and-drop as a single atomic operation.
When I hook into the ViewModel.ObservableCollection's CollectionChanged event multiple events fire and from the perspective of the ViewModel, there is no way to know if any particular add/remove/move event will exist in isolation or whether it will be a part of a series of events, all related to a single user drag-and-drop.
I can imagine all sorts of wonky solutions, such as giving the MultiSelectTreeView control all sorts of in-depth knowledge of its underlying ViewModel's possible structure (to momentarily unhook the ObservableCollection's CollectionChanged event), but that doesn't feel right at all.
Perhaps I should create my own descendant of ObservableCollection, which supports a .MoveRange() method that only fires one event, or something along those lines.
I'm sure someone with more than just a few weeks of WPF experience could probably suggest a profoundly better solution than these.
I'm not sure if this will help you, but I just ran across it today.
Batch Updates with INotifyCollectionChanged
I have a view that containing a user control.
I want to make the view model to notify the user control to do some action (refresh its' data).
I can pace some bool property in my VM and bind it to the user control so it will trigger it, but I think it's a little abuse of the property.
I feel I missing something, and can't find a solution. I will appreciate any comment.
My solution:
I'm going to solve the problem by registering an event of collection changed in my UserControl, since I'm binding to that control a view of a collection thru CollectionViewSource.
My original problem was how to make a chart control inside the UserControl to get updated when I filtering the data source. After the filtering operation from the VM, an event will raise and I will make the chart to get refresh either in the UserContol's code behind
Since you've indicated MVVM tag solution would be pretty straightforward - just bind control to a data by exposing data items/whatever by ViewModel so any data updates would be automatically dispatched to View via bndings if you would provide INotifyPropertyChanged / INotifyCollectionChanged by a ViewModel.
If you've bound your UserControl correctly, you shouldn't need to manually refresh the data since WPF will automatically update the UI when INotifiyPropertyChanged triggers
That said, if you wish to send a message from the ViewModel to the View, I usually use an messaging system of some kind to keep the Views and ViewModels separate. The two I've used and would recommend are MVVM Light's Messenger, or Microsoft Prism's EventAggregator
Either system will allow your ViewModel to broadcast a message, and your View can subscribe to receive these messages and handle them as needed.
I'm implementing the MVVM pattern in a Silverlight Application that utilizes 3rd party software (ESRI's Silverlight API). This 3rd party control only exists in the XAML:
<esri:Map x:Name="map" ... />
The ViewModel has an ObservableCollection of object which are bound to a ListBox. When a user double clicks on a specific item, the Model (which is bound to a user control inside that ListBox) fires an event which the "Main" view model is subscribed to.
My question is, in the "Main" ViewModel where the esri:Map resides, how do I call functions from this 3rd party control with data from the event (ex. map.ZoomTo( result ); )? The only solution I have so far is to move the event code (in the ListBox user controls) from the ViewModel into the Code-Behind and then subscribe to those events in the "MainPage" xaml and fire the code in the code behind.
Is this the best option utilizing the MVVM pattern??
Sounds like you want either a Blend Trigger or Behavior, depending upon the exact scenario. Here's an introduction to them.
That's a perfectly valid approach for "ViewModel First" MVVM. Another approach is to have the Code-Behind be ViewModel Aware, and directly call methods in the View Model from the event handlers - which is suitable for a "View First" approach to MVVM.
I am a huge fan of separating the whole thing, and using a good MVVM framework like Caliburn.Micro. With a framework like such, you could do something more OOPish, very SOLID, still MVVM, by utilizing a MEF:
Your View would simply trigger events in an Event Aggregator, with a message payload with information to whatever receiver handles it. The View doesn't care who handles the event, all it cares about is to raise the event to the aggregator.
Your View Models would handle whatever events are appropriate for each one. They don't care who raises the event, only that they are in charge of handling events from the Aggregator.
You will find that direct ViewModel first and View first implementations, through event handlers, of MVVM begin to grow cumbersome as your enterprise solition grows: it's scalability is limited.
Here is my problem:
I have DataGridView. It's source is set to the BindingList of my business objects.
Business object implement INotifyPropertyChanged interface. Each time the business object changes DataGridView fires several SelectionChanged events. When I add/remove objects to the DataSource SelectionChanged events are fired too.
I want to use this event to update my view, but it looks horrible with so many events.
Can anyone help please?
Or maybe someone can help me with master-details scenario with DataGridView when binding to the list of business objects?
Thanks for your comment. I've made a little "investigation" and found out that BindingSource.PositionChanged event fits my scenario perfectly.
It is a bit painful to implement master/details scenario with the WinForms' data binding after trying WPF...
I am very new to WPF, and I have a very basic WPF question:
Suppose we have a custom dll with some business logic that fires events such as
ModemIsConnected. On the UI side (.xaml) there is a label that changes its value to OK once that event is fired. I would like to offload the event handling portion (changing label's status and other minor UI tweaks) to a designer. Is it possible to handle events in xaml without creating code-behind?
Thanks!
The simple answer is I don't believe it's possible. There are no doubt things you can do with data binding and the like, but then you're getting beyond the kind of thing you want a designer to be doing.
A couple of options:
Teach the designer the bare minimum of coding an event handler and calling a storyboard. With intellisense and the nice interaction between Blend / Visual Studio you could have someone up and running fairly quickly.
Have them create storyboard animations for any of the 'minor UI tweaks' you require, and then you can hook these up to the event and change your label text with only 3-5 lines of code.
You can have the designer do the UI side without them having to get their hands dirty with code. You could create a class that implements IPropertyNotifyChanged with a boolean property that changes as the modem state changes. The designer can then bind to that property and do fancy triggers, state changes etc etc from within the XAML and the binding system will handle "telling" the UI the value has changed.