My client is trying to hook to a usercontrols Loaded Event in the View Model. Basically they want to know when the controls loaded event triggers inside the view model. They are looking for a way to do it without code behind the xaml. Is this even feasible. I am looking into whether I can route the loaded event to the viewmodel in the xaml.
One way of doing it is to use InvokeDataCommand. You'd specify the trigger's EventName as Loaded, and then your command (defined in your VM) would execute when Loaded event is fired.
You need to look into commanding. Silverlight support is fairly weak compared to WPF but it does contain the ICommand interface. You can extend controls to give them command properties or implement them via an attached property. The commands basically invoke themselves once an action has occurred in the UI. They are totally independent of how the UI is built (or at least they should be) and so can be completely unit tested.
Related
Have some experience with WPF and databinding, but completely new to PRISM and MVVM.
I'm working on Prism application where I have a shell and multiple modules.
In my previous WPF application I had a single window datacontext (with all objects I need) which I could then simply databind from any usercontrol inside my window.
In the context of the Prism, what is the proper way to have a single datacontext, let's we call it ShellViewModel and then for all modules to bind to its' objects and properties? So if there is a change in one property in ShellViewModel which is caused by one module, another module can detected that by databinding and then maybe trigger a style?
Probably there is a simple way to do this but I'm new to PRISM and MVVM and completely confused how we can do properly bindings especially when there are multiple modules involved?
Also any source code and examples would be great.
If you have a single source of data, make it available to all your view models as a service.
Register it as a singleton, so that all view models get the same instance. If you need the service to push updates to the view models, make it implement INotifyPropertyChanged and let the view models observe that (done best through a PropertyObserver).
Remember that the view model is the data context of the view, and that it should only communicate data and events between the view and the data source a.k.a. model, but should not own data itself.
Can anyone please explain difference between Triggers, Behaviors and Commands. I tried to search on this, but could not find anything useful.
And would also like to know in which scenario which one should be preferred and which one is used frequently among them?
Behavior is a way of interactivity without writing code. Behaviors makes interactivity much simpler for the designers. In short, a behavior is a reusable piece that encapsulates some functionality that can be attached to an object to extend its built-in interactivity capabilities.
Commands are used to encapsulate a piece of logic, which various Silverlight controls can bind to and execute in response to an event, such as a button being clicked. You can expose a command from a ViewModel as a property and bind the Command property of a control in the View to it. When the control is clicked, the command will be executed.
In MVVM scenarios, triggers are used to notifying the view of an event from a ViewModel.
For example, perhaps the view needs to navigate to another view once a save operation is
complete. You can implement this behavior by raising an event from the ViewModel that the view can listen for by doing either of the following:
• Wiring up an event handler in the view’s code-behind and writing some code to
respond to the event (Not recommended approach)
• Implementing a trigger in the view that listens for the event and responds accordingly
You can see this, this and this for more explanations.
Also, Pro Business Applications with Silverlight 5 is a very good reference for you.
I am using the MVVM pattern in my WPF application. In one of my Views I have a button that when clicked uses Commands to talk to its ViewModel. The problem I have is that I need the ViewModel to then talk to other ViewModels to call some of their public methods. I use IOC (Unity) and inject the container into the first ViewModel, so could access the others by using this. I’m not sure if this fits in with the MVVM concept.
Is it possible for all my ViewModels to somehow subscribe to the one button click?
Are any of these the recommended way of solving this problem or is there a better way?
To explain a bit more about my application, each view is a tab control with several textboxes. On the first tab there is also a button and combobox. The user is free to enter their own data or select an option from the combo. In this instance, if the button is then clicked I need all the tabs to load their textboxes based on the selected item in the combo from the first tab. I somehow need to wire this button click in such a way that the value from the combo is passed to all the related viewmodels.
You can use the EventAggregator. Have the command publish an event that the other ViewModels can subscribe to.
When the event is raised they'll all get the event, without needing for one VM to know the other VMs
Another option is to use Composite Commands instead of a regular command.
Make the command the button uses a composite command, and have the other viewmodels register to that Composite command.
You could go a few ways with this one:
use some kind of eventing framework to notify all subscribers if something happens: eg Prism EventAggregator. For this to work you'll need to set up Prism obviously. There are other (MVVM) frameworks out there which support some kind of event/message system like Caliburn.Micro or MVVMLight
Create a MasterViewModel that contains all the child viewmodels for all the tabs. This way the 'master' can subscribe to the PropertyChanged events from its children and execute the appropriate actions. Or the Master can even contain the commands which you are binding to.
I would recommend using some form of "Messenger" service. By this, I mean a class that implements the "Subscription Pattern."
I'm not sure which MVVM library you might be using, but if you look at the "MVVM Light Toolkit" - which is available on CodePlex - you will find a very light implementation of a Messenger there.
Basically each ViewModel will subscribe to receive a specific notification and your ViewModel with the combo box and button will publish the message when the button is clicked. It is really quite flexible in how you send the messages and your ViewModels don't need to know anything about each other.
If you are using the MVVM lite toolkit from GalaSoft you have access to the Messenger which would allow you to send a message that you can subscribe to in each of your view models.
// Send message from command handler
Messenger.Default.Send<MyMessage>(new MyMessage());
// Register for message in view models.
Messenger.Default.Register<MyMessage>(this, MyMessageReceived);
// Method to do work
private void MyMessageReceived(MyMessage myMessage)
{
// Do Work
}
I have two separate views each containing a ScrollViewer. I want to slave one to the other in terms of scrolling. (Views are being injected using PRISM)
I can do this trivially if they are in the same view. However I seem to be stuck doing it between isolated views. (The views are isolated for a good reason... well I think!)
What I think I want to do is echo the ScrollViewer 'ScrollChangedEvent' to the ViewModel layer then use some linking service to pass a message to the 2nd ViewModel.
However I'm struggling to work out how to drive the 2nd ScrollViewer from the ViewModel without violating MVVM.
Sure I'm missing something obvious so a shove in the right direction would be greatly appreciated.
Thanks
There are several ways to go about this. One would be, as you suggested, to transfer the scroll change to the view model. From there you can use a loose pub/sub mechanism (such as Prism's Event Aggregator) or a shared object that is available to both view models to transmit the event from one view model to the other.
My recommendation would be to use Prism.
When the second view model receives the event, it can publish it to the view using another event the view can directly consume, or through a property (using an attached property you can bind to that calls ScrollViewer.ScrollToVerticalOffset)
Sometimes a Domain Model object with a business logic (DDD) when calling a method an event is fired.
In my situation, a viewmodel (for a given view) encapsulates the domain object and needs to register and react on those domain events (i must use events because that same domain object can be managed by many loosely coupled views along with their viewmodels).
I also need to unregister to those events when that particular context is hidden.
I can handle this register/unregister/dispose in parallel with show/hide/dispose of that view using databinding, programmatically or whatever if the scenario keeps simple enough...
The problem comes when visualization logic comes with DataTemplates.
How can I know when that datatemplate becomes hidden so that I can unregister my events? is it there a better way with wpf to handle this, instead of adding more events?
What is the best practice to handle this scenario in a good MVVM approach?
edit: ok, the problem is structural. sometimes choices made inside the project has forced us to work in an atypical manner... in a good mvvm approach this problem should not happen
I'd be careful in making the ViewModel dependent on the View for making things right.
So what I would do is provide a property (Show? Visible? Open?) on the ViewModel that has a TwoWay binding with the View so the ViewModel can monitor the property.