Silverlight Tips Grab Bag for NovemberSubmitted by smartyP on Mon, 11/16/2009 - 21:09
I haven't written a grab bag in a while, so here is a rather impromptu set of tips from lessons learned in developing full-time in Silverlight the last several months. I hope to get better at blogging these things more frequently, but hopefully this grab bag will be useful to some.
Have Good INotifyProperty Snippets
There are several Visual Studio snippets on the web relative to implementing the INotifyProperty interface and corresponding properties in Silverlight. You should find snippets that fit your style and know how to tweak them if needed - you can edit these snippets easily in notepad.
The images below link to their corresponding snippets attached to this post - these are the snippets I'm currently using. You can use the notify property snippet with the keyword notifyp, and you can use the INotifyPropertyChanged implementation with inotifyp. You'll want to save both of these snippet files to your ..\Documents\Visual Studio 2008\Code Snippets\Visual C#\My Code Snippets\ folder.
The main thing to note is that the setters for the properties are comparing the values and only firing the notification if the value actually changed - this helps prevent firing events that update listeners and UI when the value didn't actually change.
(more after the break..)
Know How to Use Silverlight Spy
There will undoubtedly be times when you are working on a Silverlight project and run into a visual artifact that you can't trace down. When you're working with simple UI's this isn't very common (although it still does happen), but as your UI's get more complex you'll eventually run into visual quirks which trying to debug can kill an entire afternoon - knowing how to use Silverlight Spy can be invaluable in these situations.
A lot of times when I would debug a layout I would give random pink and purple colors to objects so I can see where my containers are, etc. - but Silverlight Spy already has this sort of functionality built into it - it is able to help you quickly break down your layouts visually and figure out why something isn't lining up right. Even better than that it lets you tweak values at runtime, which can help you try out various changes until you figure out the exact fix you need to make to your layout.
A prime example of where Silverlight Spy saved me recently was using the charting controls in the Silverlight Toolkit. We had a bar graph and in some instances the bar would never show up. It took me almost an hour to narrow down the issue - the widths of the bars were 0 because the time range axis was graphing such a long period of time that one bar was below 1 pixel wide. Using Silverlight Spy I was able to drill down and notice a rectangle with a 0 Width and could set its MinWidth and immediately see that the bars were actually there, and that setting a MinWidth on the style's rectangle would fix the issue.
Silverlight Spy can also be a great tool for pulling down XAPs from Silverlight apps you run into on the web - you can grab the XAP with Silverlight Spy and using Reflector you can take an in-depth look at any Silverlight app you find on the web.
Disable Cider All Together in Visual Studio 2008
Visual Studio's 'Cider' editor for XAML in Silverlight does nothing. In WPF Cider will render a preview of the XAML, but in Silverlight projects it won't (by default - you can actually drag the semi-hidden splitter up to see the XAML preview). Since you get nothing out of the Cider editor as a Silverlight developer I highly encourage you to disable Cider all together to get a noticeable performance boost when switching between .xaml and .cs files. You can switch XAML files over to open with a different editor and keep the intellisense and the exact same experience as using the Cider editor. The image below shows how to make the change. You can of course change the editor back to what it was if ever needed, but I have yet to find any reason to do that, and getting rid of the delay when switching between .xaml and .cs files all day is hard to put a price on.
- Right click a .xaml file, and choose 'open with..'
- Change from the 'Windows Presentation Foundation Designer' to the 'Source Code (Text) Editor' and set it as the default
Get Familiar With LinqPad for LINQ to XML
Chances are that if you're using Silverlight, then you're going to be consuming XML be it from webservices, RSS feeds, etc. In my case I recently worked on a project with about 16 or so XML formats to read and write from. I decided to use the Silverlight Unit Test Framework for writing tests to make testing the LINQ to XML queries a bit easier, but in the long run LinqPad was an even bigger help when it came to parsing all these XML formats without having to compile our entire project every time to run my tests.
I typically use LinqPad for the same thing over and over - I get a sample XML response from my source and I save it off to an XML file. I then create a new LinqPad query which references that XML file, and I embed the same XML sample into my unit tests which will run their tests against the sample response file. Below is a rough example of how I start my LinqPad queries - note that the Language drop-down should be set to 'C# Statement(s)':
string xml = XElement.Load(@"C:\blahblah\TypicalResponse1.xml").ToString();
XNamespace atomNS = "http://www.w3.org/2005/Atom";
XDocument doc = XDocument.Parse(xml);
// build up the data points
var entryQuery = doc.Descendants(atomNS + "entry");
foreach (var entry in entryQuery)
string id = entry.Element(atomNS + "id").Value;
And here is a quick sample of how my Initialize step might look in my unit tests:
public void Setup()
// get the embedded XML response
StreamResourceInfo sr = Application.GetResourceStream(
string xml = new StreamReader(sr.Stream).ReadToEnd();
IResponseParser parser = new ResponseParser();
_parsedEntries = parser.ParseResponse(xml);
My biggest other tip is to use Evernote to keep track of issues you run into and tips you come across as you learn Silverlight - having quick references for tips and troubleshooting is a great thing.
In your Linq to XML example,
In your Linq to XML example, is there some reason you're using XElement.Load -> ToString -> XDocument.Parse rather than XDocument.Load? Your code will load the file, parse it, convert it to a string, and then parse it again. Using XDocument.Load would simply load the file and parse it once.
that's just how i've been
that's just how i've been doing it, i just tried out your suggestion and it worked great - thanks for the suggestion!