One of the challenges in working with a Silverlight application is dealing with external events other than the typical asynchronous communication used to retrieve data. We usually think of a Silverlight application as a “pull only” client and face the dilemma of trying to “push” data to it to get it do something without direct user intervention.

Recently, when working on some ArcFM™ Silverlight application enhancements, we wanted an external event to change the location of the map that was being displayed. For example, a user might be viewing the asset information of a feature in a web-based system and then want to view that features’ location on the map.

There are a couple of strategies that could be used to accomplish this (e.g. a polling thread), but to provide a more “real-time” experience to the user, we chose to use local messaging via the LocalMessageSender and LocalMessageReceiver classes first introduced in Silverlight 3. Local messaging allows the ability for multiple Silverlight applications (plug-ins) running on a single computer to set up and use a communication channel.

The channel is started by the LocalMessageReceiver and one or more LocalMessageSenders can communicate with it. The receiver can also respond to the original message which promotes a two-way conversation, if needed. The message that is sent can be simple text or complex structures that can be serialized, such as XML or JSON data.

For our fictitious example, we will first create a Silverlight application that contains a single button and embed that into our asset information website. The Silverlight button will act as the local message sender. The ArcFM™ Silverlight application will be the local message receiver. The following diagram illustrates this scenario:

By using the HTML Bridge, you can set up your sender button generically and be able to pass along information from your web page. The HTML Bridge can be used for a variety of interaction between Silverlight and JavaScript, but here we are most concerned with the ability to access elements from the Document Object Model (DOM).

For this example, we know that we have particular attributes of the feature we are viewing in the asset management system and we need to pass them to the message receiver as part of the data payload. This is an important concept with regards to telling the ArcFM™ Silverlight application which feature to zoom to.

As previously mentioned, the data payload that is passed from the sender to the receiver can be as simple as a string. In this case, we may want to pass the feature class and the feature identifier as: “Pole^123”. When the receiver gets the message, it will parse out the feature class and ID in order to set up the searching capabilities of the ArcFM™ Silverlight application (Esri QueryTask) and subsequently set up the displaying of the result in Telvents’ AttributesViewerControl.

This all works pretty slick when the ArcFM™ Silverlight application is already running on the client machine and there are one or more senders hitting it with messages. So what happens when the user hasn’t started the receiver side first?

Well, the message will fail and you will get a SendFailedException as part of the send message completion event. When we get this error, we simply start a new instance of the ArcFM™ Silverlight application, this time sending the message payload as part of the query. This could look like the following: “http://localhost/ArcFMSilverlight/?Pole^123”.

While Telvent is looking into supporting parameters passed into the Silverlight application in the future, we will need to implement our own until that functionality is officially released. A simple check for the parameter(s) can be placed in the Default.aspx.cs , then paired with a key and sent to the Silverlight application along with the standard configuration parameters. Finally, the new key can be processed from the initialization parameters in the ArcFM™ Silverlight application and the processing remains the same as if it received the data from the local message receiver.

All-in-all, this turned out to be a nice little framework for maximizing your use of the Silverlight viewer alongside of your existing applications. It gives an otherwise non-GIS user the ability to visualize the features they are working with in another system.

We hope you’ve found helpful both the technical and practical aspects of this article. If you have further questions about it or wish to engage in some customization of the ArcFM™ Silverlight application, feel free to contact us!