Laurent Bugnion (GalaSoft)

Hi Keith,

Thanks so much for the good words. The SynchWindows demo needs a tiny bit of cleanup (it was actually written with an old version of the messenger), but I will post it ASAP. Stay tuned to the blog, I will put it up there when it is ready in a few days.

Cheers,
Laurent

Hi William,

Prism is great when you need some UI composition features, which it seems like you do. If you do use Prism in your project, then I would rather recommend using Prism (DelegateCommand, EventAggregator) in lieu of MVVM Light (RelayCommand, Messenger).

MVVM Light is lighter and easier to start with; I also think that the API is easier to use than the prism one; but it does not help you with composition.

Another way to do UI composition is to use MVVM Light together with MEF. This is perfect for small composite applications, though it does require more code to compose the regions together. Check Glenn Block's blog for demos with Widgets. This is a cool combination too, though less specialized than Prism is.

I hope this helps you,
Laurent

Hi,

This is a very good idea. I will clean that up and post it on my blog. Thanks for suggesting!

The reason why I didn't do this is that it is a WCF service that I use all the time for demos (I used it in my last year's session at MIX too ;) and I just didn't think of publishing the source.

Cheers,
Laurent

Hi Alexey,

You raise valid concerns. Give me a little more time to write a reply, I will get back to you.

Cheers,
Laurent

Hi,

The Messaging sample is WPF 4. The other samples are Silverlight 4. I understand your concerns about not wanting to use the latest version. Porting the samples to WPF3.5, resp. Silverlight 3 is fairly easy but I am not sure yet when I will be able to do it (I am in a bit of a time crunch right now). Stay posted and I will do my best.

Cheers,
Laurent

Hi Flemming,

The version I used is "Unity Application Block 1.2 for Silverlight.msi" which I downloaded from
http://www.microsoft.com/downloads/details.aspx?FamilyID=0991cedb-953a-4367-a2b6-071e31766b4c&displaylang=en

Then, I just picked the assembly in
C:\Program Files\Microsoft Unity Application Block 1.2 for Silverlight\Bin

Hope this helps,
Laurent

Hi Matt,

I got a blog post in preparation regarding DispatcherHelper. The example you mention is pretty trivial to implement using this class, but I agree that a sample is needed. Stay tuned.

Thanks,
Laurent

Alexey, Flemming,

First, Flemming you are very observant, congrats :) The reason why you don't need to RaiseCanExecuteChanged in WPF is that this platform has a CommandManager class which is observing the UI, and querying CanExecute when the user actuates controls. The CanExecute method is queried very often in WPF. In Silverlight however, the CommandManager class is not there. This is why you need to do it explicitly. For compatibility reasons, the method RaiseCanExecuteChanged is also available in the WPF implementation, but it doesn't do anything.

Regarding the responsibility principle, I tend to agree that this solution is not ideal, because the property is responsible for notifying the Command. Instead, the Command should be responsible for observing the property. This is actually what happens when you implement the ICommand interface yourself, like I show in the ICommand demo. However, because you observe the property (through the PropertyChanged event), you create a strong dependency between the Command and the object that is being observed. In my opinion, this is a losing game, and I prefer to use the RaiseCanExecuteChanged method instead.

I feel that the gain overweighs the loss, since everything remains internal to the view model class.

Note that this is not the only place where this kind of issue arises. You have a similar problem when a property modifies another property. For example, if you have properties FirstName, LastName and FullName: Changing FirstName must raise the PropertyChanged event for FirstName and for FullName. This kind of "cascaded raising" is one of the flaws of the pattern, which I didn't mention at MIX because it is really an advanced concern and I didn't want to confuse people too much. Good that you give me the occasion to write about it here though. That could be a good topic for a blog post.

Thanks a lot guys,
Laurent

Hi Alexey,

And I do not disagree with you :)

As I said, the concerns you raise are completely valid. This is a case of one evil against another. In my opinion, RelayCommand is OK because it is exposed as a property of the ViewModel, its context is the ViewModel, and its status changes internally to the ViewModel. But I completely see your point, and agree with you that it is not ideal.

I think that as long as one is aware of the issue, it is OK to go ahead with this implementation. Should that become too big a concern, the alternative is to not use RelayCommand and instead implement the ICommand interface, which will work in SL and WPF. As usual, development is a matter of informed choice. Our task is to teach beginners and let them understand the issue, which is why a separate blog post about this issue seems like a very good idea.

Thanks for the discussion!
Laurent

Hi Rob,

Your problem comes from a common confusion between the ObservableCollection (OC) role and the item's role.

The OC is responsible for notifying the binding that an item has been added, removed or that the sorting order of the items has changed. This is an implementation of the INotifyCollectionChanged interface. The OC is NOT responsible for notifying a binding that the content of an item's property has changed.

On the other hand, the item is responsible for notifying a binding that one of its properties has changed. This is an implementation of the INotifyPropertyChanged interface.

In your item, make sure that the PropertyChanged event is raised when the property changes. Any binding (for example in a DataTemplate) to that particular property will then be updated correctly.

Hopefully this helps,
Laurent

Hi,

If a propery does not raise PropertyChanged, the binding will be executed once only. It is what we call a "One Time Binding" (as opposed to One Way and Two Way Bindings).

Nested collections work just like non nested collections. If you want to set this collection as the ItemsSource of a list control (such as ItemsControl, ListBox, DataGrid etc...), then the list control will be updated when the CollectionChanged event is raised (which happens automatically when an item is added, removed or the sorting order changes in the ObservableCollection).

However, if you want the OrdersOverdue property to be databound, and this binding to be updated, you need to raise the PropertyChanged event for that particular property. For example (assuming that myOC is an ObservableCollection):

// Somewhere after the OC is constructed
// Subscribe to CollectionChanged for myOC

myOC.CollectionChanged += (s, e) => RaisePropertyChanged("OrdersOverdue");

This line adds an event handler for the CollectionChanged event, and will raise the PropertyChanged event for the OrdersOverdue property. This way, the bindings will be updated. Note that RaisePropertyChanged is not called from within the Setter of the property (since there are none), but from somewhere else in the class. This works fine.

(note: The PropertyChanged event will also be raised, unnecessary, when the sorting order changes in the collection. To prevent this, you can check the NewItems and OldItems properties on the NotifyCollectionChangedEventArgs class passed to the event).

My advice when you work with nested properties/collections: Be methodic. It all works the same, but it is easy to lose the overview. This is one of these cases where a quick UML diagram/sketch might help to understand what's happening ;)

Cheers,
Laurent

Hey Rob,

It is normal that the PropertyChanged event is not raised in the Collection's setter: The collection is probably created only once, which raises the propertychanged event only once. ALl subsequent operations (adding/removing items) is done on an already existing collection, thus only the CollectionChanged event is raised. Does that make sense?

Cheers,
Laurent

Hi,

The source code, as written in the article, is available here:
http://www.galasoft.ch/blogs-all/Resources/MIX10/MIX10-MVVM-Samples.zip

Cheers,
Laurent

Hey Matt,

My opinion is that *showing* the dialog is the responsibility of the View, while *triggering* the dialog and getting the result is the responsibility of the VM. The way I do it, I have the VM require from the View that the dialog be shown, and then handle a callback to get the result.

Based on this, there are multiple ways to do that. One way I like is to use the Messenger class send a DialogMessage (included in the toolkit) to the View, and then handle a callback to get the dialog's result. However, I would like to rework this part in a future version to make it less dependant on UI information, such as the MessabeBoxResult that it returned. Maybe a better strategy can be to inspire yourself from DialogMessage, and build your own message type.

Other approaches involved a dedicated service used to show dialogs. This is not that different, except that instead of sending messages, you invoke methods on the service.

Hope this helps,
Laurent

Hi,

Unity is an IOC container. I recommend you Google this term with Bing, as there are many many posts explaining the advantages of an IOC container. In short, it helps you to compose multiple loose parts of your application together.

As I said in the MIX10 talk, this is not compulsory at all. In fact I probably would not introduce Unity in an application just to create services and ViewModels. But if (as is often the case in applications nowadays) you already use an IOC container (Unity, StructureMap, NInject etc...), you can also take advantage of it for Services and ViewModels composition.

Hope that helps,
Laurent

Hi Fleming,

Sorry for the long delay in replying.

For the Messenger, check the following articles:

http://blog.galasoft.ch/archive/2009/09/27/mvvm-light-toolkit-messenger-v2-beta.aspx
http://blog.galasoft.ch/archive/2009/10/18/clean-shutdown-in-silverlight-and-wpf-applications.aspx

Also check the "what's new in V3" post
http://blog.galasoft.ch/archive/2010/03/16/whatrsquos-new-in-mvvm-light-v3.aspx


Regarding the usage of tokens, I do not have a sample right now, but the usage is pretty straightforward. Simply use the same token when registering and when sending. The token can be a simple value (which is probably the most logical use) but it can also be an object, in which case you must make sure that you are using the same instance when registering and when sending.

I will write more about this, but I currently don't have much time because I am working on my Silverlight 4 book.

Cheers,
Laurent

Hi Jonathan,

Actually this year I was using the Visual Studio toolbox, in which you can drag (or paste) some text from a text file. Then you can name the snippet as you want (I usually give an index and a short description). To make things clearer, I also add some dummy text snippets that I use as separators between sections of the demo.

About that though: Be super careful, because it happened to me before that suddenly the snippets in the toolbox were lost by Studio. I am very careful to keep a simple text file with all the snippets so that I can open it in last minute and copy/paste from there should that be necessary.

If you want a separate tool, Karen Corby has a WPF-based snippet manager on her blog (http://scorbs.com/2008/03/18/snippetmanager/). It works well too, but on a small screen I prefer the Studio toolbox solution. Karen's manager works with other applications too, though, so it's handy to have.

Cheers,
Laurent

Hi Hassan,

You need the Windows Phone 7 tools to open the MvvmLight1 project. If you do not want to install them, just ignore the warning, you can work with the Silverlight project, but the Windows Phone project will just not load or compile.

Cheers,
Laurent

Hassan, it sounds like you need to look into WCF RIA Services. To combine this with MVVM, check Nikhil Kothari's talk at MIX10
http://live.visitmix.com/MIX10/Sessions/CL09

Enjoy,
Laurent

Hi Manuel,

There are two ways to send targeted messages.

1) Send a message to all instances of a given type (or types that implement a given interface):

Messenger.Default.Send<TMessage, TRecipient>(TMessage message) (where TRecipient is a type or an interface)

2) Send a message with a token:

Messenger.Default.Send<TMessage>(TMessage message, object token) (where token can be an object (equality by reference) or a simple value (equality by value). For example, recipient registers with token = 1234, then sender sends with token = 1234, which ensures a point to point communication (if multiple recipients use the same token, they will all get the same message).

Does that make sense?

Cheers,
Laurent

Hi Howard,

That's a good question. It is a pattern I am using quite consistently (saving the callback and other needed elements from the request in the UserState). This helps refactoring, typically when a lambda expression grows too big and I decide to move it into its own method.

Also, even though I do use closures too, it sometimes leaves me with a weird feeling.

But to be honest the real reason here is that I didn't think that much and just applied the usual pattern I use with the UserState.

Does that make sense?

Cheers,
Laurent