We’re all spoiled.  For years, we’ve been able to drag/drop controls onto a design surface in Visual Studio and then write the code-behind.  Traditionally, our world has consisted of these two things–the design surface and the code-behind.

But with WPF and Silverlight, we really have three views: the design surface, the XAML code that defines the visual layout, and the code-behind.

When working on WPF projects then, you typically have a split window where you can work in either the design surface or the XAML code.  You can drag controls from the toolbox onto the design surface and the changes are reflected immediately in the XAML.  Conversely, you can edit the XAML and see changes on the design surface.  It looks like this.

This is beautiful.  You can work in the classic drag/drop paradigm to quickly gen up your GUI.  And then you can tweak things in the XAML, or the property editor.  Life is good.

Silverlight – Something’s Missing!

But there is a bit of a difference when you’re working with Silverlight projects.  Take a look at that same split designer view:

Notice the difference?  “Preview”, rather than “Design”.  You’ll also notice right away that you can’t drag controls onto the design surface.  Argh, I can’t live without drag/drop—these are habits that I picked up back in the days of VB3!

Relax.  Turns out that you can still drag/drop into the XAML, and your changes will be reflected in the Preview window.  The Silverlight designer is different from WPF in that this window is a read-only view of your GUI, rather than a directly-editable designer.  The other bad news is that there is no property window when editing Silverlight XAML, whereas there is when you’re working with the XAML in a WPF application.

You can read all about the Silverlight designer and its limitations here: Silverlight Tools for Visual Studio 2008 Designer Support

While this isn’t ideal, it’s workable.  Perhaps we’ll see the ability to edit directly on the design-surface in future versions of Visual Studio.  Being a newer technology, it’s sensible that Silverlight lags a bit behind WPF in terms of tooling support, in the same way that WPF seems to still lag a bit behind Win Forms.