WPF/Silverlight Insiders » Tutorials

Silverlight Tutorials: Silverlight Basic – SpinningCube

Michael Sync — Sat, 30 Jan 2010 17:47:37 +0000

This article is written by Einar Ingebrigtsen (Silverlight MVP). It is a part of “Silverlight Basic”, the third chapter of “Silverlight Tutorials for Beginners.”

Download : SpinningCube.zip (12.9 KB)

Silverlight represents a subset of WPF and it’s features, one of the features that aren’t part of the subset is 3D. Silverlight 3 introduces the ability to project any UIElement in 3D by rotating them around the X,Y and Z axises. But geometries that consist on anything else but planes, typically triangles would not perform well using the PlaneProjection. Silverlight has primitives that can be used instead, such as Polygon. The Polygon can have N number of sides, at least 3, which is perfect for representing 3D models.

This tutorial is very basic and does not involve any heavy geometry math. If you want to do more advanced geometry stuff with cameras, texturemapping, lighting and such, Balder could be place to look. Balder is a full 3D engine I started writing back in early 2007 and is opensource, you can find it here.

Getting started

First thing you need to do is to create yourself a Silverlight project and leave all the defaults in.

Rendering container

This sample needs a container to add polygons to. When you first created the project a MainPage.xaml file was added to the project, opening it you’ll see there is a tag at the top. Lets give it a size and a background color:

Now we have a container that we can add polygons to that has a dimension of 640 by 480 pixels and the background is black.

The rendering loop

The first thing we will be needing is a timer that gets called on a regular basis for handling all the calculations and generation of polygons that will be visible on the display. It is very important that this timer is running in the same thread context as the main Silverlight thread. Manipulation of the visual tree is not allowed from other threads. Silverlight has something called the DispatcherTimer that we can use for this. The DispatcherTimer can run with the same framerate as the plugin has been specified to run with, default being 60 frames per second.

In the MainPage.xaml.cs file in your project, we need to add the following code in the constructor, right beneath the InitializeComponent() method call:

In the Tick event we are specifying a method called Render, which will be a method you have to add in the same class that will be called everytime rendering will occur:

A cube

To define our cube we need points in 3D space, these are called Vertices (one vertex, several vertices). We need to add a simple class to represent a vertex. The class represents the original vertex before we have done any calculations on it and also contains the finished calculated vertex ready to be used on our 2D screen.

As you can see, the vertex contains an X,Y and Z representing the coordinate in 3D space. In addition it contains the rotated version and the translated
(2D) version. Now that we have the definition of a vertex, we need the definition of a triangle that hooks itself on 3 vertices, we call these Faces. A face
contains 3 integers representing an index into the array of vertices for the object we are rotating. Add a class called Face and make it look like this:

Next, we need the actual cube and methods for rendering itself. We create a class called Cube. In the Cube class we need to define the vertices that defines the cube. Add the following at the top of the class:

The purpose the constants at the top is to be able to change the size of the cube with ease.
And we need an array of faces that hooks up to these vertices :

Next we need to actually render the cube. The rendering is divided into two processes, one for calculating all the vertices and one for generating the polygons. First we need to define a method for calculating the vertices:

Note that the method takes the rotation around the 3 axises in as parameters, and also something called xoffset and yoffset.

The offsets are used for centering the finished result, which will be shown later in the render method. Now we need a method for generating the polygons:

We now have all the methods we need to finish the rendering. In the Cube class, we expose a public method to tie it all together:

The method takes a panel as the container in which it will render all the polygons to and the rotation around the 3 axises.

The xoffset and yoffset is calculated by taking the containers width and height and divided by 2, which is the center of the container.

All we need now is to go back to our MainPage.xaml.cs file and create our cube and call the rendering method.

Add a private field holding the Cube instance, like this:

In the constructor we can now create the cube:

Then we define some variables that we can manipulate every time we render, these will be used for rotating the cube. In the MainPage class, add the following fields:

Now, we can add a body to the Render method:

That should be just about everything we need to get a spinning cube on the screen.
The result should be something like this:

Conclusion

Silverlight has come a long way since its initial first release in 2007, but still real 3D is missing. In Silverlight 3 there has been done some work by Microsoft on the subject with the introduction of plane projection. For a simple cube like in this tutorial, one would be better off using that technique. But, if you want to represent more advanced geometries, the technique in this tutorial is better. There are some limitations though. Due to the way Silverlight works internally with the main rendering engine and the CLR being separated completely, there are speed limitations to how many polygons it is possible to render. So really complex geometries is something that would not perform well. Another issue is texturemapping. Silverlight does not give you any ability to represent the U,V coordinates within the texture for every point in a polygon. It is possible though to get this working by manipulating the matrix of the imagebrush specified, but again, performance will be impacted. In the Balder engine, we have overcome these limitations by creating our own drawing routines, not using any Silverlight primitives at all. Since the CLR is quite speedy, this enables us to draw quite complex objects.

Silverlight Tutorials: Data Binding

Michael Sync — Sat, 30 Jan 2010 17:27:55 +0000

This article is written by Emil Stoychev (Silverlight MVP).This is the fourth chapter of Silverlight Tutorials for Beginners series.

Data Binding is simple, yet powerful way to connect (bind) your business model and user interface (UI). When the data in your business model changes the UI reflects changes automatically and vice versa (when a user changes the data in the UI the data in the business model is changed).

Binding establishes a connection between two dependant items. Basically, it is an automatic way of transferring information from one item to another.

Content

Data Context, Dependency Property, Dependency Object
Types of Binding
Converters
Validation in Binding
Consuming Services
Sample

Data Context, Dependency Property, Dependency Object

Data Context

In Data Binding we have two objects: target – the UI element and source – the data (business model, entity, etc). While the source property can be a normal .NET property, the target property must be a DependencyProperty. More on that later in the tutorial.

The DataContext is actually the source of data bound to the target. The default source of a binding is the data context. DataContext is inherited to child elements and thus ideal for scenarios where you want to bind multiple elements to a single data source. DataContext is a property of FrameworkElement. Let’s see this in an example:


…



…

ContactCard is a custom defined class with three properties – FullName, Position and Email.

All bindings set to the TextBlock elements inside the StackPanel have source the DataContext of the StackPanel – {StaticResource JohnsBusinessCard} in this case.

In case of items control we can think of the DataContext as the particular data item that we bind to at run time. So let’s say we have a list of ContactCard objects set as a DataContext to an ItemsControl. The data context of each of the items in the ItemsControl is the corresponding list element in the list (set as DataContext).

Dependency Property and Dependency Object

DependencyObject and DependencyProperty are fundamental concepts in Silverlight/WPF that provide the base for the underlying property system.

< to be continued… >

Types of Binding

With each binding you can set Mode which defines the direction of the data flow as well as when the binding occurs. There are three available binding modes in Silverlight:

OneTime – set the target and forget the binding. This mode is useful when you display data and you know that this data will never change or you don’t need to change it. Changes in the source are not propagated to the target.
OneWay – set the target and update it every time the source changes. This is the default mode. Use it in cases where the user can’t change the target, but you still want to keep the target updated once the source is changed from somewhere (say the code).
TwoWay – keep both the target and the source updated. Once the source is changed its new value is propagated to the target and vice versa. This is useful in cases where the user can change the target and you want the changes to be written back to the source.

Lets take a look at the syntax:

Depending on your case you can select one of the three binding modes. To choose which one is most appropriate for your case you can try to answer yourself the following questions in this order:

- Do I need to update the target when the source change? (yes – OneWay or TwoWay; no – OneTime)

- Do I need to reflect the changes done on the target to the source? (yes – TwoWay; no – OneWay)

< continue with INotifyPropertyChanged… >

Converters

A common scenario in data binding is that you need to format the data displayed to the user. Intuitive examples for that are formatting of DateTime and number values. In Silverlight and WPF this is achieved by applying a ValueConverter (or just Converter) to the data you are binding to.

Converters are classes that derive from the IValueConverter interface. This interface have two methods that should be implemented – Convert and ConvertBack. The Convert method is used when the data flows from the source to the target, while the ConvertBack is used when the data flows in the opposite direction – from the target to the source. In case your binding uses OneTime or OneWay mode you can go only with implementing the Convert method, but that is not considered a good practice as the converters are reusable chunks of code and you never know who and in what situation will use it.

Lets see what a converter look like:


public class DateTimeConverter : IValueConverter
{
    public object Convert( object value, Type targetType, object parameter, System.Globalization.CultureInfo culture )
    {
        DateTime dt = (DateTime)value;
        return dt.ToString( "dd MMM, yyyy", culture );
    }
    public object ConvertBack( object value, Type targetType, object parameter, System.Globalization.CultureInfo culture )
    {
        throw new NotImplementedException();
    }
}

Here only the Convert method is implemented. It is important to note that you should always validate the value parameter as it could not be from the type you expect.

// show the xaml syntax – convert as static resource

This is probably the most simplest converter you can ever write. The make it more flexible you can use a ConverterParameter. In different scenarios you may want to format the DateTime value in different way. The specific format can be passed through the ConverterParameter.

Validation in Binding

; content

Consuming Services

; content

Sample

; content

Silverlight Tutorials: Styling and Templating

Michael Sync — Sat, 30 Jan 2010 15:47:15 +0000

This article is written by Alexander Golesh (Silverlight MVP).

This is introduction to Silverlight styling and templating features. This is also the fifth chapter of “Silverlight Tutorials for Beginners” series.

Content

Styling
Templating
Conclusion

Styling

Silverlight controls has default look and feel, which is very close to standard Windows application look and feel.

Style is a mechanism in Silverlight that allows you to encapsulate control property values as reusable resources. This is conceptually similar to CSS with HTML. Style defines control property values as reusable resources.

The same button which was used at figure 1 could have pretty non-standard look-and-feel.

Style also allows you to achieve same look-and-feel for multiple controls of the same type across all the application.

Let’s see how to create the style.
Let’s create a simple button defining Button element in XAML inside the StackPanel:

Style defined in “Style” tag in XAML file as a part of some content resources. Placing a style inside a specific XAML page will enable its use in this specific content, while placing it in App.xaml will enable it to be reused across all pages and controls in application. Style also could be placed inside specific panel element, which will allow using this style only to the panel’s child elements. The style defined as a part of the Resources for chosen element.
Sample style definition:

In this case we defined the style as a part of some StackPanel, which will allow using this style only for child’s of this StackPanel. The style has 2 required attributes:

TargetType – the Type of the element which allowed using this style. The type itself could specify the base class for the group of elements, for example ButtonBase – specifying it as TargetType enables to use this style for any derived class, like Button, RadioButton, CheckBox, etc.
x:Key – the name of the style, which will be used by the elements to access the style.

Style defines the properties of the target element by specifying property name and the desired value in “Setter” element. In our case the style define values of 3 properties for the Button: Width, Height and Background.

Now it is a time to apply this style on our button:

Style applied by specifying “Style” attribute of the desired element. Style (and not only style) specification uses special syntax called Markup Extension. This syntax is merely just a specification of some special command (in opposite of the attribute value, which usually being placed to the attribute) – in our case it is “StaticResource”. To distinguish special syntax from regular value it being placed inside curly braces “{…}”.

In our case StaticResource means that XAML parser should look for the resource named btnStyle and use the value of this resource as the value for the attribute.

Now our button has specified look. We could use this resource as many times as we need inside the scope of our style definition, and all elements with the same style will have same look and feel.

If we will change the definition in the style, all elements with this style applied will get the change:

Any element could specify any property value at the element definition, and it will override the value given by style (if applied)

Style could “derive” from another style by using “BasedOn” attribute.

Let’s see how to define style hierarchy for the buttons, and how it behaves:

In this sample we created 3 styles for the Button type: ButtonBaseStyle, DerivedButtonStyle and ExtendedButtonStyle.

The DerivedButtonStyle uses BasedOn attribute to derive from ButtonBaseStyle. The BasedOn defined by using same Markup Extension syntax to define the parent style BasedOn=”{StaticResource BaseButtonStyle}”. The DerivedButtonStyle got all the properties defined in base style and adds 3 new properties. The ExtendedButtonStyle uses BasedOn attribute to derive from DerivedButtonStyle. It gets all the properties defined in DerivedButtonStyle and in ButtonBaseStyle, adds new property definitions and also overrides some of properties defined in base classes: Width, Height and Background.

Applied to the button will give use following look and feel:

The existing style could be applied not only by using Markup Extension in XAML, but also form code behind:


Style style = this.Resources["BaseButtonStyle"] as Style;

if (null != style)

btnSimple.Style = style;

The style itself also could be defined in code behind.

Let’s change the style of the button on the click event. The button definition:

The initial look:

The event handler code:


private void Button_Click(object sender, RoutedEventArgs e)
{
Style myStyle = new Style();
myStyle.TargetType = typeof(Button);

Setter setter = new Setter();
setter.Property = Button.BackgroundProperty;
setter.Value = new SolidColorBrush(Colors.Yellow);

myStyle.Setters.Add(setter);

btnNewButton.Style = myStyle;
}

And after the code being executed the button gets following look:

The styling is powerful feature which allows us to configure basic set of properties for the element. But how it helps us to create the button which looks like this:

The colors and fonts – we already know. But what about the shape of the button?

To completely change the UI for the element we have to use Template feature in Silverlight.

Templating

Template allows to completely customize/change the look and feel of the controls. It allows developers and designers to sculpt the UI of controls in both subtle and dramatic ways, and enables a tremendous amount of flexibility to create exactly the user experience desired.

Template could be created as a standalone resource (with same scope definitions like the styles) or templates could be created as a part of style for the control.
The styles are the recommended location to create templates.

Templates created by defining “ControlTemplate” element with XAML. Each template must define its “TargetType” (exactly like styles). In case of template definition as a standalone resource (not within a style) it also should have key defined within “x:Key” property.

Let’s define simple template for a button:

To apply the template on button use markup extension syntax (exactly like we did for styles):

Well, the button is not exactly like planned – the text is “Close” (as defined in template) and not “Hide Me” (as defined in the control itself), the size of ellipse is also seems to be wrong. This behavior is because we didn’t specify that the values for those attributes should be taken from the actual control the style being applied on.
In case of temple we could/should specify, that values for the attributes should be taken from the actual control. To do it we will use additional markup extension – “TemplateBinding”. Also, in a case of button (which is a Content Control), the text should be displayed as a content and not as a TextBlock. Let’s rewrite the ControlTemplate.

When applied to the button

The button looks like expected.

The ControlTemplate definition as a part of a style should be in a value of Template property.

Sample (partial) style definition: