Charles Petzold

XamlCruncher for Silverlight

January 24, 2009
New York, N.Y.

The static XamlReader.Load method — implemented in both the Windows Presentation Foundation and Silverlight — is a wonderfully simple and powerful tool. Give it some XAML and out pops an object. XamlReader.Load was obviously intended for applications to process XAML during runtime, but it has also proved to be a handy development tool.

I've been told that almost every Microsoft programmer who worked on "Avalon" wrote a little program built around XamlReader.Load to interactively write and edit XAML and see the resultant object. The one that made it into the official SDK was called XAMLPad.

I wrote my own XamlReader.Load-based tool called XamlCruncher in connection with my WPF book, Applications = Code + Markup. In fact, I structured the book around XamlCruncher. The whole first half of the book is a tutorial of all the skills necessary to build a Notepad clone, and then in the second half of the book, XamlCruncher is built on top of that.

Like all real WPF programmers, I write all my own XAML, and I've found XamlCruncher to be extremely useful for that purpose, even if I do eventually move the XAML into a Visual Studio project.

I've recently felt a need to have a similar tool for Silverlight, and I'm sure somebody has done it before me, but my program, which I call "XamlCruncher SL," arose from a desire to see how few features a program such as this can have and still be useful. You can run the result here:

XamlCruncherSL.html

Silverlight SL has almost no features at all. (At least for now; I may be enhancing the program if I find it useful.) Basically you enter and edit XAML in the left of the screen and see the result in the right part. The two parts are separated by a splitter. If the XAML passes XamlReader.Load, the edit text is displayed in black; otherwise the text is displayed in red, and the exception message is indicated in the left of the "status bar" at the bottom. Sometimes the error message has a line and column indication. For that reason, the right of the "status bar" displays the current line and column of the caret in the editor.

There is no file "save" or "load" feature in XamlCruncher SL. (Obviously saving to isolated storage is high on my list of probable enhancements.) For now, if you want to save something that you've typed in the editor, select it (Ctrl‑A) and copy it into the clipboard (Ctrl‑C). Then you're on your own. Similarly, to get some existing XAML into the editor, use paste (Ctrl‑V).

XamlCruncher SL has so few features that the feature I consider most important is this: When you press the Tab key in the editor, you aren't navigated to the splitter. Spaces are inserted instead. (It seems trivial but I did have to override OnKeyDown.)

This version of XamlCruncher SL does not install a handler for the Application.UnhandledException event. If the XAML successfully passes XamlReader.Load but there is a runtime error (which in my WPF experience most often occurs during a XAML-based animation), the program will not catch it. For example, try this chunk of XAML in the program:

(Yes, select, copy, and paste.) If you change the Storyboard.TargetName or Storyboard.TargetProperty, the XAML parses OK, but there's a runtime error, and that will be indicated by Internet Explorer with the warning icon in the lower left corner and the text "Error on page." However, SilverlightSL continues to run OK, and if you fix the problem, the animation will resume. (However, the warning icon doesn't go away.) I'll be investigating Application.UnhandledException as a way to avoid this.

If you're new to the joys of interactively writing XAML, keep in mind there are certain restrictions on the XAML that can be parsed by XamlReader.Load. The root element can't contain an x:Class attribute and event handlers can't be specified. However, I've notice something rather odd: Any non-standard attribute prefaced with an 'x' prefix is simply ignored. For example, insert this into any element:

and XamlReader.Load doesn't complain.

Here's the source code, and you may ask: "Can I reference my own (or somebody else's) Silverlight DLLs in the XAML I type into XamlCruncherSL?" and the answer is "Yes, because you now have the source code." Here's how to do it:

Suppose you downloaded the stuff in my recent blog entry Canonical Splines in WPF and Silverlight and you've built the solution, and you now have a Silverlight DLL named CanonicalSplineLib.dll in the CanonicalSplineLib\Bin\Debug directory.

With the XamlCruncherSL solution loaded in Visual Studio, in the XamlCruncherSL project, right-click References, click Add Reference, select the Browse tab, navigate to the CanonicalSplineLib.dll file, and select it. Recompile XamlCruncher SL. With Silverlight, DLL's are bound into the XAP file, but they are referenced in XAML the same way as in WPF: With an XML namespace declaration indicating the CLR namespace and the assembly name. Here's a (somewhat modified) version of the XAML I showed in that previous blog entry:

In fact, the version of SilverlightSL I've made available online was compiled not only with the CanonicalSpline assembly in it, but also with all four DLLs that are part of the Microsoft Silverlight Toolkit. (The source code does contain references to those assemblies; you'll have to do those yourself based on the location of the DLLs on your machine.) That means you can experiment with stuff like the DockPanel:

Get a load of that long XML namespace declaration, and make sure it's all on one line, and notice that it's Microsoft.Windows.Controls rather than System.Windows.Controls.