{"id":384,"date":"2008-06-05T00:00:00","date_gmt":"2008-06-05T00:00:00","guid":{"rendered":"https:\/\/test.simple-talk.com\/uncategorized\/data-and-silverlight-2-data-binding\/"},"modified":"2021-05-17T18:36:47","modified_gmt":"2021-05-17T18:36:47","slug":"data-and-silverlight-2-data-binding","status":"publish","type":"post","link":"https:\/\/www.red-gate.com\/simple-talk\/development\/dotnet-development\/data-and-silverlight-2-data-binding\/","title":{"rendered":"Data and Silverlight 2: Data Binding"},"content":{"rendered":"
\n

Data and Silverlight 2: Dependency Properties and Binding Syntax <\/h1>\n

Unlike Silverlight 1, Silverlight 2 has controls, .NET CLR support and data binding features.  This article is the first of a series that describes the basic elements of data binding with Silverlight 2. <\/p>\n

Data binding<\/h2>\n

While binding can be established using a manual push and pull process, the data binding capabilities of XAML and Silverlight offer more power and flexibility with less runtime code. This provides a more robust data bound user-interface with fewer failure points than with manual binding. <\/p>\n

The process of Automated Data-Binding in Silverlight links a UI FrameworkElement<\/b> to a data source entity and back. The data source entity contains the data that will flow to the FrameworkElement<\/b> control for presentation. The data can also flow from the control in Silverlight back to the entity. For example, an entity may be bound to a series of controls, each of which is linked to a specific property on the entity, as shown in Figure 1.<\/p>\n

The entity is set to the DataContext<\/b> for a control. This then allows that control, or any child control of that control, to be bound directly to the entity. There are many important players in this process that will be introduced in this article, including the DataContext<\/b>, binding modes, and dependency properties on FrameworkElement controls. Each of these plays a critical role in customizing how the data binding process operates in a Silverlight application. <\/p>\n

\"513-image001.png\"<\/p>\n

Figure 1.<\/b> Data binding in Silverlight 2<\/p>\n

There are some basic rules to follow when you are setting up data binding in Silverlight. The first rule is that the target element of a data binding operation must be a FrameworkElement<\/b>. The second rule says that the target property must be a Dependency Property. <\/p>\n

Rule #1: FrameworkElement<\/h2>\n

The target of data binding must be a FrameworkElement<\/b>. This many sound limiting but it is quite the opposite. The FrameworkElement<\/b> has many subclasses that inherit from it. Figure 2 shows several controls that inherit from the FrameworkElement<\/b>. The FrameworkElement<\/b> extends the UIElement<\/b> class and adds capabilities that allow it to control layout and support data binding. <\/p>\n

Any control that derives from FrameworkElement<\/b> can be used for layout on a page or user control, and can be involved in data binding as a target. There are other classes that derive from some of the subclasses shown in Figure 2, such as System.Windows.Controls.Textbox<\/b>, too. <\/p>\n

In data binding, both a data source and at least one target are required. The target can be a control or set of controls on a page (or within a user control). Basically, the data can travel in either direction between the source and the target. The sources of data are generally instances of objects such as a domain entity. The properties of the data source are referred to in the targets, so that each target control knows which property of the entity it should be bound to. <\/p>\n

\"513-Leavethisalonetoo.jpg\"<\/p>\n

Figure 2.<\/b> FrameworkElement Class Hierarchy<\/p>\n

Rule #2: Dependency Properties<\/h2>\n

As mentioned previously, the second rule of data binding in Silverlight is that the target must be a Dependency Property. This might initially seem to be a restriction, especially since one of the first controls people think about when they think of data binding is the TextBox’s Text property. However if you take a look at the source code (using a tool like Lutz Roeder’s .NET Reflector) for the Text property of a TextBox you will see that it too is a Dependency Property. In fact most properties that you can think of are Dependency Properties, which is great, since that means you can use data binding with so many properties.<\/p>\n

Dependency Properties are data-bound properties whose value is determined at runtime. The purpose of dependency properties is to provide a way to determine the value of a property based on inputs including, but not limited to, user preferences, resources, styles, or data binding.  An example of a Dependency Property can be seen in the XAML code snippet below by looking at the Fill property.<\/p>\n

<Rectangle Fill=\"#FFE5CECE\" Grid.Column=\"0\" Grid.Row=\"0\"  RadiusX=\"20\" RadiusY=\"20\" Opacity=\"0.8\" StrokeThickness=\"0\" \/>\n<\/pre>\n
The Rectangle control’s Fill property is a Dependency Property that is set to a specific color, in this case. The Fill property’s value could be determined using a resource or by data binding to an object. This would allow the color of the rectangle to be determined at runtime.<\/p>\n
Dependency Properties are not declared as a standard .NET CLR type, but rather they are declared with a backing property of type Dependency Property<\/b>. The code in Example 1 shows the public facing property Fill<\/b> and its type Brush However you’ll see that its backing property is not Brush<\/b> but rather the type Dependency Property<\/b>. You can always identify a Dependency Property by looking at its backing property’s name. If the backing property name has the Property suffix then it is generally the backing property for a Dependency Property.<\/p>\n
Example 1<\/b>. DependencyProperty<\/p>\n
C# code<\/b><\/p>\n
public\nstatic readonly DependencyProperty FillProperty;public\nBrush Fill {\nget { return (Brush) this.GetValue(FillProperty); }\nset { base.SetValue(FillProperty, (DependencyObject) value); }\n}\n<\/pre>\n
VB Code<\/b><\/p>\n
Public Shared ReadOnly FillProperty As DependencyProperty Public\nProperty Fill() As Brush Get\nReturn CType(Me.GetValue(FillProperty), Brush)\nEnd Get\nSet(ByVal value As Brush)\nMyBase.SetValue(FillProperty, CType(value, DependencyObject))\nEnd Set\nEnd Property\n<\/pre>\n
Table 1 shows a quick reference of these terms applied to the code in Example 1<\/p>\n\n\n\n\n\n\n\n\n
\n
Term<\/b><\/p>\n<\/td>\n
\n
Description<\/b><\/p>\n<\/td>\n
\n
Explanation<\/b><\/p>\n<\/td>\n<\/tr>\n<\/thead>\n
\n
Dependency Property<\/p>\n<\/td>\n
\n
The property named Fill<\/p>\n<\/td>\n
\n
A property that is backed by a field of type Dependency Property<\/p>\n<\/td>\n<\/tr>\n
\n
DependencyProperty <\/p>\n<\/td>\n
\n
The type of FillProperty<\/p>\n<\/td>\n
\n
A type that defines the backing field<\/p>\n<\/td>\n<\/tr>\n
\n
Dependency Property Identifier<\/p>\n<\/td>\n
\n
The instance of the backing property,FillProperty . This is referred to in the CLR Wrapper code with the GetValue and SetValue methods.<\/p>\n<\/td>\n
\n
An instance of the Dependency Property<\/p>\n<\/td>\n<\/tr>\n
\n
CLR Wrapper<\/p>\n<\/td>\n
\n
The setter and getter accessor code for the Fill property.<\/p>\n<\/td>\n
\n
The getter and setter for the property<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
 <\/b>A dependency property can also get its value through a data-binding operation. Instead of setting the value to a specific color or a Brush, the value can be set through data-binding. When using data-binding, the property’s value is determined at runtime from the binding to the data source.<\/p>\n
The following XAML example sets the Fill for a Rectangle using data-binding. The binding uses an inherited data context and an instance of an object data source (referred to as MyShape<\/i><\/b>). The binding syntax and the DataContext<\/b> will be explored later in this article.<\/p>\n
<Rectangle Fill=\"{Binding MyShape.FillColor}\"  Grid.Column=\"0\" Grid.Row=\"0\" \nRadiusX=\"20\" RadiusY=\"20\" Opacity=\"0.8\" StrokeThickness=\"0\" \/>\n<\/pre>\n
Besides basic data binding, styles and templates are a huge beneficiary of using dependency properties. Controls that use styles are indicated through a StaticResource<\/b> (defined in app.xaml or defined locally). The style resources are often set to a Dependency Property to achieve a more elegant appearance.<\/p>\n
Dependency Property values are determined using an order of precedence. For example a style resource may set the Background Dependency Property to White<\/i><\/b> for a canvas control. However the Background color can be overridden in the control itself by setting the Background property to Blue<\/i><\/b>. The order of precedence exists in order to ensure that the values are set in a consistent and predictable manner. The previous example of the Rectangle control shows that the locally-set property value has a higher precedence than a resource.<\/p>\n
When creating a binding, a Dependency Property of a FrameworkElement<\/b> must be assigned to the binding. This is the target of the binding operation. The source of the binding can be assigned through the DataContext<\/b> property of the UI element or any UI element that is a container for the bound UI element.<\/p>\n
Silverlight Binding XAML Markup Extensions<\/h2>\n
One of the main pieces of functionality offered by the Dependency Property is its ability to be data bound. In XAML, the data binding works through a specific markup extension syntax. Alternatively, the binding can be established through .NET code. A set of XAML attributes exist in order to support the data binding features. A basic example of the usage of these extensions is shown in the pseudo-code examples below.<\/p>\n
<someFrameworkElement property=\"{Binding}\" .http:\/\/www.simple-talk.com\/><someFrameworkElement property=\"{Binding Path=pathvalue}\" .http:\/\/www.simple-talk.com\/> <someFrameworkElement     property=\"{Binding oneOrMoreBindingProperties}\" .http:\/\/www.simple-talk.com\/><someFrameworkElement property    =\"{Binding Path=pathvalue, oneOrMoreBindingProperties}\" .http:\/\/www.simple-talk.com\/><\/pre>\n
The element must be a FrameworkElement<\/b> (thus the name someFrameworkElement<\/i><\/b>). The property<\/i><\/b> would be replaced with the name of the property that will be the target of the binding. For example the element might be a TextBox and the property might be Text. To bind the value of the property to a source the binding markup extensions can be used. <\/p>\n
The Binding attribute indicates that the value for the Dependency Property will be derived from a data binding operation. The binding gets its source from the DataContext<\/b> for the element or the DataContext<\/b> that is inherited from the closest parent element. To bind an element to an object that is the DataContext<\/b> (and not to a property of the object), all that is needed is the Binding<\/b> attribute (see the first line of XAML from the previous example). For example, this is usually the case when binding an object that is a list to a ListBox.<\/p>\n
The second usage of the binding markup syntax is to specify a pathvalue<\/i><\/b>. This can be the name of a property that exists on the bound object. For example, to bind a TextBox’s Text property to the CompanyName<\/b> property of an object in the inherited DataContext<\/b> the following code could be used:<\/p>\n
<TextBox x:Name=\"tbCompany\" Text={Binding CompanyName}\"\/><\/pre>\n
Binding Extension Properties<\/h3>\n
Additionally, there are a handful of other binding properties (referred to in the previous example as oneOrMoreBindingProperties<\/i><\/b>) that can be set with the XAML binding extensions in Silverlight. These properties are:<\/p>\n
    \n
  • Converter  <\/li>\n
  • ConverterCulture  <\/li>\n
  • ConverterParameter  <\/li>\n
  • Mode  <\/li>\n
  • Source  <\/li>\n
  • Path  <\/li>\n
  • NotifyOnValidationError  <\/li>\n
  • ValidatesOnExceptions <\/li>\n<\/ul>\n
    The Mode indicates the binding mode that specifies how the binding will operate. Valid values for the Mode property are OneTime<\/b>, OneWay<\/b> and TwoWay<\/b>. An object reference can be set to the Source property. If the Source property is set the object reference will override the DataContext<\/b> as the data source for this binding. All of these properties are optional. The default value for the Mode is OneWay while if the Source property is omitted the data source will defer to the DataContext<\/b>.<\/p>\n
    Keep in mind that a Dependency Property follows an order of precedence to determine its value. If a Dependency Property is bound and in code the property is set to a value explicitly, the binding is removed. For example the tbCompany<\/b> TextBox in the previous example is bound to the CompanyName<\/b> property of the DataContext<\/b>. If the Text property of tbCompany<\/b> is set to Foo<\/i> in code, then the binding is removed.<\/p>\n
    DataContext<\/h1>\n
    The DataContext<\/b> refers to a source of data that can be bound to a target. The DataContext<\/b> often is set to an instance of an entity. Once set, the DataContext<\/b> can be bound to any controls that have access to it. It can be used to bind all controls within a container control to a single data source. This is useful when there are several controls that all use the same binding source. It could become repetitive to indicate the binding source for every control. Instead, the DataContext<\/b> can be set for the container of the controls.<\/p>\n
    Each FrameworkElement<\/b> has a DataContext<\/b>. This includes the instances of the UserControl <\/b>class that the examples in this article have demonstrated, since the UserControl<\/b> class inherits from the Control class which in turn inherits from the FrameworkElement<\/b>  class. This means that, on a single UserControl<\/b>, there could be objects assigned to dozens of DataContext<\/b> properties of various FrameworkElement<\/b>  controls. For example the UserControl<\/b>, a layout control such as a Grid, and a series of interactive controls such as the TextBox, CheckBox and ListBox controls might all have their DataContext<\/b> property set. <\/p>\n
    To use the DataContext<\/b>, the XAML must also be modified using the binding markup extension syntax. The newly modified XAML for the UserControl<\/b> is shown in the code example below. This code is only the portion of the entire XAML file that shows only the elements where binding takes place.<\/p>\n
    <TextBox x:Name=\"tbFirstName\" Grid.Column=\"1\" Grid.Row=\"0\"  Margin=\"10,5,10,5\" HorizontalAlignment=\"Left\" Height=\"30\" \nWidth=\"240\" Style=\"{StaticResource textBoxStyle}\" \nText=\"{Binding FirstName}\"\/>\n<TextBox x:Name=\"tbLastName\" Grid.Column=\"1\" Grid.Row=\"1\" \nMargin=\"10,5,10,5\" HorizontalAlignment=\"Left\" Height=\"30\" \nWidth=\"240\" Style=\"{StaticResource textBoxStyle}\" \nText=\"{Binding LastName}\"\/>\n<TextBox x:Name=\"tbCompany\" Grid.Column=\"1\" Grid.Row=\"2\" \nMargin=\"10,5,10,5\" HorizontalAlignment=\"Left\" Height=\"30\" \nWidth=\"240\" Style=\"{StaticResource textBoxStyle}\" \nText=\"{Binding Company}\"\/>\n<\/pre>\n
    This XAML shows that the Text property of each TextBox is bound to a property of the data source. The data source is not listed anywhere in this XAML code. Therefore it is inferred that the Binding will use the DataContext<\/b> that is closest in the inheritance hierarchy to the Target. If the TextBox itself has its DataContext<\/b> property set, it will use the object from its own DataContext<\/b>. <\/p>\n
    Example 2.<\/b> DataContext<\/b> Binding<\/p>\n
    C# <\/b><\/p>\n
    private void DataContextBinding_Loaded(object sender, RoutedEventArgs e)  {\nperson = new Person { FirstName = \"Ella\", \nLastName = \"Johnson\", Company = \"Hoo Company\" };\nthis.DataContext = person;\n}\n<\/pre>\n
    VB Code<\/b><\/p>\n
    Private Sub DataContextBinding_Loaded(ByVal sender As Object, _  ByVal e As RoutedEventArgs)\nperson = New Person With {.FirstName = \"Ella\", _\n.LastName = \"Johnson\", .Company = \"Hoo Company\"}\nMe.DataContext = person\nEnd\nSub<\/pre>\n
    The code in Example 2 shows the event handler that will execute when the UserControl<\/b> is loaded. First an instance of the Person class is created and initialized. Then the DataContext<\/b> property (also a Dependency Property) of the UserControl<\/b> is set to the person instance. This gives each TextBox’s Binding a valid DataContext<\/b> to use as the data source. Figure 3 shows the result of the binding. The DataContext<\/b> is set for a container control (the UserControl<\/b> itself). <\/p>\n
    \"513-Leavethisalonethree.jpg\"<\/p>\n<\/div>\n
    Figure 3.<\/b> DataContext Binding<\/p>\n
    Summary<\/h2>\n
    Silverlight 2 offers a variety of data binding features that all stem from some basic concepts as discussed in this article. All instances of the FrameworkElement<\/b> class support data binding as a target while all properties of FrameworkElement<\/b>s that are dependency properties can be a target property of a data binding operation. The DataContext<\/b> is a very powerful way to bind a source object to one or more elements are multiple levels in XAML. These are the fundamental tools to data binding with Silverlight 2.<\/p>\n
    <\/div>\n","protected":false},"excerpt":{"rendered":"
    Silverlight 2 is far more versatile than Silverlight 1. It can handle data-sources with some subtlety. John Papa tackles the whole subject of data-binding with Silverlight. This article is a partial excerpt from John Papa’s upcoming book Data Access with Silverlight 2 by O’Reilly, due to be released in December 2008. …<\/p>\n","protected":false},"author":221825,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[143538],"tags":[4143,4229,4178,4838,4868,4179],"coauthors":[],"class_list":["post-384","post","type-post","status-publish","format-standard","hentry","category-dotnet-development","tag-net","tag-net-framework","tag-bi","tag-silverlight","tag-silverlight-how-to-example-data-binding","tag-source-control"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/384","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/users\/221825"}],"replies":[{"embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/comments?post=384"}],"version-history":[{"count":6,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/384\/revisions"}],"predecessor-version":[{"id":91142,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/384\/revisions\/91142"}],"wp:attachment":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/media?parent=384"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/categories?post=384"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/tags?post=384"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/coauthors?post=384"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}