Monday, June 30, 2008
Want to contribute to your developer community? Want to know what your peers think of you? I'm proposing a new type of meme. Hopefully this will catch fire like Michael Eaton's Software Meme did a few weeks ago.
Contribupendence Day. That's what I'm calling it. On July 3, 2008, I am going to write recommendations for 5 people on LinkedIn. And leave comments on Plaxo. And {name your social network here}.
One of the things that I have found, in this wonderful developer community I am a part of, is that we've got some amazingly talented people in this industry. But when I look around at their profiles on the sites I mentioned above, you'd hardly know it. Hardly anyone has even ONE recommendation on LinkedIn. Comments (or a presence, for that matter) on Plaxo are slim. Facebook walls usually consist of nothing more than "Hey Steve, what are you doing this weekend?" But yet, when you're looking for that next job, what's the first place a new employer is going to look?
So let's tell the world about the people we work with. Or the people we WISH we worked with. No strings attached. Let's make sure that when someone looks up your friend online, that they find a glowing (and true) review from a peer. No embellishments, no lies. Just the truth. And do it with no expectation that they will return the favor. That's just selfish.
I will be picking 5 people from each social network that I participate in. That's currently only LinkedIn, Plaxo, and Facebook. So, on July 3rd, I hope you will contribute to someone's independence from online mediocrity. If you have a blog, tell us who you tagged! My list will be here Thursday.
This post was inspired by Marvin Palmer, a software developer for Vanderbilt Medical Center. He wrote a glowing recommendation for me on LinkedIn, and I was incredibly flattered. I hope each of us can do the same for someone else on Thursday. Have a great holiday weekend.
Labels: contribupendence, jeff blankenburg, linkedin, marvin palmer, meme, plaxo
Thursday, June 26, 2008
We (and by we I primarily mean Amanda Laucher) are organizing a bus trip to Nashville for DevLink. This might be one of the single greatest ways to get to know your fellow developers in the community.
The bus will start in Grand Rapids, MI, heading down through Detroit to Columbus, OH, through Cincinnati, and down to Nashville, TN. If all works out, we should have Wi-Fi, xboxes, and perhaps even LAN gaming if we can pull it off.
I will almost definitely be on this bus. Many of the people you have seen speaking at Day of .NET events will be there. And so should you. We are also looking for sponsorship, so if your company would like an opportunity to get their names and products in front of some of the best, most influential software developers in this region of the country, please contact Amanda.
On top of that, the bus actually takes you someplace. In Nashville, there's an amazing technical conference called DevLink. It's two full days of technical sessions, and after my attendance last year, I wanted to make sure I was speaking there this year.
I'll be presenting a session on Next Generation Web Applications in Visual Studio 2008. I'm really looking forward to this trip. And I hope I can share this bus trip with you.
Who is going to DevLink?
Labels: amanda laucher, devlink, devlink bus tour
Tuesday, June 24, 2008
I like speaking in public. I really enjoy it. But it's been far too long since I've done it. And my next scheduled talk isn't until the end of August, at DevLink.
I'm posting this message to let the world know that I'm ready to get back in the game. Please contact me at jeffrey.blankenburg@microsoft.com if you would like me to come talk to your developers, whether that's internal to your company, or at a user group in your community. I will do my best to accomodate all requests. I've got several new talks ready, as well as a few older favorites that audiences enjoy.
Here they are:
* Building Next Generation Web Apps With Visual Studio 2008
This talk is an overview of Visual Studio 2008 and some of the great new features it has to offer. This includes tools and techniques ranging from the Split view design pane to effectively using LINQ.
* Silverlight 101: The Basics
This talk really is an introduction. We'll talk about XAML, build a basic application, and show the integration with Expression Blend. I would recommend this for any group that wants to get their feet wet with Silverlight.
* Silverlight 301: Way More Than A Spinning Button
In this talk, we will learn how to build a Silverlight application that talks to a SQL server through a WCF web service. We will render the content in a visually appealing way using XAML. And if you ask nicely, I'll even spin a button for ya.
* Cool Microsoft Stuff: The Technologies You Have To Try
This is an overview of some of the amazing things Microsoft is working on behind the scenes. Some of them are available in beta form, but you're guaranteed to see something you've never seen before. This includes technologies like Photosynth, Deep Zoom, and Live Mesh.
* XNA Anyone?
This talk will walk you through the basics of game development using XNA as the platform. We will also talk about game development for the Zune.
I'm posting this message to let the world know that I'm ready to get back in the game. Please contact me at jeffrey.blankenburg@microsoft.com if you would like me to come talk to your developers, whether that's internal to your company, or at a user group in your community. I will do my best to accomodate all requests. I've got several new talks ready, as well as a few older favorites that audiences enjoy.
Here they are:
* Building Next Generation Web Apps With Visual Studio 2008
This talk is an overview of Visual Studio 2008 and some of the great new features it has to offer. This includes tools and techniques ranging from the Split view design pane to effectively using LINQ.
* Silverlight 101: The Basics
This talk really is an introduction. We'll talk about XAML, build a basic application, and show the integration with Expression Blend. I would recommend this for any group that wants to get their feet wet with Silverlight.
* Silverlight 301: Way More Than A Spinning Button
In this talk, we will learn how to build a Silverlight application that talks to a SQL server through a WCF web service. We will render the content in a visually appealing way using XAML. And if you ask nicely, I'll even spin a button for ya.
* Cool Microsoft Stuff: The Technologies You Have To Try
This is an overview of some of the amazing things Microsoft is working on behind the scenes. Some of them are available in beta form, but you're guaranteed to see something you've never seen before. This includes technologies like Photosynth, Deep Zoom, and Live Mesh.
* XNA Anyone?
This talk will walk you through the basics of game development using XNA as the platform. We will also talk about game development for the Zune.
Labels: developer evangelist, jeff blankenburg, microsoft, Silverlight, silverlight 2, software development
Thursday, June 19, 2008
Today I'm going to show how to create a simple WCF service, and consume it from a Silverlight application. This is something you are going to need to do quite often, and if for no other reason, I am documenting this here so that I have it as a reference.
The first thing we need to do is create a Silverlight application. (In order to have all of the Silverlight 2 prerequisites, make sure you visit this page.)
1) I'm going to start from the beginning. First, we need to create a new Silverlight project. I'm naming mine JBWCFService.
2) We will then be prompted to create a web project to accompany our Silverlight project. I choose a Web Application Project from the dropdown.
3) Here is a view of what my solution explorer looks like after the projects are created. I have a Silverlight project called JBWCFService and a Web Application project called JBWCFServiceWeb, not surprisingly.
4) Next, I want to create a SQL database from which to get my data from. I'm not going to walk through all the steps of adding tables, columns, and data. You can certainly find that elsewhere. Here's my adding the SQL database to my project though...
5) OK, it's time to create our service. I'm naming my service MyNewService. It's just another thing to add to our project, so here we go:
6) Once the new service has been created, you will have a few new files in your project. In my case, they are named IMyNewService.cs, MyNewService.svc, and its code-behind, MyNewService.svc.cs. By default, the interface (IMyNewService.cs) will be open and ready for editing. They create a DoWork() method for you, but we're going to delete that and do something more interesting in a little while. First, we need to get LINQ up and running against our data. I am naming mine LINQClasses.
7) In addition to adding the class files necessary, this will also open the LINQ design surface by default. We can just drag items from our data structure right to the left half of the surface, creating ORM class structures that represent our data. In my example, I only have one table, profile, but we can do this for all of our tables, and stored procedures can be dragged to the right half of the surface, creating methods. I have already dragged my table over in the next screenshot (click to enlarge).
8) We also want to make sure that our data is unidirectionally serializable (I like big words). By clicking on the design surface (not one of the table boxes), you can get to the properties of the DataContext, and change the Serialization Mode to "Unidirectional."
9) Now we need our Silverlight project to become aware of our WCF service running in the web application project. To do this, we just need to add a new service reference to the Silverlight project. Click the "Discover" button to find it automatically. This will also automatically spin up a web server for your service to run in. I named my service reference MyNewServiceReference.
10) Ready to write some code? To this point, everything has been handled automatically for us. Now we have to get our hands dirty. Let's go back to our Service interface (IMyNewService.cs). In there, let's get rid of that DoWork() method. Instead, our method is going to return a List of profiles from the database, based on our new classes that were created for us. Because this is an interface, we don't define the actual functionality of the method here, just it's signature. I named my method GetProfilesByLastName.
11) Ok, that was exhausting. Let's have the IDE write some more code for us now. Let's open the code-behind file for MyNewService.svc (MyNewService.svc.cs). You can see that it inherits from the interface we just defined, so right click on the name of the interface, and have it implement the interface for you.
12) Now you've got the shell for the method. We just need to tell this method what to do. Here's where the LINQ comes into play. We need to get a reference to our DataContext from earlier, and then I wrote a simple query to retrieve names from the database based on a last name query. Finally, we return our list of data.
13) Each time we update our service, we will need to update our service reference in the Silverlight project, so that it sees our new methods. Just right click on the service reference and choose "Update Service Reference." Also, we have one small change we need to make to our web.config file as well. If you've been following the instructions, then you can scroll down to the bottom of your web.config and look for the <endpoint binding="wsHttpBinding" /> property. Silverlight only currently supports basicHttpBinding, so we need to change it to that.
14) Next, we need to add one more reference to our Silverlight project before we can finally start working with the XAML. We need to add a reference to System.Windows.Controls.Data so that we can use the DataGrid control in our interface.
15) XAML time. Kinda. We need to include that reference as a namespace in our Page.xaml document. OK, now we can add some controls to our page. I also added a Button, a TextBox, and a DataGrid, inside a couple of StackPanels, for layout purposes.
16) Now, we need to call that method in our service and populate that grid. The first thing we need to do is instantiate our ServiceClient. Now, since we are calling this service asynchronously, we also need to set up an event handler to know when our data has returned so that we can update the DataGrid. There's an excellent bit of shorthand for creating this code automatically. My screenshot shows all of the code I will need, but for the line that starts:
sc.GetProfilesByLastName +=
I only actually typed what is above. After that, I pressed the Tab key twice. The first press of Tab actually finishes out my EventHandler statement. The second Tab press creates my EventHandler method, so that I can add the guts. Finally in my Button_Click method, I need to call the GetProfilesByLastName asynchronously, passing in the value from my TextBox, named DataEntry.
17) The last little touch we need to put on this application is the actual binding of the data to our DataGrid, and we'll do that in the new EventHandler method that was created for us. There's just one line of code in the method:
DataGrid.ItemsSource = e.Result;
So, there you have it. We've created a WCF service that uses LINQ to talk to a SQL server, and a Silverlight 2 application that consumes that service and renders the result. Not bad for 17 steps, and only a few lines of code.
Click here to download the solution files.
The first thing we need to do is create a Silverlight application. (In order to have all of the Silverlight 2 prerequisites, make sure you visit this page.)
1) I'm going to start from the beginning. First, we need to create a new Silverlight project. I'm naming mine JBWCFService.
2) We will then be prompted to create a web project to accompany our Silverlight project. I choose a Web Application Project from the dropdown.
3) Here is a view of what my solution explorer looks like after the projects are created. I have a Silverlight project called JBWCFService and a Web Application project called JBWCFServiceWeb, not surprisingly.
4) Next, I want to create a SQL database from which to get my data from. I'm not going to walk through all the steps of adding tables, columns, and data. You can certainly find that elsewhere. Here's my adding the SQL database to my project though...
5) OK, it's time to create our service. I'm naming my service MyNewService. It's just another thing to add to our project, so here we go:
6) Once the new service has been created, you will have a few new files in your project. In my case, they are named IMyNewService.cs, MyNewService.svc, and its code-behind, MyNewService.svc.cs. By default, the interface (IMyNewService.cs) will be open and ready for editing. They create a DoWork() method for you, but we're going to delete that and do something more interesting in a little while. First, we need to get LINQ up and running against our data. I am naming mine LINQClasses.
7) In addition to adding the class files necessary, this will also open the LINQ design surface by default. We can just drag items from our data structure right to the left half of the surface, creating ORM class structures that represent our data. In my example, I only have one table, profile, but we can do this for all of our tables, and stored procedures can be dragged to the right half of the surface, creating methods. I have already dragged my table over in the next screenshot (click to enlarge).
8) We also want to make sure that our data is unidirectionally serializable (I like big words). By clicking on the design surface (not one of the table boxes), you can get to the properties of the DataContext, and change the Serialization Mode to "Unidirectional."
9) Now we need our Silverlight project to become aware of our WCF service running in the web application project. To do this, we just need to add a new service reference to the Silverlight project. Click the "Discover" button to find it automatically. This will also automatically spin up a web server for your service to run in. I named my service reference MyNewServiceReference.
10) Ready to write some code? To this point, everything has been handled automatically for us. Now we have to get our hands dirty. Let's go back to our Service interface (IMyNewService.cs). In there, let's get rid of that DoWork() method. Instead, our method is going to return a List of profiles from the database, based on our new classes that were created for us. Because this is an interface, we don't define the actual functionality of the method here, just it's signature. I named my method GetProfilesByLastName.
11) Ok, that was exhausting. Let's have the IDE write some more code for us now. Let's open the code-behind file for MyNewService.svc (MyNewService.svc.cs). You can see that it inherits from the interface we just defined, so right click on the name of the interface, and have it implement the interface for you.
12) Now you've got the shell for the method. We just need to tell this method what to do. Here's where the LINQ comes into play. We need to get a reference to our DataContext from earlier, and then I wrote a simple query to retrieve names from the database based on a last name query. Finally, we return our list of data.
13) Each time we update our service, we will need to update our service reference in the Silverlight project, so that it sees our new methods. Just right click on the service reference and choose "Update Service Reference." Also, we have one small change we need to make to our web.config file as well. If you've been following the instructions, then you can scroll down to the bottom of your web.config and look for the <endpoint binding="wsHttpBinding" /> property. Silverlight only currently supports basicHttpBinding, so we need to change it to that.
14) Next, we need to add one more reference to our Silverlight project before we can finally start working with the XAML. We need to add a reference to System.Windows.Controls.Data so that we can use the DataGrid control in our interface.
15) XAML time. Kinda. We need to include that reference as a namespace in our Page.xaml document. OK, now we can add some controls to our page. I also added a Button, a TextBox, and a DataGrid, inside a couple of StackPanels, for layout purposes.
16) Now, we need to call that method in our service and populate that grid. The first thing we need to do is instantiate our ServiceClient. Now, since we are calling this service asynchronously, we also need to set up an event handler to know when our data has returned so that we can update the DataGrid. There's an excellent bit of shorthand for creating this code automatically. My screenshot shows all of the code I will need, but for the line that starts:
sc.GetProfilesByLastName +=
I only actually typed what is above. After that, I pressed the Tab key twice. The first press of Tab actually finishes out my EventHandler statement. The second Tab press creates my EventHandler method, so that I can add the guts. Finally in my Button_Click method, I need to call the GetProfilesByLastName asynchronously, passing in the value from my TextBox, named DataEntry.
17) The last little touch we need to put on this application is the actual binding of the data to our DataGrid, and we'll do that in the new EventHandler method that was created for us. There's just one line of code in the method:
DataGrid.ItemsSource = e.Result;
So, there you have it. We've created a WCF service that uses LINQ to talk to a SQL server, and a Silverlight 2 application that consumes that service and renders the result. Not bad for 17 steps, and only a few lines of code.
Click here to download the solution files.
Labels: jeff blankenburg, linq to sql, microsoft, Silverlight, silverlight 2, tutorial, wcf, web service
Wednesday, June 18, 2008
So I encountered a bug today. A real-life, this-hasn't-been-fixed-yet bug in Silverlight 2 Beta 2. And I gotta think it's pretty common. After all of my posting on layout options, I think it's my responsibility to mention this one. It is also documented on the Silverlight forums, but I want to make sure it's shared here as well...
Much of what I am doing for my pet Silverlight 2 project requires me to show/hide different canvases, depending on which "page" you are on within my site. I've seen some Silverlight sites that are actually just different SL apps, and links actually take you to a seperate .aspx page for each one. I wanted to keep the user experience without any postbacks. All AJAX. No wavering from my page. Because of this, each navigation button just hides everything and shows the section it represents.
So each "page" is represented as a canvas. And for the simple example below, it works perfectly.
However, when your canvas contains elements that derive from Control, you don't get the behavior you expect. Here's my canvas with real stuff in it:
What I am finding is that my canvas just doesn't show up. In my code, I know my syntax is correct, because it works for all of the simple canvases like the first one I showed. The moment I add a Button, TextBox, Radio Button, User Controls, etc. the Canvas no longer will change its Visibility property from Collapsed to Visible. This, it would seem, is a major problem. However, there's a pretty simple workaround for this.
Click here to see the example running.
By making my base element for this function something other than a Canvas, it works perfectly. In my example, I have used a StackPanel, and just put my Canvas right inside it as the only element. In this example, all of the contents of my "page" will display as expected now.
Sure, it's a little work-around-y, but it gets the job done until this bug is corrected.
Has anyone else encountered this? What was your solution?
Much of what I am doing for my pet Silverlight 2 project requires me to show/hide different canvases, depending on which "page" you are on within my site. I've seen some Silverlight sites that are actually just different SL apps, and links actually take you to a seperate .aspx page for each one. I wanted to keep the user experience without any postbacks. All AJAX. No wavering from my page. Because of this, each navigation button just hides everything and shows the section it represents.
So each "page" is represented as a canvas. And for the simple example below, it works perfectly.
However, when your canvas contains elements that derive from Control, you don't get the behavior you expect. Here's my canvas with real stuff in it:
What I am finding is that my canvas just doesn't show up. In my code, I know my syntax is correct, because it works for all of the simple canvases like the first one I showed. The moment I add a Button, TextBox, Radio Button, User Controls, etc. the Canvas no longer will change its Visibility property from Collapsed to Visible. This, it would seem, is a major problem. However, there's a pretty simple workaround for this.
Click here to see the example running.
By making my base element for this function something other than a Canvas, it works perfectly. In my example, I have used a StackPanel, and just put my Canvas right inside it as the only element. In this example, all of the contents of my "page" will display as expected now.
Sure, it's a little work-around-y, but it gets the job done until this bug is corrected.
Has anyone else encountered this? What was your solution?
Labels: canvas, jeff blankenburg, Silverlight, silverlight 2, visibility
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
(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...)
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
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
Thursday, June 05, 2008
So today I was tagged by Sarah Dutkiewicz (AKA the Coding Geekette) to answer some questions about how I got into software development. These questions were originally posed by Michael Eaton here. I've got a short, but adventurous history regarding software. Here's my answers:
How old were you when you started programming?
As someone who spent more time on the athletic fields than on the keyboard in high school, I was still a power DOS user when Windows came around. I took the "Computers" class in high school, but it was really more about how to use a mouse than how to make a computer "DO" anything. My first real programming experience would have been writing Pascal and C++ in college. I pursued a Psychology degree, but secretly was taking Computer Science classes behind the scenes. Not sure why I never changed my major. I also really started dabbling in web development because the web had really taken off while I was in college ('95-'98). HTML, Javascript, all the basics. This would turn out to be the foundation of my career.
How did you get started in programming?
Like I mentioned, I have a Psychology degree. I got out of school and tried to use it. Pulling down a salary just over the poverty line, I got frustrated by the always-on-call nature of the job very quickly. Scanning the classified ads in Cleveland, I found a place looking for a "webmaster." I applied, and for a decent raise over what I was making, I was now working for a company in Strongsville creating a new web site for them from scratch. I got this job solely on the merits of having built some small websites in college. No formal degrees. No real qualifications.
What was your first language?
This is a tricky question. My first languages were probably C++ and Pascal, because I used them in college. But my first language I used professionally was VB6.
What was the first real program you wrote?
The job I found in Strongsville would have to qualify as my first program. It was a website using Classic ASP, VB6, HTML, CSS, Javascript, and SQL Server 7.0. I was robust, too. A full set of administration tools let the company's management update the information on the fly for nearly every part of the site. It was so robust, in fact, that my boss eventually realized that I had nothing left to offer, and let me go. Man, was I pissed.
What languages have you used since you started programming?
Hmm...VB6, VBScript, Java, C#, VB.NET, Javascript, CSS, HTML, C++
What was your first professional programming gig?
Oops, I think I answered this above.
If you knew then what you know now, would you have started programming?Absolutely. This industry is constantly changing, growing, and shaping the way almost every other industry works anymore. The fact that a piece of software (Amazon.com) can compete against a behemoth like Wal-Mart is absolutely amazing to me, and it's happening in nearly every vertical. It's a privilege to be a part of this revolution.
If there is one thing you learned along the way that you would tell new developers, what would it be?To agree with Mike Eaton, personal skills go a long way. Those of you that know me know that I am incredibly outgoing, love to meet new people, and could talk for hours on just about anything. The ability to communicate with others (read: business leaders) will be the single most important thing you can work on as a developer. Your ability to think and communicate effectively to your management will go MUCH farther than your ability to apply polymorphism principles to your application. Trust me. The other little tidbit I'll offer is that your career will have EVERYTHING to do with WHO you know, not WHAT you know. Make friends. Go to user groups. Get on Plaxo/Twitter/LinkedIn/Facebook. The physical relationships you create are a far better investment in your future than any 3 day training class.
What's the most fun you've ever had ... programming?
After I left that first programming job, I found there wasn't much for me in Cleveland in the software development space (at least web development). So I tried my luck in Columbus. There, I found a job at an advertising agency called Resource. We were working on the very first e-commerce website for Burton Snowboards. The whole team (about 9 of us) came in early on Monday morning (5:00 AM) to get started on the final push for this site (it was due that Friday for testing and review.) The next time we LEFT THE OFFICE was Wednesday, for dinner. We worked all day and all night, took naps under our desks, and stopped to play a little Foosball once in a while. Working 60 hours straight is not any fun, but the team I was with, and the project we were working on made it worthwhile. Burton even thanked us for our efforts by giving each of us our own snowboard, boots, and bindings! (The snowboard is hanging on the wall in my sportsbar/basement.)
I'm hoping this little list will spread organically, but I'm going to call out a few people to answer these questions as well:
Josh Holmes
Brian Prince
Jennifer Marsman
Jeff Hunsaker
Tim Wingfield
Todd Kaufman
I encourage everyone to take a crack at this list of questions. It lets you get to know your fellow developers a little better, which strengthens that relationship, which you may need to call on the next time you're looking for a job. Everything's got a purpose...so get to it! And comment a link your post here so I know about it!
Labels: jeff blankenburg, software development