It is clearly more readable, easy to understand and to write !Īs usual, a full project can be found on my Dropbox folder after registration.

TaskScheduler.FromCurrentSynchronizationContext()) Retrieve the persons on another thread.įoreach (var p in t.Result) _persons.Add(p) Private void LoadUpPersonsClick(object sender, RoutedEventArgs e) Here is a an example of this second solution: This is usually what I do even if it’s degrade the code readability because it’s more complex to write. Pass the information to the UI Thread and creates the list on it.

Tell the user to wait, then retrieve the data on a secondary Thread.

I don’t personnaly like this solution because this a kind of a hack and the interface reactivness remains odd.

Retrieve the data on the UI Thread and wait after every add for the UI Thread to update.

In WPF 4.0 you have two different solutions: The loading of the full list is quite long because it requires to go to a database via a WCF services and then to come back with the information. Let’s say that you have an application which display peoples on a list.

In this post we will discover that this is over with WPF 4.5 (and that you’ll love it) !

Then you put the collections creation/feeding on another Thread to free the UI’s one and you realize that it is not possible because : “This type of CollectionView does not support changes to its SourceCollection from a thread different from the Dispatcher thread”. After a few time, you realize that it freezes the application UI and that the users usually don’t like it. To begin, you put everything on the main(the UI one) thread and it works just fine. Collections are a part of every application and their management is maybe the first thing you learn to deal with in WPF. Here is the seventh (OMG !) post on the WPF 4.5 new features. WPF 4.5 – Part 7 : Accessing collections on non-UI Threads

Www dropbox com getspace