#GIS from a .NET developer's perspective

Correctly displaying your current location

With GPS receivers integrated in phones, tablets and PCs, a lot of apps are being built that displays your current location. Usually the GPS API’s that these devices come with provides you with two values: Longitude and Latitude in decimal degrees, and often an estimated accuracy in meters. Most apps just display these values as is, without considering formatting or number of significant digits. This blog post attempts to show how this could be done. I’ll use C# for this, but it should apply to any device, language and API out there.


Some people think of longitude as the “X” in an ordinary flat X,Y the coordinate system and latitude as Y/Up/North. It’s technically not correct because this is not a flat coordinate system, but a ‘polar’ coordinate system - I do however understand this simplification and I think of it the same way internally when working with code that deals with any type of coordinate system. However, how things work internally and how they are displayed are two very different things. An example of this are date objects: They are usually stored and handled as a ‘tick’ number, but we never display it like that. Geographical coordinates are the same way. They have one way they are stored in memory, and a completely different way to be displayed.

First of all lets get the order out of the way: If you still think of longitude as the ‘x’ you probably want to display this value first. However it’s commonly agreed upon that latitude is displayed before longitude.

Next are negative coordinates. Instead of showing a latitude/longitude as for instance -117,34 you would write 117°W 34°N. So we prefix the coordinate with N/S and E/W depending on weather the coordinate is positive or negative. So in C# this could look like this:

char ns = lat < 0 ? 'S' : 'N'; //Southern or Northern hemisphere?
char ew = lon < 0 ? 'W' : 'E'; //Eastern or Western hemisphere?
string formatted = string.Format("{0}°{1} , {2}°{3}", Math.Abs(lat), ns, Math.Abs(lon), ew);

Now this is still decimal degrees. A more ‘proper’ format would be to use the degrees, minutes, seconds (DMS) format . Some people do prefer decimal degrees though, so you might want to make this a configurable option. But if you expect people to be using this coordinate to plot a position on a map, you are better off using DMS, since this is the format maps uses along its edge - and it also looks prettier. Degrees are denoted with a °, minutes with a single quote ' and seconds with a double quote ". For example 117°W 23' 12.34”

To make this conversion you will first show the integer part of the degrees. Take the remainder multiply by 60, and you’ll get the minutes. Lastly take the remainder of that and do the same, and you got the seconds (and you can display the seconds with decimals, but see the part on ‘accuracy’ next).  Below is what that will look like in C#:

char ns = lat < 0 ? 'S' : 'N'; //Southern or Northern hemisphere?
char ew = lon < 0 ? 'W' : 'E'; //Eastern or Western hemisphere?
//Make positive
lon = Math.Abs(lon);
lat = Math.Abs(lat);
//Grab the part in front of the decimal
var majorLong = Math.Floor(lon);
var majorLat = Math.Floor(lat);
//the value after the decimal in minutes (*60)
var minorLong = (lon - majorLong) * 60;
var minorLat = (lat - majorLat) * 60;
var minutesLong = Math.Floor(minorLong);
var minutesLat = Math.Floor(minorLat);
var secondsLong = (minorLong - minutesLong) * 60;
var secondsLat = (minorLat - minutesLat) * 60;
string formatted = string.Format("{0}{1}°{2}'{3}\" {4}{5}°{6}'{7}\"", ns, majorLat, minutesLat, secondsLat, ew, majorLong, minutesLong, secondsLong);


Often I see a location displayed as for example -117.342817243 , 34.212381313. When I see this many digits I instantly think ‘oooooh that’s a very accurate location’. But this is very misleading. In college, several of our professors would fail our reports if the end result displayed more digits than the accuracy of the input data. The same thing applies here. If your GPS receivers accuracy is 1000m, how many digits should you display, and how many meters is one second?

First a little about the size and shape of earth: While earth is not a perfect sphere, it’s fairly close to an ellipsoid (this is still an approximation though). It’s widest at equator, and smallest (flattened) between the north and south pole. So in ellipsoid-speak the parameters are:

Semi-major axis: 6,378,137m
Semi-minor axis: 6,356,752.3142m
Mean radius (mR): 6,367,449m

So back to the question: How many meters is one second? This is pretty easy to determine for latitude, but unfortunately this is not a straightforward conversion for longitude, since this changes with the latitude. Let’s first start with the simpler latitude:
First we need the circumference of Earth along a meridian (a line that goes north/south) and Equator:

Circumference at Equator: 2 * Pi * 6,378,137 = 40,075,016 m
Circumference of a meridian : 2 * Pi *  6,356,752 = 39,940,652 m

For simplicity let's stick with a rough average of 40mio meters, since this is not going to really matter for the end result.
From that we get:

Horizontal length of one degree at Equator or along a meridian:
     40,000,000 / 360 = 111,111m
Horizontal length of one second at Equator or along a meridian:
    111111.111 / 60 minutes / 60 seconds = 31m

So from that we get that we should never display any decimals on seconds unless our accuracy is better than 31 meters. And we shouldn’t display more than one decimal unless the accuracy is 3m or better (which never happens with standard GPS equipment). Similarly if we are using decimal degrees instead of DMS for display, how much does the n'th digit matter at Equator or along a meridian?

5 digits: 0.000,01 * 40000000 = 400m 
6 digits: 0.000,001 * 40000000 = 40m
7 digits: 0.000,000,1 * 40000000 = 4m

So in this case we will only show 7 digits if accuracy is better than 40m, and probably never more than 7 digits.

Latitude always goes along a meridian, so the number of significant digits doesn't ever change with your location. But the length of one degree at a longitude changes with the latitude you're at.
The radius of a longitude at a given latitude is: cos(latitude)*mR*2*PI.
At 34 north or south that would be: 33,168,021m. So here the number is roughly 3m instead of 4m, meaning you are more likely to show more digits on the longitude portion for the coordinate, the further north you go. In general practice however, this is not going to matter too much, since it only gets better. so to keep it simple we’ll just stick with the same conversion at all latitudes.

Bringing it all together

So let’s bring all this together into a C# ValueConverter you can use for binding against a GeoCoordinate object returned by the GeoCoordinateWatcher in .NET and Windows Phone. A converter parameter is used for choosing whether you want DMS or decimal degrees as output.

using System;
using System.Device.Location;
using System.Globalization;
using System.Windows.Data;

namespace CoordinateDisplay
    /// <summary>
    /// Converts a GeoCoordinate to Degrees-Minutes-Seconds
    /// </summary>
    public class CoordinateConverter : IValueConverter
        private const double MeanEarthRadius = 6367449; //meters
        private const double MeanEarthCircumference = 2 * Math.PI * MeanEarthRadius; //meters
        public object Convert(object value, Type targetType, object parameter, CultureInfo culture)
            if (value is GeoCoordinate)
                var coord = value as GeoCoordinate;
                if(coord.IsUnknown) return "Unknown";

                double lat = coord.Latitude;
                double lon = coord.Longitude;
                if ((parameter is string) &&
                    string.Compare("decimal", parameter as string, StringComparison.OrdinalIgnoreCase) == 0)
                //show as decimal degrees
                    var decimalsLat = 7;
                    var decimalsLon = 7;
                    int val = 4;
                    if (coord.HorizontalAccuracy > val * 100) decimalsLat = 5;
                    else if (coord.HorizontalAccuracy > val * 10) decimalsLat = 6;
                    val = (int)Math.Floor(Math.Cos(lat / 180 * Math.PI) * MeanEarthCircumference / 10000000d);
                    if (coord.HorizontalAccuracy > val * 100) decimalsLon = 5;
                    else if (coord.HorizontalAccuracy > val * 10) decimalsLon = 6;
                    return string.Format("{0}°,{1}°", Math.Round(lat, decimalsLat), Math.Round(lon, decimalsLon));
                else //Show as degrees/minutes/seconds
                    char ns = lat < 0 ? 'S' : 'N'; //Southern or Northern hemisphere?
                    char ew = lon < 0 ? 'W' : 'E'; //Eastern or Western hemisphere?
                    //Make positive
                    lon = Math.Abs(lon);
                    lat = Math.Abs(lat);
                    //Grab the part in front of the decimal
                    var majorLong = Math.Floor(lon);
                    var majorLat = Math.Floor(lat);
                    //the value after the decimal in minutes (*60)
                    var minorLong = (lon - majorLong) * 60;
                    var minorLat = (lat - majorLat) * 60;
                    var minutesLong = Math.Floor(minorLong);
                    var minutesLat = Math.Floor(minorLat);

                    //one digit accuracy on one second equals ~3m or better
                    //this changes with the latitude, but this is good enough for now
                    int decimals = 1;
                    if (coord.HorizontalAccuracy > 30)
                        decimals = 0; //With this accuracy we don't need to show sub-second accuracy
                    var secondsLong = Math.Round((minorLong - minutesLong) * 60, decimals);
                    var secondsLat = Math.Round((minorLat - minutesLat) * 60, decimals);
                    return string.Format("{0}{1}°{2}'{3}\" {4}{5}°{6}'{7}\"",
                        ns, majorLat, minutesLat, secondsLat,
                        ew, majorLong, minutesLong, secondsLong);
            return value;

        public object ConvertBack(object value, Type targetType, object parameter, CultureInfo culture)
            throw new NotSupportedException();

Here’s an example of using that in XAML where the datacontext is the GeoCoordinate:

        <local:CoordinateConverter x:Name="dmsConverter" />
        <TextBlock Text="Degrees minutes seconds:" />
        <TextBlock Text="{Binding Converter={StaticResource dmsConverter}}" />
        <TextBlock Text="Decimal degrees:" />
        <TextBlock Text="{Binding Converter={StaticResource dmsConverter}, ConverterParameter=decimal}" />
        <TextBlock Text="{Binding Path=HorizontalAccuracy, StringFormat=Accuracy: \{0:0\}m}" />

And what this can look like on a Windows Phone with different accuracies (notice the different number of digits):


You can download this sample app here.

WinRT vs. Silverlight - Part 4 - Dispatcher

See intro blogpost here.

In Silverlight and WPF you will often use the Dispatcher to return from a background thread to jump to the UI Thread. This is required when you need to update your UI, because you’re not allowed to touch the UI from anything but the UI Thread. The Dispatcher method has changed slightly in WinRT. It’s also now of type “CoreDispatcher”, instead of just “Dispatcher”.

           (s, a) => { ... }
      , this, null);

GZIP Compressed Web Requests in WP7 - Take 2

I earlier wrote about how .NET API in Windows Phone 7 doesn’t zip-compress it’s web requests, and how using Mango’s socket support allows you to circumvent that to get more efficient use of the limited data connection phones often have. The approach had some problems and limitations, and wouldn’t work in all scenarios. Even so, compressing your webrequests is very important on a phone since you can often save 50-80% of the data transmitted, and many people pay by the byte they transmit.

Since my blogpost Windows Phone 7 Mango has gone through a few iterations, and using a socket is no longer necessary, since the “accept-encoding” header needed to request GZIP compressed requests is no longer blocked (thank you to those who voted for getting this unblocked). However, GZIP compression is still not a built in feature (Why not Microsoft?!?). If you set this header, you are still in charge of uncompressing the content. I’ve updated my GZipWebClient class to take advantage of the new allowed header. It simplifies the class quite a lot, as well as made it more stable.

Also I “forked” the DotNetZip library and included in this project, so you don’t need to go find 3rd party dependencies, and in the process removed all parts of the library that is not needed to keep the assembly as compass as possible. So here’s what the client now basically looks like:

public class GZipWebClient : WebClient
    public GZipWebClient()
    protected override WebRequest GetWebRequest(Uri address)
        var req = base.GetWebRequest(address);
        req.Headers[HttpRequestHeader.AcceptEncoding] = "gzip"; //Set GZIP header
        return req;
    protected override WebResponse GetWebResponse(WebRequest request, IAsyncResult result)
        WebResponse response = null;
            response = base.GetWebResponse(request, result);
            if (response.Headers[HttpRequestHeader.ContentEncoding] == "gzip")
                return new GZipWebResponse(response); //If gzipped response, uncompress
                return response;
            return null;

The key here is adding the header that tells the server “Hey I understand GZipped responses as well”. When the response comes back and the header says “Hey here’s some gzipped content”, I use a custom GzipWebResponse class that uses the DotNetZip library to uncompress the stream. Apart from some trivial code, this is the meat of that class:

internal class GZipWebResponse : WebResponse
    WebResponse response;
    internal GZipWebResponse(WebResponse resp)
        response = resp;
    public override System.IO.Stream GetResponseStream()
        return new SharpGIS.ZLib.GZipStream(response.GetResponseStream()); //Uncompress

You use it exactly like the normal “WebClient” class, except you instantiate the GZipWebClient instead. The rest of your existing code doesn’t change at all. Example:

WebClient client = new SharpGIS.GZipWebClient();
client.DownloadStringCompleted += client_DownloadStringCompleted;

You can download the source code below, and you can also get it on NuGet/SymbolSourceusing command “Install-Package SharpGIS.GZipWebClient”

Download source

I also rely heavily on this in my WinPhone Twitter client ‘Peregrine’ and have seen quite a performance improvement when updating your twitter timeline. You can download Peregrine for free here:


With the latest v1.1 update on nuget (source also updated here), you don’t have to do the above. All you need to write is the following two lines of code and put it in your app.xaml.cs startup file. After this ALL existing code (including 3rd party libraries you don’t have control over) will start using GZIP compression!

WebRequest.RegisterPrefix("http://", SharpGIS.WebRequestCreator.GZip);
WebRequest.RegisterPrefix("https://", SharpGIS.WebRequestCreator.GZip);

If you just want to do this for some domains, only register that prefix part. So no need to go replace all your WebClient as mentioned above. More on how this work in this blogpost.


Note that using RegisterPrefix causes this to use an internal custom HttpWebRequest class and that can have some serious effects on your app. Unfortunately Microsoft ‘forgot’ to unlock the Get/Set UserAgent property when they ported from Silverlight (there the user agent was always the browser), and many 3rd party libraries  tries to set this property, which will throw a NotImplementedException. Also note that cookies are not supported either (some libraries use that). They should of course be checking the “SupportsCookieContainer” property before using it, but not all do (I’m looking at you RestSharp), and will therefore throw an exception. However for almost all the simpler scenarios, the above register works like a charm.


Now also on GitHub:


Update 2 no longer applies :)

Windows Phone: Adding Mango features to a 7.0 WinPhone App

Microsoft just announced what happens to your non-Mango app (WP7.0) if you publish a Mango app (WP7.1) to the marketplace. Basically if you upgrade your app to 7.1, you will no longer be able to maintain the 7.0 app for people who still haven’t upgraded yet (and we know from the last update that that can take a while).

However, it is possible to make a 7.0 app that uses Mango features if the user has upgraded to Mango. That way you can continue to build a 7.0 app, and the moment the user upgrades to Mango, he will get additional features available. All this using a little “reflection magic”. The certification requirements does kind of hint at that this is not allowed, but some apps has already made it through certification, so this seems to be considered OK to do, and it also works great as well.

So how is this done? We can use the method of the Type object to get identifiers of methods, events, constructors, properties etc. by using their names. This way we will never write a piece of code that explicitly uses one of these (which the compiler would reject), but instead at runtime will attempt to locate them, and if successful execute/access it

But before we attempt doing that, we can perform a check for whether this is a mango device (or newer). Mango is v7.1, so it must be version 7.1 or newer:

bool IsMangoDevice = (Environment.OSVersion.Version >= new Version(7, 1));

We can also get access to types we don’t have yet in the 7.0 compiler but the 7.1 device has. For example, the StandardTileData class used to create secondary tiles for your app can be accessed using its full name and assembly:

Type t = Type.GetType("Microsoft.Phone.Shell.StandardTileData, Microsoft.Phone");

If we continue down this path, we can actually create a secondary tile on a mango device, and still have the app be 7.0. That means you can TODAY submit an app to the marketplace that uses mango features, and people with developer devices will get mango features now! (again note that this might cause problems during marketplace certification, but some apps has already made it through and is available today!)

Anyway… here’s the code that creates a secondary tile:

//get the constructor for the StandardTileData and create a new instance of it
var newTileData = t.GetConstructor(new Type[] { }).Invoke(null);
//Get the setter method for the title property
var setMethod = newTileData.GetType().GetProperty("Title").GetSetMethod();
//Set the tile title
setMethod.Invoke(newTileData, new object[] { "This is my new tile" });
//Get the create method for the shell tiles
Type shellTileType = Type.GetType("Microsoft.Phone.Shell.ShellTile, Microsoft.Phone");
var createMethod = shellTileType.GetMethod("Create");
//Create the tile, with the uri and tile data
Uri uri = new new Uri("/MainPage.xaml?Test=This_Came_From_A_Secondary_Tile", UriKind.Relative)
createMethod.Invoke(null, new object[] {  uri, newTileData});

Or how about setting the system tray color?

GetSetMethod().Invoke(null, new object[] { Colors.Red });

Of course you should only call these methods if the device is a mango device, so use the check shown first before executing this code. I created an extension class that neatly encapsulates this and only executes the code if it’s supported. Examples:

//Set tray color if supported

//Add hold event handler to a control (onHold is of type RoutedEventHandler delegate):

//Show "Create secondary tile" button if supported:
createTileButton.Visibility = MangoExtensions.IsMangoDevice ? Visibility.Visible : Visibility.Collapsed;

//Create/replace tile:
MangoExtensions.CreateTile("My Tile", new Uri("/MainPage.xaml?parameter1=value1", UriKind.Relative));

You can download the entire extension class here: Download

WPF vs. Silverlight - Part 11 - Silverlight on Phone vs. Browser

See intro blogpost here.

Well technically this is not a WPF vs Silverlight post, but a SL vs WP7, but it still kinda belongs in this series.

Generally the differences in the API’s between Browser Silverlight and Windows Phone Silverlight are pretty slim. However dealing with the phone can be quite different anyway. First there’s often less security restrictions on the phone to worry about. Secondly there’s a lot of phone specific APIs like sensor data, camera, contacts etc). The screen is also smaller so often some controls doesn’t make sense to have on the phone, or needs to have a separate layout to enhance the experience on this small touch-centric screen. Lastly (and very importantly) the small amount of memory, processing power and battery life means that performance is a concern. This often forces you to go down a slightly different avenue for your application, and for certain custom controls.

For the API differences I’m again going to be cheap and just point you to the main resource on MSDN that has some really good info on that matter:

Other notable things:

  • In Silverlight for Windows Phone, effects such as Blur and DropShadow are not supported.
  • Custom pixel shaders are not supported, so the PixelShader type is not supported.
  • Silverlight applications on Windows Phone are hosted on the client device and do not run inside of a browser. Silverlight features that are based on a browser host are not supported. These features include the HTML DOM bridge, JavaScript programmability, and the Silverlight plug-in object reference.
  • Isolated storage on Windows Phone does not enforce quotas to restrict the size of isolated storage for Silverlight-based applications. The default quota size of 1 MB does not apply. (however there’s still a 2Gb limit on Isolated Storage for WP7, or less if you run out of space).
  • Manipulation events that Silverlight doesn’t have (well technically they are there but throw a not supported exception), are the same as in WPF, so WP7 has better touch closer to WPF than Silverlight.

Next: WPF vs. Silverlight - Part 11– Silverlight on Phone vs. Browser

WPF vs. Silverlight - Part 9 - Reusing code in Visual Studio #2

See intro blogpost here.

In the previous post, I covered how to configure your project to create both a Silverlight and a WPF build. However, I usually like to structure my control libraries slightly different, and place the theme file for a specific custom control next to the control code, instead of having an ever-growing Themes\Generic.xaml file with all the controls merged together. It makes it easier to find the theme for a specific control without having to scroll an enormous XAML file. My Silverlight project will usually look like this:


In Generic.xaml I instead “merge” in this file using a Merged Dictionary:

        <ResourceDictionary Source="/MyLibrary;component/Controls/TemplatedControl1.Theme.xaml" />

As you add more controls, you simply add another entry into the resource dictionary. So the next step would be to link this new TemplatedContro1.Theme.xaml file into WPF, and make your solution look like the following:


However, this won’t work in WPF! When you run the WPF version, the template will never get applied, because the template is never found. There seems to be a bug in WPF that the Silverlight and Windows Phone compilers doesn’t have, and it literally took me forever to find this problem: WPF doesn’t like linked resource files that isn’t located in the root of the project! The only workaround I’ve found so far is to move the TemplatedControl1.Theme.xaml to the root of the WPF project (still linked though) and create a new non-linked Generic.xaml file for WPF (since it now has to point to a different location of the theme file).

So your WPF project will instead look like this:


Note that the WPF\MyLibrary\Themes\Generic.xaml is no longer linked, but is a copy of the Silverlight file, with the \Controls\ part removed from the ResourceDictionary Source path.

By the way, if you followed the same steps for creating a Windows Phone 7 project, the WP7 compiler doesn’t have this problem so this workaround is specific for WPF only.

Next: WPF vs. Silverlight - Part 10 - XAML Parser Differences

WPF vs. Silverlight - Part 0 - Introduction

In my day to day work, I work on building not one, not two, but three .NET API's. One for Silverlight, one for WPF, and one for Windows Phone. However, since this is all based on the same technology (.NET and XAML), we reuse most of our code for all 3 (a rough estimate is 99% is the same code files). That's pretty cool, because I can create one feature in for instance Silverlight, and WPF and Windows Phone will instantly have it.

...well except if I hit one of those inconsistencies that makes up the remaining 1% of code differences. I've searched through our code and looked for the most common code differences in the API's, and the following series will cover these.

When you do need to write platform specific code, you can use a compiler conditional to do it. By default a Silverlight project will have a "SILVERLIGHT" conditional declared that you can use to exclude or include code for a specific platform. This is done by surrounding the code with a #if [condition] ... #endif section. Example:

   //Silverlight and Windows Phone

If you are writing code for Windows Phone as well, note that this is also a Silverlight app, and will compile with the SILVERLIGHT conditional. However, Windows Phone also has a default conditional you can use to exclude/include features separate from Windows Phone:
//Windows phone:

    //Windows Phone
    //Windows Phone and WPF
    //Silverlight but NOT Windows Phone

You will see these conditionals used in the upcoming blogposts to separate the code differences between the platforms. Click to select a topic below:

  1. WPF vs. Silverlight - Part 1 - Custom Controls Theme
  2. WPF vs. Silverlight - Part 2 – XamlReader
  3. WPF vs. Silverlight - Part 3 - Creating Bitmaps Programmatically
  4. WPF vs. Silverlight - Part 4 – Animations
  5. WPF vs. Silverlight - Part 5 - XAML Control Instantiation
  6. WPF vs. Silverlight - Part 6 - Debug.WriteLine
  7. WPF vs. Silverlight - Part 7 - Case sensitivity
  8. WPF vs. Silverlight - Part 8 - Reusing code in Visual Studio #1
  9. WPF vs. Silverlight - Part 9 - Reusing code in Visual Studio #2
  10. WPF vs. Silverlight - Part 10 - XAML Parser Differences 
  11. WPF vs. Silverlight - Part 11 - Silverlight on Phone vs. Browser
  12. More to come… keep checking back… 



A note on our development approach: We generally build a new feature for Silverlight first. Since Silverlight is a subset of WPF, we are less likely to be using an API that's not available in WPF (since it has most of what Silverlight has). We then test the code in WPF and tweak if necessary (tweaks rarely needed). Windows Phone is Silverlight (albeit roughly an earlier version), so we might exclude a feature here and there, but generally the only differences here are various simplifications for performance reasons (most of which isn’t needed with the upcoming Mango release), and of course sometimes retemplating for a smaller touch-centric screen.

GZIP Compressed Web Requests in WP7

Before you read on, you might want to read the “Take 2” blogpost instead:

If you use the WebClient in Silverlight, the browser handles the web request for you, and if the browser supports compressed content (which all of them does), it will take full advantage of that, and you never have to worry about it. However on Windows Phone 7, there is no browser, and the Silverlight API itself handles the web request. However, this client does NOT support compressed content. The result of that is often a much larger response, which in turn means an app that loads data from the web updates much slower, and for those who pay per Mb downloaded, also a big increase in dataplan costs. Data like JSON and XML can sometimes compress as much as 10x, so there’s quite a benefit to compress data responses.

Unfortunately you can’t choose to request compressed content through the header and handle the uncompressing yourself, because the required header (Content-Encoding=gzip,deflate) is a restricted header. This is probably a carry-over from Browser-Silverlight (since there the browser handles this), and for whatever reason this restriction wasn’t removed (this is also the case with the Mango beta release). Not supporting gzip and/or deflate in web requests really seems like a (huge) oversight in Windows Phone. If you agree, please vote for this feature here.

So what to do? Well luckily Mango adds support for Sockets which is basically the core component driving the WebClient. So I ventured into creating my own WebClient subclass, and building custom HttpWebRequest/HttpWebResponse handlers that uses a Socket to request data in gzip format.

You can download the compiled library as well as source code below. It works exactly like WebClient (in fact it’s a subclass of WebClient). However, note that the “OpenWrite” is currently not supported (DownloadString, OpenRead and UploadString are all OK to use).


   1:  WebClient c = new SharpGIS.GZipWebClient();
   2:  c.OpenReadCompleted += new OpenReadCompletedEventHandler(c_OpenReadCompleted);
   3:  c.OpenReadAsync(new Uri(""), "TESTSTATE");
   5:  ...
   7:  private void c_OpenReadCompleted(object sender, OpenReadCompletedEventArgs e)
   8:  {
   9:      StreamReader reader = new StreamReader(e.Result);
  10:      string result = reader.ReadToEnd();
  11:  }

Note: The library requires SharpZipLib (included in binary).

.NET Code Reuse presentation

Tomorrow, I’ll be doing a presentation on .NET code reuse across Silverlight, WPF and Windows Phone at the LA SLUG user group meeting.

Microsoft has been touting for a while that you can reuse your code across these platforms, but never really tell you about all the gotcha’s. As part of my day job building the ArcGIS API for Silverlight, WPF and Windows Phone (where 99% of the code is reused), I’ll talk about the experiences and lessons learned, and what usually hides in the remaining 1%.

The meetup will take place:
Wednesday, May 25, 2011 at 7:00 PM (PDT)
United Future / Wongdoody
8500 Steller Dr Culver City, CA

If you are not in the LA Area, you will miss out on the free beer and pizza, but for the first time ever LA SLUG will be streaming the event online. See event details for more info. I’ll post slides (and if there is a recording, a link to that as well) shortly after.

Silverlight vs. WPF

Silverlight or WPF? Who will win? Or will they team up to be the best tigerblood-powered kick-ass platform ever conceived?

Windows Phone 7 Copy/Paste on TextBlocks

With the recent update of Windows Phone 7, AKA the "NoDo" update, Windows Phone got support for Copy/Paste. Any existing app out there instantly gets this support automatically, without the developer has to do anything.

However, copy/paste only works on TextBoxes, but what if you want to allow the user to copy text from a TextBlock? Today this is not possible. The trick to make this work is to simply use a readonly TextBox, and restyle it to look like a TextBlock. Here's the TextBox style that accomplishes this:

<Style x:Key="ReadOnlyTextBox" TargetType="TextBox">
	<Setter Property="Foreground" Value="{StaticResource PhoneForegroundBrush}" />
	<Setter Property="IsReadOnly" Value="True" />
	<Setter Property="TextWrapping" Value="Wrap" />
	<Setter Property="Template">
					<ContentPresenter x:Name="ContentElement" />

Note: This approach actually also applies to "normal" browser-Silverlight as well.