Further to my previous post, Erik Meijer commented that an overload to the FromEvent method is available to convert from generic event handlers to the specific ones used by much of the BCL. So the code from the previous post would look something like this now:

        #region Ctor
        public MainPage()
        {
            InitializeComponent();

            var mouseEventSource = Observable.FromEvent<MouseEventHandler, MouseEventArgs>(
                eh => new MouseEventHandler(eh),    // Conversion
                eh => this.MouseMove += eh,         // Subscribe
                eh => this.MouseMove -= eh);        // Unsubscribe

            _mouseMoveSubscription = mouseEventSource.Subscribe(OnMouseMove);
        }
        #endregion

        private void OnMouseMove(Event<MouseEventArgs> e)
        {
            var position = e.EventArgs.GetPosition(this);

            Debug.WriteLine("Mouse moved.  Position: {0}.", position);
        }

This solves one of my major gripes. Exciting times!

<rant>

Thought I’d share with you some of my gripes with the ObservableCollection<T> class that forms the basis of just about all data-bindable domain models in WPF and Silverlight.

Firstly why does it not support an AddRange(IEnumerable<T> items) method like other collections?

The EventHandler signature looks like:

private void OnCollectionChanged(object sender, NotifyCollectionChangedEventArgs e)

and NotifyCollectionChangedEventArgs has a property NewItems of type IList.  This implies that you should be able to add multiple items, but the API doesn’t support it.  Infuriating!

More importantly, when you Clear an ObservableCollection you get called on the CollectionChanged event with NotifyCollectionChangedAction.Reset.  However when you look at e.OldItems you’d expect to find the list of items that were cleared, right?  Sadly not.  I often find that I hook into various event handlers in the OnCollectionChanged method.  In order to clear these subscriptions on reset it means that I have to hold a parallel collection of the items in the ObservableCollection.  Not good.

Also, why is there not an ObservableDictionary<TKey, TValue>?  Various people have attempted to implement this, but it should really be part of the framework and understood by data binding.

I’m hopeful that these issues will go away with the BCL changes for the very groovy System.Reactive framework.

</rant>

I’ve just been checking out some of the asynchronous programming stuff that will be shipped with .Net 4.0.  I managed to obtain a preview copy of the System.Reactive.dll by downloading the lates Silverlight Toolkit source.  This seems like very exciting stuff indeed.  Basically turning the whole .Net event infrastructure on its head.  This is based on the observation that we can think of the observer pattern as being the dual of the enumerable pattern.  The power of this is that we can use Linq to enumerate over events just as we do over objects in an enumerable.  Or, in other words, Linq of pushed rather than pulled data.

Check this out for more information:

http://themechanicalbride.blogspot.com/2009/07/introducing-rx-linq-to-events.html

My one criticism of this so far is:

Say you want to create an observer on the MouseMove event on a control.  You’d do something like this:

var mouseEventSource = Observable.FromEvent<MouseEventArgs>(this, “MouseMove”);
var mouseMoveSubscription = mouseEventSource.Subscribe(mea => Debug.WriteLine(“Mouse Moved”));

And this works perfectly.  The only problem… that pesky “MouseMove” parameter when converting the event into and IObservable.  I noticed that there’s an overload of the same method that takes Actions to add and remove the EventHandler.  This would look something like this:

var mouseEventSource = Observable.FromEvent<MouseEventArgs>(eh=>this.MouseMove += eh, eh=>this.MouseMove -= eh);

This looks much nicer as I’m not passing in that ‘orrible string and therefore have compile-time checking of the event.  Only problem with this is that it requires the MouseMove event handler to be a generic EventHandler<MouseEventArgs>.  Sadly, the MouseEventHandler is a delegate in its own right rather than deriving from the generic EventHandler.

This leads me to the following conclusion.  This looks like really interesting technology, but it’ll require a massive overhauling of the .Net base class libraries to be truely useful.