Referred URL - http://www.silverlightshow.net/items/Routed-Events-in-Silverlight.aspx

With the Windows Presentation Foundation a new type of events were introduced - the RoutedEvents. They have provided the developer with entirely new approach to the eventing and the event handling. Those of you who are already at the WPF and have experience with the routing of events may found this article useless, but I believe that it can be a good starting point for everyone who makes his first steps in the event routing and more specially in the Silverlight event routing.

Routed events basics

Before explaining the routed events you have to understand the element tree (also known as visual tree), that is typical for every WPF or Silverlight application. It consists of the controls hosted by the application and their parent-child relationships. For example:

<UserControl>

    <Grid>

        <StackPanel>

            <TextBlock />

            <TextBox />

            <Button />

        </StackPanel>

    </Grid>

</UserControl>

Don't Miss

• Silverlight Toolkit Overview
  
• Attached Properties in Silverlight
  
• Tip: How to declare a dependency property in Silverlight?
  
• Asynchronous Silverlight - Execute on the UI thread

The routed events are directly connected with the visual tree. It is used to propagate the event upwards or downwards on it, so the event could be handled by controls that are different then the control that originally raised the event.

There are three types of RoutedEvents - direct, tunneling, and bubbling.

Direct

This type of routed events can be handled only by the controls that had raised them. They are very similar to the events we are familiar with from WinForms and ASP.NET.

Tunneling

By this type of events, first the handlers of the root element of the visual tree are invoked and then the event travels through the child elements till it reaches the one that originally has raised it.

Bubbling

This type of events is first handled by their source and then the event handlers of the parent elements are invoked till the event reaches the root element of the visual tree.

The Handled property

Another basic thing is that the event arguments of every routed event have a Handled property. When set to true in the event handler the event won't propagate further in the visual tree.

RoutedEvents in Silverlight

The things explained above are fully in force for WPF, but for the Silverlight they are a little bit different. There are some differences between the routed events in Silverlight and WPF. Here are the most important of them:

• You cannot create custom RoutedEvents in Silverlight. In WPF to create a custom event of this type we useEventManager, but in Silverlight it's not available. There still is a way out, but we'll discuss it later on in the article.
  
• The only type of routed events in Silverlight is the bubbling event. Such events for example are theMouseLeftButtonDown and the MouseLeftButtonUp.
  
• The control specific events don't bubble - for example the Click event of the Button control. This one sounds pretty logical - why to propagate an event through visual tree, when it can be handled only by a specific type of controls?

Here is a simple example (with source code) that will illustrate the behavior of the bubbling events in Silverlight. For it I have used the MouseLeftButtonUp and MouseLeftButtonDown events.

When I handle the MouseLeftButtonUp I write the name of the control that had handled it in the list and onMouseLeftButtonDown I clear the list. In the handlers of the ListBox for these two events I set the handled property to true, because I don't want the events raised by this control to be handled further in the visual tree. The same I have done with the handler for the MouseLeftButtonDown event - I need to clear the list once.

Note! Use the routed events where needed and be sure to stop the events you don't need to propagate through the visual tree, because this might cause faults and malfunctions in your application. For example the LayoutRoot is listening for an event that is raised in a specific part of the tree (the rectangle), but the event can also be raised in other parts of the tree (the ListBox).If we let the event, raised by the ListBox, to propagate to the LayoutRoot, the last will handle it, which causes the incorrect behaviour of the application.

Telerik RadControls for Silverlight and the EventManager

If you didn't know, the Telerik RadControls for Silverlight implement routed events in the way they are in WPF. Almost all of the events used there are RoutedEvents and maybe you'll ask how they made custom RoutedEvents, when Silverlight doesn't support creation of custom RoutedEvents? To overcome the limitation they introduce the EventManager,RoutedEvent and RoutingStrategy types in their controls. Those who are familiar with WPF won't be surprised to see these three here. The functionality from the WPF is mirrored exactly the same, so the use in Silverlight is identical. If you have the RadControls at hand and need your application to support custom routed events you can find a great use of them. You can read more about that in Hristo Hristov’s post.

Conclusion

The routed events are a very powerful mechanism that can improve the functionality of our applications a lot. There are some differences between their appearance in Silverlight and WPF, but let's don't forget that Silverlight is a subset of WPF and it still has a long way to go. But I was pretty impressed by the bubbling events and I will surely find them useful for my future development.

Referred URL

http://cm-bloggers.blogspot.com/2010/01/first-steps-with-silverlight-bing-maps.html

-> To use the Silverlight Bing Maps control, you need to sign up at the Bing Maps Account Center and obtain a key.

-> Download and install the Bing Maps control.

-> Then create a new Silverlight application and add a reference to the assemblies provided with the control as shown here:

XAML File

<UserControl x:Class="BingMaps.MainPage"

xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

xmlns:d="http://schemas.microsoft.com/expression/blend/2008"

xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"

xmlns:m="clr-namespace:Microsoft.Maps.MapControl;assembly=Microsoft.Maps.MapControl"

mc:Ignorable="d"

d:DesignHeight="750" d:DesignWidth="700" Width="Auto" Height="Auto">

<m:Map Name="map" CredentialsProvider="Place your Bing Key" Width="700" Height="700" />

</UserControl>

private void b1_Click(object sender, RoutedEventArgs e)

        {

Uri url = new Uri("../Feed.xml", UriKind.Relative);

WebClient client = new WebClient();

            client.DownloadStringCompleted += new DownloadStringCompletedEventHandler(client_DownloadStringCompleted);

            client.DownloadStringAsync(url);

        }

void client_DownloadStringCompleted(object sender, DownloadStringCompletedEventArgs e)

        {

if (e.Error == null)

            {

//Reads XML and Populates the Pushpins in Map

StringReader stream = new StringReader(e.Result);

XmlReader reader = XmlReader.Create(stream);

                reader.MoveToContent();

while (reader.Read())

                {

if (reader.NodeType == XmlNodeType.Element && reader.Name == "entry")

                    {

//Adds Tooltip

var tooltipText = "Unkown";

                        tooltipText = reader.GetAttribute("title");

                        tooltipText = tooltipText + Environment.NewLine + reader.GetAttribute("description");

//Adds Pushpin pertaining to Longitude and Latitude

string[] loc = reader.ReadInnerXml().Split(" ".ToCharArray());

double lat = Double.Parse(loc[0]);

double lon = double.Parse(loc[1]);

Pushpin p = new Pushpin();

                        p.Location = new Location(lat, lon);

                        tooltipText = tooltipText + Environment.NewLine + "Latitude - " + lat + Environment.NewLine +"Longitude - " + lon;

                        System.Windows.Controls.ToolTipService.SetToolTip(p, tooltipText);

                        p.Cursor = Cursors.Hand;

                        map.Children.Add(p);

                    }

if (reader.NodeType == XmlNodeType.EndElement && reader.Name == "entries")

                    {

break;

                    }

                }

                reader.Close();

            }

        }

Note - If map is not showing and throwing ‘Unable to connect server’ error. In Internet options check the proxy settings and enable‘Automatically detect settings’

Referred URL

http://www.devtoolshed.com/explanation-cross-domain-and-client-access-policy-files-silverlight

Taking some of the good ideas from Adobe Flash in regards to security policy, Silverlight has implemented a similar security model to block unauthorized cross domain network calls. This plugs a potential security hole where a malicious Silverlight application could run on a page the user is viewing and make API and network calls to domains that the user is not on without his or her knowledge. Microsoft has a quick write-up on some of the security issues this solves here: http://msdn.microsoft.com/en-us/library/cc197955(VS.95).aspx.

Commonly, this issue is usually encountered in Silverlight when you see an exception like this:

An error occurred while trying to make a request to URI "http://localhost/myservice.asmx". This could be due to attempting to access a service in a cross-domain way without a proper cross-domain policy in place, or a policy that is unsuitable for SOAP services.

In order for Silverlight to call a remote resource on a different domain from where the XAP file was served such as a Web Service or RSS feed, the domain where the service or feed resides must grant access to the Silverlight application. The way this is done is using an XML file with the name "clientaccesspolicy.xml" or "crossdomain.xml".

As the above diagram illustrates, when your Silverlight application communicates with the server that served the application, the communication here is allowed because this is on the same domain from where your app was served. But when your Silverlight application attempts to communicate with a 3rd party remote server, a policy must exist (which is defined in either the "clientaccesspolicy.xml" or "crossdomain.xml" file) that allows this communication. If not policy exists on the domain different from the domain from where your Silverlight app was served, the communication is not allowed (hence the name "cross domain script attacks" because it is communication a-"cross" domains).

Difference between Cross Domain and Client Access Policy files

"crossdomain.xml" was created originally for use with Flash applications. But Silverlight also supports this file. "clientaccesspolicy.xml" is specific to Silverlight and allows you to configure specific access rules for HTTP/HTTPS communication and allowable domains.

To enable communication to a server for a specific Silverlight application, both files do not need to be present. You can choose either one depending on your preference but at least one of the files must be there with the correct rules configured. If you want to enable access for both Silverlight and Flash applications, then you might consider just having a "crossdomain.xml" file (or you could still have both this case).

Both the Cross Domain and the Client Access Policy files are XML but have different elements and format.

Example of Client Access Policy file

Client Access Policy files give you more granular controls over traffic types, access to resources, and specific HTTP header information. The following example will allow any and all request to this web server from Silverlight:

<?xml version="1.0" encoding="utf-8"?>
<access-policy>
  <cross-domain-access>
    <!-- Silverlight 3 or higher requires the http-request-headers attribute. -->
    <policy>
      <allow-from http-request-headers="*">
          <domain uri="http://*" />
          <domain uri="https://*" />
      </allow-from>
      <grant-to>
        <resource path="/" include-subpaths="true"/>
      </grant-to>
    </policy>
  </cross-domain-access>
</access-policy>

You can specify that only a specific file can be accessed. For instance, here we only allow HTTP traffic from any domain and we only allow these requests to serve the "myfile.xml" file:

<access-policy>
  <cross-domain-access>
    <policy>
      <allow-from http-request-headers="*">
        <domain uri="http://*" />
      </allow-from>
      <grant-to>
        <resource path="myfile.xml" include-subpaths="false" />
      </grant-to>
    </policy>
  </cross-domain-access>
</access-policy>

Here we only allow the domains microsoft.com and repeatsys.com access:

<access-policy>
  <cross-domain-access>
    <policy>
      <allow-from http-request-headers="*">
        <domain uri="http://www.microsoft.com" />
        <domain uri="http://www.repeatsys.com" />
      </allow-from>
      <grant-to>
        <resource path="/" include-subpaths="true" />
      </grant-to>
    </policy>
  </cross-domain-access>
</access-policy>

This example shows how to use the wildcard (*) to allow any sub-domain of a specific domain access. Here we are allowing all requests from any sub-domain of devtoolshed.com access:

<access-policy>
  <cross-domain-access>
    <policy>
      <allow-from http-request-headers="*">
        <domain uri="http://*.devtoolshed.com" />
      </allow-from>
      <grant-to>
        <resource path="/" include-subpaths="true" />
      </grant-to>
    </policy>
  </cross-domain-access>
</access-policy>

Example of Cross Domain file

The following example will allow any and all requests to this web server from Flash or Silverlight:

<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy 
  SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
  <allow-access-from domain="*" />
</cross-domain-policy>

Technically, this completely eliminates any security from the cross domain policy so although this is really convenient for development purposes, it should probably not be used in production in most cases.

If you wanted to only allow certain domains to access the system, your file could be configured like this:

<!DOCTYPE cross-domain-policy 
SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
  <allow-access-from domain="www.microsoft.com" />
  <allow-access-from domain="www.devtoolshed.com" />
</cross-domain-policy>

If you wanted to block all access to your server from any Silverlight or Flash application, you could use this code:

<!DOCTYPE cross-domain-policy 
  SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
</cross-domain-policy>

Also note, you can use the wildcard (*) character to handle the situation of multiple sub-domains on a specific domain. For instance, this file shows how to allow all sub-domains from devtoolshed.com to communicate with the server:

<!DOCTYPE cross-domain-policy 
  SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
  <allow-access-from domain="*.devtoolshed.com"/>
</cross-domain-policy>

Where do I put the crossdomain.xml or clientaccesspolicy.xml file?

The crossdomain.xml or clientaccesspolicy.xml MUST be located at the root of your web server. If you put the file(s) in a sub-directory where your website files might be, they don’t count and won’t work. The file(s) need to be in the root of your web server so if your domain is www.devtoolshed.com, then the file(s) should be located at:www.devtoolshed.com/crossdomain.xml or www.devtoolshed.com/clientaccesspolicy.xml respectively.

What is the order that Silverlight requests these files?

When a Silverlight app communicates to a remote server, it first requests the "clientaccesspolicy.xml" file and then if that is not found, it falls back on the "crossdomain.xml" file to check if it exists. If neither does, communication will fail if this request is to a different domain than the one from which the Silverlight app was served from.

A great diagram of the process to request the file is available at:https://community.dynamics.com/blogs/cesardalatorre/comments/9579.aspx

It is a bit confusing at first thought because Silverlight is actually the one that deciphers the policy even though the policy is set and maintained at the web server where the resources that are being requested reside. Once you get over that mental hurdle, the rest is pretty easy to understand.

Domains and sub-domains are different

Also note that when we say "domain" this does not include sub domains. To a Silverlight app, the domains "www.devtoolshed.com" and "fudge.devtoolshed.com" are completely different. They must both be allowed separately. Sub-domains on a specific domain are treated as different domains to cross domain policies.

HTTP and HTTPS are different

HTTP and HTTPS are treated as separate types of requests and must be specifically allowed. Even after doing this, you may still have problems in your Silverlight app if you are running HTTPS and try to make an HTTP call or vice versa so watch out for cross SSL communication (this is kind of a separate issue from the cross domain security issues but worth noting here).