I've been asked by a couple of folks how they might get started creating a map of the United States in XAML. Having done some mapping work in my past, I know how difficult it can be to create the states as individual elements, but arranged to represent the shape of the country. It's challenging to say the least.

So, having said that, I wanted to make sure that everyone that needs the United States rendered in XAML can have it. I found this on the blog of Maciej Skierkowski, where he was facing the same problem. It's my understanding that he created this, and here's his post on the reason.

Download the map of the United States in XAML here.

Labels: Silverlight, united states, XAML

(See Part 1 and Part 2 first...)

In the third and final installment of this series on Silverlight Layout, we are going to be discussing my preferred option for interface creation: The Grid. In many ways, I would compare this to table based layout in HTML (which is generally a bad word), but I will come to its defense in Silverlight today.

There are many reasons why table-based layouts should not be used in HTML. A few of them are:

1) Tables are very heavy. With all of the <tr> and <td> tags you need, the page bloats quickly.

2) CSS is the right way to do it. Once you harness the power of CSS, you have far greater control of your layout (not to mention accessibility) than you do with tables.

3) Tables are very difficult to manipulate once they are in place. If you've ever tried to move things around in a legacy table layout, you know what I'm talking about.

The reason I am recommending this type of layout is because those problems have been addressed in Silverlight with the <Grid>. So let's take a look at the code.



You'll notice that this doesn't really look like HTML table layout that you've seen in the past. Instead, we've seperated (still in the same file, mind you) the content from the layout. We don't have to wrap each element in a set of table tags. We define a grid, and then we assign each element to a cell of that grid. I've also turned on the ShowGridLines attribute, so we can see exactly what the grid looks like. We can also assign height and width values to the cells of the grid, up to and including the wildcard "*" character. This tells the application to use the rest of the remaining space for that cell. If you have more than one wildcard cell, it will split the unclaimed space evenly between them. Please note that the grid starts with 0,0, not 1,1. So our Red Rectangle is assigned to Grid.Cell="0" and Grid.Row="0" which puts it in the top left corner. Each of the respective rectangles after that is assigned to their respective grid location as well. The design pane of Visual Studio 2008 looks like this with the XAML I just used:



You'll notice that the Black rectangle is missing. That is the one assigned to the wildcard space. In the design pane, there's not a Canvas width and height defined. In the XAML, I did not specify a width and height for my Grid. This causes it to fill the entire space of the window it is rendered in. When we run the application, however, you'll see that the black box is, in fact, there, and takes up the rest of your browser window.

In my next post, I will talk about using templates to create "styles" that can be reused by your XAML elements.

Labels: grid, jeff blankenburg, layout, microsoft, Silverlight, tables, visual studio 2008, XAML

(See Part 1 first...)

Today we are looking at a second way to lay out your interface in Silverlight. This will be far more familiar to the CSS fanatics out there. The primary concept is simple...we'll be using a StackPanel control to position our elements.

For those of you less familiar with CSS, this is more of a flow-based layout. As the size of the Silverlight container grows and shrinks, you will find that the elements will move to accomodate that space. I, personally, would not recommend approaching your entire interface with this technique, but it certainly makes sense for small portions, like navigations and lists of data.

Most of our positions will be determined by manipulating the margins of the individual elements on the page. In doing so, we can place our elements specific distances apart without having to specify their exact position on that page.

In the example below, I have 6 buttons that I want to arrange in a 3x2 block. I start with an outer stack panel that, by default, will stack my elements vertically. However, I want to have two rows of 3 buttons each, so I am going to nest two more stack panels. Each of these will have the Orientation attribute of the StackPanel set to Horizontal, to create the rows.



For demonstration purposes, I also modified the margins of a few of the buttons, just to show that we are merely stacking these elements. This is not a grid, or table, and certainly not absolute positioning. These elements are merely stacked, either horizontally or vertically, with margins as the leverage to move things around a bit.

NOTE: I have a major complaint about how margins were implemented in Silverlight.

Again, for those of you familiar with CSS, the de-facto standard for specifying margin sizes was one of two formats:

margin-left:10px;
margin-right:10px;
etc.

OR

margin:0 10px 0 10px;

Each of those examples would have given you a 10 pixel margin on both the left and right of the element you were styling. In the second example, we are using a bit of shorthand to specify ALL of the margins in one line. They start with the top, and go clockwise. margin:Top Right Bottom Left;

In the margin implementation for Silverlight, it would appear that they also offer a shorthand version for margins (actually, the only version is shorthand), and they did not follow the standard convention mentioned above. Instead, they chose to use Margin="Left, Top, Right, Bottom". I've not yet talked with the team to see why this convention was chosen over something more familiar to developers, but if I can find an answer, I will post it here.

(continue to Part 3...)

Labels: .net, jeff blankenburg, microsoft, Silverlight, stack panel, XAML

Some of you, my dear readers, have asked how I got over that magical step in my Silverlight Animation Tutorial. The step where I had an Adobe Illustrator file, and then, POOF!, I had the XAML to start working with it.

No, I didn't recreate the logo in Expression Blend. Mike Swanson created an AI->XAML Exporter. You will need:

* Adobe Illustrator CS2
(I don't know how they did it, but every trial version of this software on the web has disappeared. There used to be a 30 day trial...now you can only find Illustrator CS3. This is why I save all of my installation files.)

* Mike Swanson's Export Plug-in

* The rest of his instructions.

One quick thing to remember, however, is that there are a couple of quirks with the XAML you get. The syntax is good. No issues there. But it is creating XAML for WPF, not Silverlight. WPF has a much larger set of tags to work with, and as such, most WPF XAML may not be directly compatible with Silverlight.

Not in a "these are totally different" way, more in a "the opening and closing tags for WPF are different than Silverlight." WPF uses <window> as its top level tag, and Silverlight uses the <canvas> tag. Window is meaningless to Silverlight, because you don't have a window for it. It's only part of a web page. You can see this illustrated below:

Default code generated for a WPF application:

<Window
     xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
     xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
     x:Class="UntitledApplication1.Window1"
     x:Name="Window"
     Title="Window1"
     Width="640" Height="480">
     <Grid x:Name="LayoutRoot"/>
</Window>

Default code generated for a Silverlight application:

<Canvas
xmlns="http://schemas.microsoft.com/client/2007"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Width="640" Height="480"
Background="White"
x:Name="Page"
>
</Canvas>

So, in order to use the XAML that is generated by this tool in Silverlight, you're going to have to chop the "middle" of the XAML out and paste it into your new Silverlight app. Everything else should be the same. Ta-da!

Labels: adobe illustrator, Mike Swanson, Silverlight, WPF, XAML