Friday, June 06, 2008
(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.
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
There are many decisions to be made when you're building a new application, and Silverlight introduces some new (but old) paradigms when it comes to the layout of your interface.
In this first part of three articles, we're going to be talking about the <Canvas> option. I equate this to a more familiar concept in HTML known as absolute positioning. Each element will be given its own specific location on the page, and nothing but code can move them. This is also one of the downfalls of the <Canvas>, but for many apps, this may not matter.
With elements absolutely positioned, things just don't adjust. If a user resizes their browser, the elements don't move. If a user tries to see your application on a smaller screen than you anticipated, part of the app is going to be hidden. (Think mobile phones, for example...if you position everything out to fit in a window 800 x 600, that 320 x 200 screen is not going to show very much).
However, this is still one of the fastest ways to get your elements positioned on a page, and the taboos that came with absolute positioning in CSS are erased, because we're now developing in a universal plugin, not 17 flavors of browser and platform combinations.
So how do we do it? Here's some example code:
As you can see, it's pretty straightforward. We have a button, an ellipse, and a rectangle, and their positions are defined by the Canvas.Left and Canvas.Top attributes. You can also nest <Canvas> tags, and the Left and Top attributes apply to the immediate parent of the element you are positioning.
Click here to see the code above running in a browser.
(continue to Part 2...and Part 3...)
Labels: absolute positioning, CSS, jeff blankenburg, layout, Silverlight