Better late than never, here's the 3rd and final part of the loosely coupled eventing in Silverlight series - and finally the code to download.

Event Publishers
Simply put, any method that is a member of a control can be an event publisher - but most commonly you'll probably be dispatching some event from within an event handler.  Indeed, this is the example we'll use from the demonstration application.

private void Button_Click( object sender, RoutedEventArgs e )
{
    this.Dispatch( "local://TestEvent" );
}

First a quick discussion of the code above. You will recognise the "Dispatch" method as one of the extension methods we defined earlier for Control.  The most basic signature of the Dispatch method (of which there are a few overloads), takes an event URI and that's all - the method will be invoked for you with no further notification (fire and forget if you will).  In the event that you want to be notified when the method subscribers have completed, this is where the EventCallBack comes in to play.  This allows you to define a method that will be notified and passed the result of whatever event handler fired. The EventCallBack delegate itself returns object, so you can pass back whatever type/value you wish to utilise in your local method and up-cast it to whatever is appropriate.  So, if we wanted to define a callback that would be notified with the result of the event that was executed you would add an additional parameter to the Dispatch method, and provide the implementation.  I've included the signature of the EventCallBack delegate below for completeness.

public delegate void EventCallBack( object result );
... 
private void Button_Click( object sender, RoutedEventArgs e )
{
    this.Dispatch( "local://TestEvent", new EventCallBack( CallBack ) );
}
private void CallbackMethod( object result )
{
    CallBackInfo.Text = result.ToString();
}

That's all there really is to it, simple and lightweight loosely coupled eventing system for Silverlight.  There are a number of notable additions that will be coming in future versions of the framework, specifically:

• An asynchronous callback mechanism utilising the BackgroundWorker to prevent long running operations blocking (the current method invocation is serial in nature - not totally ideal)
• Parallel execution of events with the same priority
• Maybe generic type support on EventCallBack to clean up the callback methods and apply a little more type safety to your called methods, other than "object result"

Hopefully this series of posts will go some way to explaining the thinking (as will the example solutions) but if you have any questions/concerns or are interested in contributing to this framework, please get in touch.

Download
The V1.0 release project is available to download now from CodePlex : http://www.codeplex.com/designtek