Solid Solutions

The initial impression of a Surface unit can be a little underwhelming.  The units gets shipped in a completely clean state, there are virtually no applications pre-installed on the unit.  There is just one to start, the water attract application.  So when the unit starts up you get a nice picture of rocks underwater, and it will respond to your fingers by making ripples in the pond.

Wonderful.

You can touch one of the access points (there’s one in each corner) which act like the “Start” menu in Windows, and it will close the attract application and take you to the Surface Launcher, which appears as a purple ribbon down the middle of the screen.  In any video that I’ve ever seen of the Surface unit, there are a bunch of applications listed in the launcher that you can pick from.  Well, not on your shiny new Surface unit, the ribbon is empty.

Now you can unzip the Surface SDK Samples and run the InstallSamples.bat file that is included with the SDK, which will compile and register all of the sample apps so that they show up on the Launcher bar.  That’s an improvement, and to be honest I’m not sure why Microsoft doesn’t ship it with those samples installed, at least on the developer machines anyway.  Not that it is difficult to add them, it is actually really easy, but when somebody shells out this kind of cash to get a unit, you’d think that Microsoft would want their first impression to be something good, not disappointment that it doesn’t do anything yet.  Imagine how happy you’d be with your iPhone if you took it out of the box, turned it on, and all it had to show you was a blank screen.

Adding your own application to the launcher bar is really easy.  All of the registration is done using a simple XML file that is copied into a special directory on the Surface unit.  Any application that has this XML file in the directory will be automatically added to the launcher assuming that the XML file does not contain any errors in it. 

The directory to copy the file into is C:\ProgramData\Microsoft\Surface\Programs

And the XML file looks like this.  The title appears above the preview picture in the launcher.  The description appears below.  The executable file and arguments tell the unit what to run for this program, the icon image is shown when the application is visible on the launcher bar but is not the one in the middle, and the preview is what is displayed when the application is the center one in the launcher bar.  The preview can be a video if you want, or a series of images.  You can also specify any tags or groups of tags that are to be used in the application.

Ok, so you’ve bought a Surface unit (cool), it’s been shipped to your place of business (finally) and you’ve opened the box to find a shiny black box with a glass top inside (ooh, shiny).  Now what?

Well, first off, get a friend.  The box weighs in at just under 300 pounds, so getting it out of the packing is a job for at least a couple of people.

Secondly, get a sturdy table to set it on, or at least get one if you want to stand around it instead of sit.  It’s only about 24 inches tall, which is ok if you are going to sit on a chair, but quite low if you want to stand around it.  Do your back a favour and get something a foot tall to set it on, preferably with wheels so you can move it around.

Third, get down on the floor and peer under the short sides.  One of them has a couple of thumb-screws that you can undo, one on each side, which will allow you to slide the end off.  Behind that panel are all of the IO slots.  There are 6 USB slots, an VGA monitor port, some RCA video and audio jacks, and a special port for updating the firmware labelled DO NOT TOUCH.  Plug in the included bluetooth adapter for the wireless keyboard and mouse, and plug in an external monitor, and you’re getting pretty close to getting it going.

All you need now is power.  That’s on the other end, along with the hard power switch.  You don’t have to take any panels off this time, but it is a real pain to get the cord plugged into the unit.  It’s easier if you can get a friend to rock the unit up a bit so you can see.  After you get the power cord attached, plug it in and then flip the hard power switch that is right beside the power plug.

Of course, the unit won’t turn on yet, that’d be too simple.  Go back to the end with the IO connections and you will find a soft power button in the bottom left which you can push up to power on the unit.

Ah hah!  And now you have a working, powered on Surface unit.  Unfortunately you don’t yet have the Surface display that you’ve seen in the videos.  The thing is built on Vista after all, so when you turn it on for the first time you have to give it an admin username and password.  Then you have to setup the displays so that you have your desktop shared to the other monitor, and then setup the unit so it knows that there is a second monitor to use for debugging.  This will allow you to run the Visual Studio on the second monitor while seeing the results on the Surface unit itself.

Ok, almost there.  The SDK was already installed by the first-time login script, so there are a bunch of applications available to play with, but none installed where the Surface unit can find them from it’s launcher application.  But if you unzip the SDK samples you can open a solution file that contains all of them, and run one of them at a time.  Just be sure to start up the Surface Input program (which registers your fingers and raises them to your application as events) and the Surface Shell program, which redirects the output to the unit instead of to the debugging screen.

Wow, several hours later you can do a puzzle on the Surface unit, or draw on it with your finger, or even look at a bunch of pictures and throw them around the surface.  If you want it to do more… well, better brush up on your WPF skills.

Oh, you can also read the SDK documentation on the Surface unit if you want.  Seems like a waste of a perfectly good touch screen though.

Databinding is one of the huge improvements in WPF over previous Microsoft technologies.  In Windows Forms there were many properties on controls that could have databinding associated with them, but certainly not all of them, and the objects you could bind from as a source were limited as well.

In WPF most of those restrictions are lifted.  You can bind to virtually any property on any control, and you can use just about anything as a source, including properties on another control.  For example, this has 4 buttons down the side that change the color of the “Selected Color” control.  The databound buttons all have their Background bound to the Background of the Selected Color control, so when you change the Background of the Selected Color control, the others automatically update theirs as well.

The XAML declaring the objects on the screen

And the single line of code I had to write to get the buttons to change the Background on the TextBlock.

The binding magic is done by the snippet

This is the syntax for binding in WPF.  The curly braces { } tell the compiler that we are putting in something that needs to be de-referenced before it can be use. (think <% %> in ASP)  In this case, the first word “Binding” tells the compiler that we are declaring an object of the type Binding.  The rest of the statement is simply properties on the object that need to be set, in this case we use ElementName to identify which UI element we want to use, and Path which tells us which property on the element to use.

This can also be written out in long-hand like this:

This makes it easier to see what the special notation is doing.  The Button has a Background property on it.  For that Background property we are declaring a Binding object to use to set the content.  That Binding object has 2 properties that we are interested in, the ElementName and the Path. 

The shorthand notation is way more compact, but it is also a little more cryptic.  The biggest advantage of using the long-hand notation is that the intellisence is much better at showing you what the possible properties are that you can use.

When you type the shorthand notation ‘Background=”{‘ Visual Studio pops up a list of colors which can be set to the Background property, effectively ignoring the {.  And the Binding keyword is case sensitive, but it won’t autocorrect the casing for you like it will in other places.  Both of these are addressed in the long-hand notation, so it is much easier for beginners to use, if not quite so pretty when they are done.

Being able to bind to properties on other controls is a really neat idea that is likely to get used in all the wrong places.  Imagine a grid control that is displaying data, with a detail view under the grid used for editing.  This is a pretty common screen design.  With this databinding you could, if you wanted to, bind the detail section directly to the grid’s currently selected row, and then databind the grid to the actual datasource.  This would conveniently update the detail view as soon as you selected a new row in the grid, and if you set the binding as two-way, it would even automatically update the grid if you changed a value in the detail.

But that doesn’t make it a good idea necessarily.  You have data changes being pushed through a display-only control on their way to the datasource, which is a rather round-about way of getting there.  It would be far cleaner to bind both the grid and the detail to the same datasource, and have the detail push any changes directly to the datasource.  The datasource could then push those changes back up to the grid for display.  This way the grid remains a display-only control, and does not become the source of data updates which the grid is not actually capable of making.  To make this easier, there is a “Master-Detail” type datasource, which displays the entire list for you as the master, but also tracks the currently selected row for use in the detail.  Using this makes it almost trivial to setup this kind of screen.

Databinding in WPF has far more to offer than just binding to other control’s values thought, it can also bind to XML objects, database objects, or just about any other object that is defined in the application, including any business layer objects that you may have written or generated.  Databinding is incredibly powerful and pervasive throughout the WPF framework, this is just one thing you can do with it.

WPF, like most modern development languages, has many ways to do similar things.  Take these two ways of styling text.  They are both done in pure XAML, not with the help of any kind of artistic program.  And they both do a bit of magic on some text, but they do it in very different ways.

The first one is done using two labels layered on top of each other with the same text in them.  The Label in the front is a standard Label, while the one in the back has a couple of transformations on it to make the shadow.  The second example is created by taking a snapshot of the contents in a TextBlock, flipping those contents over and applying a mask to get it to gradually fade out as it goes down.  With a little effort, you could make this one look like the text was sitting in water instead of on a mirror.

So to build the first one, first we put a Label control into a Grid, set the text we want to display, and then set any attributes we want to put on the text such as size and weight.  The Padding numbers are in the order of Left, Top, Right and Bottom.  These put the specified number of pixels around the content, much like cell padding does for an HTML table.  The numbers I chose will help line up the 2 layers so that the shadow doesn’t start way below the main text.

Which looks like this.  (The shadow around the picture is added by the blog software, not by the XAML)

To add the shadow we have to add an additional label with some transformations on it.  This is done using 2 different transformers at the same time.  One resizes the text so it is taller, and the other skews it to the right so it goes back into the distance like a shadow.  Because we are using 2 transformers at the same time, and a Label (as most controls) can only have one content transformer on it, we compose the two transformers into a TransformGroup and apply the whole thing to the Label.

Which gives us this:

Well, that’s not quite right.  It appears that the shadow effect is ON TOP of the text we are trying to shadow.  The Z order is incorrect.  Which is an interesting feature of WPF when you are composing complex controls.  The Z order, if it is not explicitly set, is implied in the order that the controls are added.  In this case, we added the shadow effect to the grid cell AFTER we put in the label that had the main text.  Simply changing around the order of them so that we draw the shadow first, and then the main text, fixes the problem.

The other example is a little more complicated in how it works, but no more complicated in how to set it up.  It simply has a TextBlock that has some text in it which is the main text.  Then a rectangle is used to take a picture of the TextBlock’s contents, flip it over and make it bigger, and that is displayed below the main text by adding it to a StackPanel.  StackPanels automatically stacks controls one on top of the other.  Finally an opacity mask is applied to the rectangle, which is a fancy way of saying that we put a semi-opaque layer on top of the rectangle and fade it out to completely transparent as we near the bottom using a linear brush.  This gives us the fuzzy-to-gone appearance of the reflection.

The only other really tricky thing is how the VisualBrush is binding it’s contents to the contents of the TextBlock named txtTest.  The idea of data binding is a huge idea in WPF, virtually anything can be databound to virtually anything else, including another control’s values.  I’ll go more into the databinding thing in a future post, but for now just recognize that this syntax is binding the rectangle’s contents so they are an image of the text in the TextBlock.

Which button looks like it was thrown together by a developer with the artistic skills of a blind monkey, and which one looks (a bit more) like a professionally designed UI?

I think we can all agree that the second button looks much more professional. To be fair, it’s not just that developers typically aren’t heavy into the artistic skills; the tools available to the developers to date have been limited. In a Windows Forms application you could change the backcolor of a button, the size, and even the font color, but that’s where your ability to change things stopped. To get a professional looking button you had an artist draw you a pretty picture in an art program and give you the image file, and you put that on top of your button. And you usually had to have more than one picture file, since the button usually looks differently when it is pressed down. Imagine a basic calculator with 10 digits on it and 6 symbols, that is 32 pictures that the artist has to provide you. And if you decide to change the color scheme, that is 32 image files that the artist has to individually update.

Well it’s a lot easier with WPF. One of the premises of WPF is that a control has a default look, and it has a default behaviour, but both are completely changeable by the developer without having to inherit the control. So I decided to show you how to make a button that looks a little better (with the help of a book).

The basic idea of making a “glassy” button is to have a bright background, then a layer with a shadow effect, your button, and then a layer on top to make it shiny. We put the number behind the shiny layer. This is all done using XAML, and the ContentTemplate is simply a composed set of layers for the display. To make this button it looks like this. It’s not as hard as it looks.

First we make the button have a slightly different color for the text, and we bold it. Without the bold it has trouble being seen through the shiny layer, and the color change makes it look a bit faded (the first 2 bytes of the color are a transparency code, FF is solid, 00 is transparent).

Next we redefine the Control Template that is used to display the button. Note that we are still going to be using the button control, we are just changing how it looks. So first we draw a bright yellow rounded rectangle to provide the glow through the button. The rounding is done by the RadiusX & RadiusY properties. By itself it looks like this.

Next we add a dark shadow color in the bottom right so it looks like the button is sitting on the grid in 3D. This is done using a gradient fill, which simply starts at one color (almost black in this instance) and moves towards another color (transparent in this case). The RadialGradientBrush starts at a point in the canvas and moves out from that point. The coordinates for the button are 0.0 for the top left, and 1,1 for the bottom right. So this is saying “Starting at coordinates 0.9,0.9, paint color #101010 until you get 10% of the size of the button away from that point, and then fade to transparent, and be completely transparent by the time you get 80% of the size away from the initial point.” Notice that it fades slower going horizontally compared to vertically, that’s because the button is wider than it is tall.

Now we add our actual button color on top, making it partly opaque so that we can see our other 2 layers that we have so far. We also add a border that is not opaque at all.

Then we add our ContentPresenter to the button. In this case our content is a text string “7” but it could easily be more complex than that, such as a picture, or a spinning piece of text, or even a bunch of other controls. The content of the button is set on the button itself (think “Text” property, but with more options) and we are just making a template here, so we are not actually setting the text to “7”, just providing instructions on where to put the content when it is provided.

Finally we add a top shine layer that makes it look like we are reflecting light off of the top part of the button. This one is white fading to transparent as it goes down the button, and the LinearGradiantBrush goes in straight line. In this case, it is starting from the middle of the top of the button and going to the middle of the bottom. If we wanted the shine to be angled so that the light was coming from the top left, we could start the gradient closer to the top left corner and head towards the bottom right.

And voila, we have a shiny, glassy button that looks a little rounded. And we didn’t have to involve any artists or their arcane art programs. I’m sure they could make it look much better than I did, but this is far and above what buttons normally look like in my apps. And because it was declared as a Window.Resources at the top of the XAML, any button on the window is automatically going to get this content template. It could also be made a resource at the application level so all windows can use it, or even externalized into a “MyCompanyTemplates” file that is imported.

One of the really cool things is that, because this content template is built in a Grid control (with everything in the first grid cell), and we didn’t use any hard-coded units, this template will automatically resize itself. If you need a 300×300 button, this thing would look the same as it does at these smaller sizes, without a pixel to be found, and all without a line of code to make it work. Of course, this button is not complete, it is still missing the “pressed” animation for instance, and there are some other things we could do to make it better for the user’s experience, but I’ll cover those in another blog.

Oh, and I didn’t come up with this on my own. Credits for the design go to the authors of the “WPF in Action with Visual Studio 2008” book from Manning Publications.