1. Get the Bing Maps WPF control.
2. Get a Bing Maps API key.

You MUST have a Bing Maps API key in order to use any of the SOAP services.

For this application we will be using the Geocode Service and the Route Service.  The Geocode service is used to match addresses, places, and geographic entities to latitude and longitude coordinates on the map, as well as return location information for a specified latitude and longitude coordinate.  The Route service is used to generate routes and driving directions based on locations or waypoints.

Now that you have that out of the way let’s write an application. Create a new WPF application targeting the .NET 4.0 framework. Add a reference to the Microsoft.Maps.MapControl.WPF.dll. This will most likely be located in Program Files or Program Files (x86) –> Bing Maps WPF Control –> Beta –> Libraries.

Open up your App.xaml. You need to add an ApplicationIdCredentialsProvider as a resource and enter your ApplicationId:

We need to add the Geocode and Route service to our application.  First, let’s start by adding the Geocode service.  Right click the project and select “Add Service Reference”.  Use the following address:

http://dev.virtualearth.net/webservices/v1/geocodeservice/geocodeservice.svc

Give your service a name. I called mine BingServices.  Now we need to add the Route service, but we don’t want to add a separate service reference.  Ideally we would have a single service that contained both the Geocode and Route services.  Luckily there is a trick we can use to do just that.  Select the Project and click the “Show All Files” button at the top of the Solution Explorer.  Expand the Service Reference folder and then expand the BingServices service.  Look for a file called Reference.svcmap. Open the References.svcmap and locate the MetadataSource node.  It will loko something like this:

Simply add a new MetatdataSource as follows:

As you can see we added a new MetadataSource that points to the Route service and we gave it a SourceId of 2.  Now right click the service and select “Update Service Reference”.  This will generate a single service proxy for both the Geocode and Route services.  Pretty slick huh?

The next step will be to create a ViewModel that will contain an ICommand that will execute the route calculation, properties that will represent a “To” address and a “From” address.  We will also need a property for the RouteResult and for the directions we generate.  Lets first create our Direction object:

Now we will need a make-shift delegate command (do not use in production code):

Now on to the ViewModel itself:

Let’s walk though the CalculateRoute Method.  First we geocode the “From” and “To” properties the same way we did in the geocoding post.  Once we have our From and To locations we use those results to generate a RouteRequest and send that request to the Route service.  The service will generate a result and we set our RouteResult property accordingly.  This property will be used in data binding shortly.  Next we generate an ObservableCollection<Direction> by looping through all the ItineraryItems in the result. 

Now that we have generate all of our data, we need to create a View that supports and displays this data, but before we do that we need to create some attached properties.  Why do you ask?  Well because as it stands, the Bing Maps WPF control is not data binding friendly.  So we need to enable data binding with the use of attached properties.  We will need an attached property for the Route result which will be responsible for drawing the route line on the map.  We will also need one for the MapLayer that will be used to contain the route line.  Here is the code:

The RouteResult property simply creates a MapPolyline, loops through all the points in the result and adds the locations to the route line.  It then gets the RouteLineLayer and adds it to the map.  Lastly, it sets the map’s view to best fit the route line.

Now we are ready for the View:

Oh and don’t forget the code behind:

Now let’s view the fruits of our labor at runtime.

As you can see, given a “From” and “To” address, we can draw a route line and provide turn-by-turn directions as the user hovers over the direction pins.  Pretty neat huh?  And it wasn’t too difficult to pull off.  As always you can Download the Source and start playing.

The concept is simple.  We want a Bing Maps application that can be extended at runtime.  By extended, I mean that I want the ability to add new elements/modules to the Map at runtime.  The important thing about these elements/modules is that they can come from anywhere and they should be loosely coupled from the Map as well as other elements/modules that may exist on the Map.

Luckily for us this is extremely simple to accomplish.  All we have to do is create a custom RegionAdapter, register it with our Prism application, and then apply it to our Bing Map control.  So let’s start with the RegionAdapter.

Now in the Bootstrapper we need to register our mapping.

Now we simply give the Map a region name. (this is actually all the shell has in it)

That is all there is to it.  You can now start injecting modules onto the Map at runtime.  Lets look at my two modules I am using as an example.  Here is the structure of my application:

• ModuleA will inject a MapPolygon in the Shape of Texas.
• ModuleB is the Earthquake application we built in an earlier post.
• Infrastructure is the project where shared code goes, in this case our MapRegionAdapter
• BingMapsPrismfiedDemo is of course our shell project.

This is what the application looks like at runtime when both modules have been injected into it.

Now I can easily add more layers to this map as I see fit.  As always, Download the Source and start playing.  You may want to add MEF support as well.

Let’s start with the Geocode Service which is used to match addresses, places, and geographic entities to latitude and longitude coordinates on the map, as well as return location information for a specified latitude and longitude coordinate.  We will create a simple application that allows you to enter an address and place a pushpin at that location.  First thing is first:

1. Get the Bing Maps WPF control.
2. Get a Bing Maps API key.

You MUST have a Bing Maps API key in order to use any of the SOAP services.  Now that you have that out of the way let’s write an application. Create a new WPF application targeting the .NET 4.0 framework. Add a reference to the Microsoft.Maps.MapControl.WPF.dll. This will most likely be located in Program Files or Program Files (x86) –> Bing Maps WPF Control –> Beta –> Libraries.

Open up your App.xaml.  You need to add an ApplicationIdCredentialsProvider as a resource and enter your ApplicationId:

Now create a very simple UI that will accept an address and a button to perform the geocoding:

The next thing we need to do is add a new Service Reference to the project and point to the following service:

http://dev.virtualearth.net/webservices/v1/geocodeservice/geocodeservice.svc

Give your service a name (I called mine BingMapsService) and just for fun, in the “Add Service Reference” dialog, click the “Advanced” button and click “Generate asynchronous operations”.

Next we need to create a ViewModel to support our View.  This is a WPF application after all.  This ViewModel will need a command for the button that will perform the geocoding, and a property that will represent the result of the service that the UI will use to map the address.  It should resemble something like this:

I want to point out that the DelegateCommand<T> is a very simple ICommand implementation and should NOT be used in production applications.  Here is the code:

Let’s hook our UI up to our command.  it should look something like this:

Notice that we are using the text of the TextBox as the CommandParameter.  Next, we need to implement the command:

In this command we are simply creating an instance of the service client, creating a GeocodeRequest, setting the credentials using the ApplicationId we have stored in the App.xaml, and then using the address as the Query for the request.  When the call to the service is completed we are setting the GeocodeResult property to the first element in the results.

Now the tricky part.  We want to place a Pushpin on the address that was entered and then move the map to that location.  We also need to make sure that when another address is entered, we clear any previous Pushpins that may exist on the map.  We also have to be aware that other elements my be on the map and we don’t want to accidentally alter those elements.  Oh and did I mention this was an MVVM application and this has to be done with just data binding?

The approach that I decided to go with is to use Attached Properties.  So I created two attached properties; one for the GeocodeResult and another for a MapLayer that will be dedicated to the GeocodeResult.  This will allow us to create a MapLayer that is specific to our GeocodeResut and not alter any other elements that may be on the map.  Let’s check out the code.

Notice that when the GeocodeResult changes we get the Location and create a pushpin for that location.  We also set the tooltip to the FormattedAddress of the GeocodeResult.  So when we hover over the pushpin we will see a nice little tooltip of the address.  Next we try to get the GeocodeResultLayer from the map, if it is null this means it doesn’t exist on the map yet so we create one and assign it accordingly.  We clear the layer child elemnts and then add out pushpin.  The last thing we do is call the SetView method of the Map control passing in the location and the current ZoomLevel.

The final step is to use our AttachedProperty on the map.  Be sure to create a namespace for the MapInteractivity class and define it as follows:

One last thing.  Be sure to remember to set your DataContext of your View to the ViewModel we have created:

That’s it.  You now have an application the can map (geocode) an address using the Bing Maps WPF Control and the Geocoding SOAP Service.  Oh and we are doing this all with MVVM and data binding which is my favorite part.  Be sure to Download the Source and start playing around.

Well, now that everyone has been given their respective credit, let’s continue.  I wanted to take my last post a little further.  In that post I simply created an event handler for a button click event using inline code in the x:Code directive.  If you started to play with the sample code, you might have thought to yourself, “I wonder if I can load this XAML, event handler and all, from a file or database and have it still work.”.  Well, if you tried it, you found the answer really quick.  No!  The reason is pretty simple; code must be compiled in order to execute.  Therefore any code inside loose XAML will fail.  Also, when using loose XAML, trying to hookup an event handler would crash your application because it is not allowed.

Oh, then it must not be possible? Wrong!  Well, then how do you do it if the code must be compiled?  Simple, we compile the code just before we run it.  Say what?  That’s right, let me introduce you to the CodeDom.  The CodeDom allows you to dynamically generate and compile code at runtime.  Let’s get to it.

We need to attach event handlers to elements in loose XAML, and have them execute C# code.  Each element has different events to handle, and each event will execute different code.  This tells me that we need an object that contains two properties, one to specify the RoutedEvent to handle, and another to specify the c# code to execute.  We also need a common event handler definition to execute whenever the RoutedEvent is invoked.

That was simple enough.  Now, in order to attach event handlers to elements in loose XAML, we need away to get around the “no event handlers allowed” limitation.  To do this we can use an attached property.

This attached property allows use to attach an instance of our DynamicEvent class to our element.  When the Handler attached property is set, we simple add our OnEventExecute event handler to the RoutedEvent specified in the RoutedEvent property.  Now we have the basic framework needed to attach and event handler to any event on any element in loose XAML.  Let’s see how to attach an event handler in XAML using this newly created DynamicEvent class.

As you can see I have added a handler for a Button’s Click event.  I also provided a Script to execute when the event is invoked.  Notice that we are preserving the whitespace in the script.  Of course nothing will happen just yet.  Now we need to take the script and compile it at run time.  This is where the CodeDom comes in.

The steps necessary to compile code at run time go a little something like this:

• Create a CodeCompileUnit
• Add our namespace and import statements
• create our dynamic class
• add a method that will execute the Script
• compile the code
• execute the code

All these steps must be performed when the ROutedEvent is invoked, which means the code must be compiled inside the OnEventExecuted event handler.

The first step is really easy.  We simply need to create an instance of the CodeCompileUnit class.  The CodeCompileUnit references the CodeDom object graph and has properties for storing attributes, namespaces, and assemblies.  Next we need to create our namespace and import statements.

Once the namespace and import statement are created we need to add them to out CodeCompileUnit instance.  Then we need to create our dynamic class.  We need to make sure it is a public class:

When the dynamic class is created we add it to our namespace.  Now we create a method. We give it a name of ExecuteScript and set its access modifier to public.  We specify that it accepts two parameters.  One being the sender which is of type object, and one that is the event args that is of type RoutedEventArgs.  Lastly, we set the body of the method to the Script property.

Now we have to create our compiler parameters.  These include adding referencing to the necessary Dlls required to run your code.  We also want to specify that we want to generate the code in memory.  If you wanted to you could save the assembly to a file.

Now we compile the code into an assembly.

The last thing we need to do is run the code that was just compiled.  We will need the help of reflection to accomplish this.

That is it.  Now to test this out lets create a .txt file that contains our XAML that we define above and save it CodeSnippet.txt.  In our MainWindow.xaml.cs, lets handle the Loaded event and load our CodeSnippet.txt using the XamlReader.Load method.

Run the application is this is what it should look like.

Now click the button and our C# code defined within the Script property will be dynamically compiled and executed changed the text of the button to this:

This is a very simple example and is not intended to be a complete solution, but it does show some of the powerful capabilities you have using WPF, XAML, and the CodeDom.  Like always download the source and start playing around.  See what kind of cool stuff you can do with it.

They looked at me in amazement, “Really?”.  Apparently that is a little known fact about WPF.  Yes, it is absolutely possible to write inline code inside a XAML page without the need for a code-behind file, and everything will work as expected.  I quickly realized that his was going somewhere I didn’t want it to go.  I knew what was coming next; they asked me to show them how to do it. Uggg…

Okay here is the deal; what I am about to show you is not recommended.  It goes against everything I have been teaching in the community, but if you are curious how to actually do this, it is quit simple.

As you can see the code snippet above is pretty simple.  You will notice that the Button has a EventHandler defined called “btnExitApp_Clicked”.  Since there is no code-behind (I deleted it) you may be expecting a compile error that says it cannot find the definition for the EventHandler.  But wait, we do have the event handler defined within the <x:Code>….</x:Code> tags.

The <x:Code>….</x:Code> is a directive element defined in XAML.  An x:Code directive element can contain inline programming code. The code that is defined inline can interact with the XAML on the same page.  Notice that the code is inside the x:Code element and that the code must be surrounded by <CDATA[...]]> to escape the contents for XML, so that a XAML processor (interpreting either the XAML schema or the WPF schema) will not try to interpret the contents literally as XML.

That is all there really is to it.  There are some limitations to using inline code, for more information you can check out the MSDN documentation.  Now, I don’t want to see this in any production code.

So here is a hidden performance increasing jewel you might find useful.  We can set the default open mode to be in full XAML view.

First thing you need to do is in Visual Studio go to your Tools ==> Options ==> Text Editor ==> XAML ==> Miscellaneous.  There you will see an option for “Always open documents in full XAML view”.  Check that box.

Now every time you open a XAML file it will open in full XAML view and give you one less thing to gripe about.

Here is what it looks like.

Here is the source: Download the Loading Animation Source

I hope it is useful to someone besides me.

Lets say I have the following code snippet:

<StatusBar>

   <StatusBarItem>

       <TextBlock Text="{Binding Messssage}" />

   </StatusBarItem>

</StatusBar>

As you can see my property Message is totally misspelled.  If I were to run this application nothing would ever appear in my status bar, and I would not know why.  I didn’t get any compile errors, and my view renders perfectly in my designer, so what the hell is going on.  You might spend hours looking at your object’s property, stepping through the property changed events, or just saying XAML is a piece of crap and I give up.  Well never fear, I am about to reveal the secret to debugging your XAML.

Look in your Output Window!

Yes, the nearly always forgotten Output Window.  As you can see, if you click on the image above, it tells me that I have a binding expression path error and gives the line number where the error occurred.  So don’t spend hours stepping through code looking for a ghost.  Just check your Output Window.

Example 1:  Lets say you want to format a double value into a currency:

<TextBlock Text="{Binding Amount, StringFormat={}{0:C}}" />

Notice the “{ }” just after the StringFormat attribute?  What that is doing is escaping the text after the “=” sign.  You need to do this because we do not have any text directly after the “=” sign.  If you don’t put the “{ }’”, strange things will happen. 

And now lets say we want to place some text in front of the currency:

<TextBlock Text="{Binding Amount, StringFormat=Total: {0:C}}" />

Since we now have text after the “=” sign we no longer need the “{ }”. 

How about a date you ask:

<TextBlock Text="{Binding Date, StringFormat={}{0:MM/dd/yyyy}}" />

Oh, and you want time:

<TextBlock Text="{Binding Date, StringFormat={}{0:MM/dd/yyyy hh:mm tt}}" />

What?  You want to create a tooltip comprised of more than one property of an object.  Well Okay:

<Button Content="Delete Me">

    <Button.ToolTip>

        <ToolTip>

            <StackPanel Orientation="Horizontal">

                <TextBlock>

                    <TextBlock.Text>

                        <MultiBinding StringFormat="Delete {0} {1}">

                            <Binding Path="FirstName" />

                            <Binding Path="LastName" />

                        </MultiBinding>

                    </TextBlock.Text>

                </TextBlock>

            </StackPanel>

        </ToolTip>

    </Button.ToolTip>

</Button>

As you can see the StringFormat attribute can be a time saver, and just make life a little easier.  One thing to note is that if you use the StringFormat attribute and you bind to a property that has no value, otherwise known as null, then the text that will be displayed is “{DependencyProperty.UnsetValue}".