XAML and GIS

While working an a recent app I wanted to enable tilt functionality onto a Grid that contained a few items. Unfortunetly I was unable to get the control to tilt. I tried setting all sorts of properties, but nothing worked. I downloaded the source and took a look at it, and the same time I asked the twiiter universe whether non selectable items could be “tiltable” Morten Neilson replied with exactly what I was seeing. His suggestion was to change the source which is easy enough to do. Just add FrameworkElement to the list.

static TiltEffect()

{

// The tiltable items list.

TiltableItems = new List<Type>()

{

typeof(ButtonBase),

typeof(ListBoxItem),

typeof(MenuItem),

};

}

But I wanted to find a way to make this work without having to change the source for the WP7 toolkit. I love open source projects, I have two myself. But it’s a lot nicer to use the out of the box code rather than having to maintain your own.

My thought was if the toolkit limits to those items, what if I wrapped my Grid in one of them? I didn’t want to use a button because then I’d have to style it, so I tried a ListBoxItem.

<ListBoxItemtoolkit:TiltEffect.IsTiltEnabled="True">

<Grid>

<TextBlockText="I'm now tiltable!"/>

</Grid>

</ListBoxItem>

Of course there is no need for the Grid in the above, but you get the point. This is being used outside of a ListBox and works fantastic!

I’m a big fan of .Net and all the glory that it offers. So when I’m developing against ArcGIS COM objects I cry a little inside. Working with COM objects in .Net is not fun. C# 4.0 made this a little better by improving the code generated by interop.

Example code to get an indexed property within .Net from a COM object with VS2008

int fieldIndex = 2;

IRow row = cursor.NextRow();

objectvalue = row.get_Value(fieldIndex);

Example code to get an indexed property within .Net from a COM object with VS2010

int fieldIndex = 2;

IRow row = cursor.NextRow();

objectvalue = row.Value[fieldIndex];

Notice the difference? It’s in the last line where we get the value for the field. Not only do you not need the get_XXX prefix, but you use square brackets. It’s actually an indexed property now! Small things like this make working with ArcObjects a little better, but there is still a lot more that can be done. One area that always just plain sucks is iterating over COM collections. Here is a simple example of iterating over an ICursor

ICursor cursor = table.Search(null, true);

IRow row = cursor.NextRow();

while(row != null)

{

// Do some stuff

row = cursor.NextRow();

}

This is one of the easier COM collections to work with. This one at least does not have a Reset() method. Without a doubt, you are bound to forget that setter at the end of the while loop and your be looking at the same row for a very long time. This is very error prone.

Luckily we can add new functionality to any object by using extension methods. I hope you’re familiar with extension methods. I’m always surprised when I find active developers that have never heard of them. By creating an extension method, I can change the code above to:

ICursor cursor = table.Search(null, true);

foreach(var row in cursor.ToEnumerable())

{

// do some stuff

}

Ahhh… So much better! No need to worry about setting the row object again at the end of the while loop. I can work with this a lot easier than before, and it just looks a ton better!

Let’s take a look at what it would take to write this extension method.

publicstaticclass Extensions

{

publicstatic IEnumerable<IRow> ToEnumerable(this ICursor source)

{

if (source != null)

{

IRow row = source.NextRow();

while (row != null)

{

yieldreturn row;

row = source.NextRow();

}

}

}

}

I have this code written once and I can now forget all about it! From now on it’s .Net goodness baby!

But wait! There’s more! I went ahead an created a NuGet package that contains many of these extension methods!

PM> Install-Package ArcGISExtensions

This package contains 15 ToEnumerable methods to help out with iterating over the ArcGIS COM collections. I picked the ones that are used the most. I plan to add some more Enumerable extensions as well as others to help out with your ArcGIS development.

So, when someone asked how to go about styling the new PivotViewer control, my immediate response was going to be “Use Expression Blend”. But, we’re in a odd place right now. There is now RTM of Express Blend. There is only the Expression Blend Preview for Silverlight 5. As this is not a RTM release, and PivotViewer is new, I thought I would test it out first. So, open a Silverlight 5 project in Blend Preview and add the PivotViewer Control. Right click on the PivotViewer –> Edit Template –> Edit a Copy…

WHAT?!?!? An empty template! I must have done that wrong. I must have done PivotViewer –> Edit Template –> Create empty… Yup, that must be it! Try again, and again an empty template. Blend, you have failed me! How could you? I used to think that Blend was the all powerful Oz when you need to style a control. But it failed!

OK, I’ll just go to step two. Microsoft is always great when it comes to documentation. Go to MSDN, and… No templates?!?! Ok, Silverlight 5 had the longest Beta program! Was it a year? I don’t recall when the first beta came out, maybe around MIX? Yes I think that’s it. Granted, the PivotViewer control was not released with the first Beta, but it was with the second. So this is one time when the team dropped the ball when it comes to the docs.

So, nothing from the all powerful Blend, nothing from MSDN, now what? Like any .Net developer I keep a copy of Reflector close by. Open up the PivotViewer assembly and check out the resources. Sure enough, there it is! If you’ve played with PivotViewer before, you know that this control is not just a simple control. This thing is a beast! It is an entire application disguised as a control. Because this thing is so huge, the styles used are contained in a 6000+ line xaml file! Maybe this is why it is not on MSDN, but the basic style of the actual PivotViewer control is only 170 lines of xaml. That’s nothing! Here is the default style for PivotViewer

As you can see, the default style is nothing much. It’s mainly just the title bar. The DetailPaneStyle helps apply some color based style like Background, Foreground, etc. to the panel that appears when you drill into a trading card. This panel shows up on the right. The FilterPaneStyle does the same but for the panel on the left that shows the different properties that you can on. Being able to set the color is nice, but come on I want to do more. Surely I can use the ability to set this styles in Expression Blend with the Edit Additional Styles feature. Oh, that’s disabled with the right click menu, but it’s not disabled in the Object menu! Oh, that doesn’t work at all. Crap! Blend you suck! I want a divorce!

Luckily the styles for these two controls are also in that 6000+ line file. So, if you do want to style the left pane (also called the Facets) or the right details pane, you have everything needed.

If you are looking to get down and dirty with the Facets, you’ll want to pay attention to the Accordion styles. The PivotViewer uses a CustomAccordion control, and it uses a lot of styles that are supplied in the file. You’ll want to alter the AccordionItemStyle, FacetCategoryHeaderTemplate, and the FacotCategoryTemplate styles.

As it’s currently impossible to find these styles, I’ve supplied them here. This file comes complete with all of the comments from the team that developed it! WooHoo! I also went ahead and fixed some of the styling. For some reason this team REALLY loved ancestor binding and used it everywhere. They even used it where TemplateBinding should be used.

Managing extents within the ArcGIS .Net client API’s is pretty simple. Esri has an example on the resources page. I implemented one for the ArcFM Silverlight SDK sample. Oddly enough, they are quite similar. I don’t remember copying theirs, but you never know. Like most things we as developers do, after a couple of years you look back and wonder “What was I thinking?” I look back at my original code and wonder why did I implement the Extents class the way that I did. I originally used one List to hold all of the Extents. This made some of the code pretty ugly. I’ve created a different implementation that utilizes two stacks. I have one class that manages all of the extents:

58:// Only add the extent if it is "new" ie: Not a Previous or Next extent

59:if (IsNewExtent)

60: {

61: Extents.Add(e.NewExtent);

62: }

63: IsNewExtent = true;

64: PreviousExtent.RaiseCanExecuteChanged();

65: NextExtent.RaiseCanExecuteChanged();

66: }

67: }

The joy of these classes is that they can be used within all of the .Net Client API’s! This can even be used within the new ArcGIS Runtime (currently in Beta). Using these within our application is now a breeze! Here is the xaml for a WPF Window

UPDATE: See a new post to get the latest code for the custom MessageBox.

UPDATE: After posting this blog I found out about the message box within the XNA framework. This does allow for custom button text which is what I was trying to accomplish. However, the user experience is different than what you get from the message boxes within the native phone applications (eg: deleting a text). With the native message boxes, the application bar disappears, but with the XNA message box, it gets greyed out. It’s the little things that matter. Also within the XNA framework you cannot add additional components to the message box. For example, you might want to add a “Do not show me this again” option within the message box.

While using a Windows Phone you get prompted every once in awhile by a message box. Custom Applications have them, even apps native to the phone has them. When deleting a text message or a contact you get a nice prompt asking you if you want to delete it. But there is something unique about these message boxes that separates them from the one that you and I get to have. The standard message box only allows for an “OK” and a “Cancel” button. The message boxes that are native to the phone have custom text. When you delete a text, you are prompted with buttons “delete” and “cancel”. Seeing as there is not a way to do this, you need to create your own. I’ve created a very simple sample that can be used.

The CustomMessageBox sample is based on the assumption that message boxes are “binary”. What I mean is that you get binary options, Yes/No, OK/Cancel, etc. So I’ve limited what is allowed to be a valid result.

1:publicenum CustomMessageBoxResult

2: {

3: Yes,

4: No,

5:// Not using this yet, but you could wire up to the back button of the phone to be a cancel

6: Cancel

7: }

I don’t have the ability to have a Show method return the CustomMessageBoxResult so I’ll need an EventArg that will be used within an event.

1:publicclass MessageBoxEventArgs : EventArgs

2: {

3:public CustomMessageBoxResult Result { get; set; }

4: }

The xaml is pretty straight forward. We need to "”block” the page the CustomMessageBox is for. To do this I made the control a grid so it will fill up everything. Then give it a background with an opacity that will block all clicks.

Pivot was originally released as a demonstration project that was a separate download from Silverlight itself. At version 5, Pivot becomes part of the Silverlight family. Pivot allows users the ability to visualize their data. Puts the power of filtering and grouping their data without the need to learn complex SQL statements. The original version of Pivot required you to have an XML representation of the data, and images that it would display. This required extra work for the developer, or web administrator to create this data from their data store. With Silverlight 5, you now have the ability to bind to any property that your class has. It also allows you the ability to create what’s known as trading cards with XAML. These cards replace the images you previously needed. You can even define at what stage you want a trading card to display. By defining different trading cards at different levels, you can give the user more information the more they filter down their data.

When I first started looking into whether I’d be able to get PivotViewer results from ArcGIS Server, I figured I would have to create a Silverlight class with properties for all of the fields that I wanted to use within Pivot. It turns out that Pivot works great with the data you get straight from the ArcGIS or ArcFM Silverlight SDK. It easily binds to the Attributes Dictionary that is on the Graphics objects.

To get started using Pivot, you need to download the latest Silverlight 5 Tools. Create a new Silverlight Application. Make sure to pick Silverlight 5 as the version

You’ll need to add a reference to ESRI.ArcGIS.Client and System.Windows.Controls.Pivot. To add the ArcGIS Silverlight SDK, open the Add Reference dialog, and click the Browse tab. Browse to the location of ESRI.ArcGIS.Client assembly. The default location is C:\Program Files (x86)\ESRI SDKs\Silverlight.

Open MainPage.xaml.cs. We’re going to need to create a query to the ArcGIS Server. For my example, I’m going to use the Telvent ArcGIS Server at http://server.arcfmsolution.com/arcgis/rest/services. First, we need to query for the electrical switches that we’ll use within Pivot

public MainPage()
{
InitializeComponent();
QueryForSwitches();
}
private void QueryForSwitches()
{
// Query for switches. Switches have LayerID of 3 QueryTask task = new QueryTask("http://server.arcfmsolution.com/ArcGIS/rest/services/Electric/MapServer/3");
Query query = new Query();
// Return all of the fields, we want use them all, but good to have 'em anyways!
query.OutFields.Add("*");
// Get as many of the switches as we can query.Where = "ObjectID > 0";
task.ExecuteCompleted += QueryTask_ExecuteCompleted;
task.ExecuteAsync(query);
}

Add a call to this method within the constructor of the MainPage. When the task completes, all we need to do is set the DataContext to the Features that are returned.

The XAML is where all of the magic happens. We are able to pick which fields the user will be able to filter/sort by, and define the trading cards. I want to give the user the ability to sort and filter switches by Installation Date, the Phase Designation, which Feeder it belongs to, and the Operating Voltage. So the fields I need from the Attributes dictionary are INSTALLATIONDATE, PHASEDESIGNATION, FEEDERID, and OPERATINGVOLTAGE. To do this, you add PivotViewerProperties.

I’m using fields that have domain values, so I need a few value converters, I won’t bore you with the conversion of the domains here. If you need to sort/filter by date values, like the Installation Date, use a PivotViewerDateTimeProperty This gives you cool date filtering capabilities. I don’t have any integer values that I’m sorting by, but if I did I would use the PivotViewerNumericProperty. To create a trading card, add a PivotViewerItemTemplate to the ItemTemplates collection.

This gives our trading card a Metro feel. But there isn’t much data here, as the user drills further into their data, I want to show them more. We can add more trading cards if we want to add more detail when users start filtering their data, or using the zoom capability of Pivot. To do this you set the MaxWidth property of the PivotViewerItemTemplate, and add another template.

<sdk:PivotViewerItemTemplate MaxWidth="250">

To see more, download the complete sample here. Give your users the power to SEE their data.

The Repository Pattern is well known to everyone that needs to access a database. That is unless you access a database through ArcObjects. A repository is easy to use, easy to inject, and easy to unit test. Doing anything with ArcObjects is very complicated. Especially unit test. Wrapping ArcObjects in a layer of abstraction usually helps simplify things. By wrapping a few simple operations within a repository, your code no longer needs to start or stop an edit operation, no longer needs to worry about creating a QueryFilter (something that cannot be done within unit tests), and no longer needs to worry about all of the little details of accessing ArcObjects.

If this interface is injected into your object, you can now easily unit test all of the basic CRUD operations, something that you cannot do if you rely on ArcObjects.

The basic implementation of this interface will need to do all of the dirty ArcObjects access that your code used to do. It will need an instance of the Editor object so that it can manipulate the operations. It will have to create the QueryFilters for doing queries.. You get the idea.

If you like to keep things more generic, remove the ITable and IRow from the methods and properties and make them generic type parameters. This allows you the ability to implement the interface and get back your own custom objects.