We all get clobbered at least once by memory leaks in our shiny new applications. One of the main causes of this is when objects that are expected to be garbage collected are not because we have not (or are unable) to unsubscribe them from the event handlers of longer living (static) objects. The de-facto solution is to implement Microsoft’s ‘WeakEventManager’, but it takes a lot of coding, and adds another layer of complexity to your applications. Wouldn’t it be great to do something a bit easier like: public partial class MainWindow : Window { private EventProxy<RoutedEventHandler> proxy = new EventProxy<RoutedEventHandler>(); public MainWindow() { InitializeComponent(); Loaded += WindowLoaded; }   private void WindowLoaded(object sender, RoutedEventArgs e) { AddPublishers(); var customer = new ... [More]

When I’m building prototypes in WPF or working on a GUI spike in an agile development team I often find it really unproductive to continuously switch between working in XAML (with my designer hat on), and working on the plumbing code (with my C# hat on). Wouldn't it be nice to be able to model my data in XAML, and seamlessly use it with XAML Binding expressions that’ll be valid once the ‘real’ data gets plumbed in. Well, thanks to the dynamic features in CLR v4 this is now a trivial task. Firstly lets look at the XAML – you’ll quickly see the flexibility in using this approach - <Window x:Class="DynamicWPF.MainWindow" xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" xmlns:collections="clr-namespace:System.Collections;assembly=mscorlib" xmlns:sys="clr-namespace:System;assembly=mscorlib"... [More]

A common problem in WPF (& Silverlight) development is when you are working with multiple threads that need to change a collection that is a binding source and implements INotifyCollectionChanged. Basically, the standard ObservableCollection<T> will only allow updates from the dispatcher thread, which means you need to write a lot of code for the worker threads to marshal changes onto the main message pump via the dispatcher. This can be a bit tedious, so I recently wrote a collection that performs all of the necessary marshalling internally, so users of this type do not have to be concerned about thread affinity issues. Also, I decided to use a ReaderWriterLock to provide thread-safety during updates to the collection. Here is my collection class:   public class SafeObservable<T> : IList<T>, INotifyCollectionChanged { private IList<T> collection = new List<T>(); private Dispatcher dispatcher; ... [More]