The Binding Markup Extension
A Silverlight Binding connects a target dependency property (on a UI element) to a source, most commonly a property on a CLR object reachable through DataContext, using syntax like Text="{Binding Path=Name}". DataContext is inherited down the visual tree, so setting it once on a parent (typically in code-behind: this.DataContext = viewModel) lets every descendant element bind against the same object without repeating the source per control. Binding.Mode controls direction: OneTime reads the value once, OneWay pushes source-to-target updates only, and TwoWay synchronizes both directions, which is essential for editable input controls like TextBox.
Cricket analogy: DataContext being inherited down the visual tree is like a captain's tactical plan for the day being communicated once at the team huddle and then every fielder on the ground automatically knows the target field placement without the captain repeating it to each player individually.
INotifyPropertyChanged and Live Updates
For OneWay or TwoWay bindings to reflect changes after the initial render, the source object must implement INotifyPropertyChanged, raising a PropertyChanged event with the changed property's name whenever a bound property is set; Silverlight's binding engine subscribes to this event and refreshes the target automatically. ObservableCollection<T> plays the analogous role for collections bound to an ItemsControl: adding or removing items raises CollectionChanged, which the ItemsControl listens for to insert or remove the corresponding generated container without a full rebind, whereas a plain List<T> assigned to ItemsSource will not reflect subsequent Add/Remove calls in the UI at all.
Cricket analogy: INotifyPropertyChanged is like a scoreboard operator who immediately updates the display the instant a run is scored, rather than the crowd having to wait until the innings ends to see the new total, while a plain List<T> without notification is like a scoreboard that's frozen until manually refreshed at the next break.
Converters and Validation
An IValueConverter implements Convert (source-to-target) and ConvertBack (target-to-source) to transform data during binding, such as turning a boolean IsActive property into a Visibility value for a status indicator, or formatting a DateTime into a localized string; converters are referenced in XAML via Converter={StaticResource someConverter} and can accept a ConverterParameter for lightweight configuration. For input validation, implementing IDataErrorInfo or throwing an exception in a property setter (combined with ValidatesOnExceptions=True and NotifyOnValidationError=True on the Binding) lets Silverlight surface a red validation border and error tooltip automatically on the offending control.
Cricket analogy: A converter turning a boolean IsActive into Visibility is like a broadcast graphics system translating a raw "is the batsman out" flag into a visual DRS animation, transforming underlying data into a presentable form, while IDataErrorInfo flagging an invalid run total is like the third umpire flashing a red light when the recorded score doesn't add up.
public class Customer : INotifyPropertyChanged
{
private string _name;
public string Name
{
get { return _name; }
set
{
if (_name != value)
{
_name = value;
OnPropertyChanged("Name");
}
}
}
public event PropertyChangedEventHandler PropertyChanged;
protected void OnPropertyChanged(string propertyName)
{
PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(propertyName));
}
}
public ObservableCollection<Customer> Customers { get; } = new ObservableCollection<Customer>();Binding a TextBlock's Visibility to a boolean value requires a converter because Visibility is an enum (Visible/Collapsed), not a bool — a common BooleanToVisibilityConverter handles this translation and is reused across most Silverlight projects.
Assigning a plain List<T> (instead of ObservableCollection<T>) to an ItemsControl's ItemsSource means later Add or Remove calls on that list will not update the UI at all, since List<T> raises no CollectionChanged notification — the ItemsControl only reflects the collection's state at the moment of binding.
- Binding connects a target dependency property to a source property, typically resolved through DataContext.
- DataContext is inherited down the visual tree, so setting it once lets many descendant bindings share the same source.
- Binding.Mode (OneTime, OneWay, TwoWay) controls the direction and frequency of updates.
- INotifyPropertyChanged with a PropertyChanged event is required for OneWay/TwoWay bindings to reflect later changes.
- ObservableCollection<T> raises CollectionChanged so ItemsControl reflects Add/Remove without a full rebind; plain List<T> does not.
- IValueConverter's Convert/ConvertBack transform data between source and target representations, optionally using ConverterParameter.
- ValidatesOnExceptions and IDataErrorInfo let Silverlight surface automatic validation error UI on invalid input.
Practice what you learned
1. What must a source object implement for a OneWay binding to reflect property changes made after the initial render?
2. Which collection type raises CollectionChanged so a bound ItemsControl reflects Add/Remove operations automatically?
3. What XAML property is most commonly used to set the source object once for an entire subtree of bindings?
4. What two methods does an IValueConverter implement?
5. What combination of Binding properties enables Silverlight to automatically display a red validation border when a property setter throws?
Was this page helpful?
You May Also Like
Silverlight Controls
An overview of Silverlight's built-in control library, the ContentControl/ItemsControl hierarchy, and event handling for common interactive controls.
Silverlight Styles and Templates
How Style setters standardize appearance across controls, and how ControlTemplate replaces a control's entire visual structure while VisualStateManager drives its states.
Silverlight Resources
How ResourceDictionary scoping, StaticResource lookup, merged dictionaries, and embedded assets let Silverlight applications share and organize reusable objects.
Related Reading
Related Study Notes in Microsoft Technologies
Browse all study notesWindows 10 / UWP Development Study Notes
.NET · 30 topics
Microsoft TechnologiesWindows Batch Scripting Study Notes
Batch · 30 topics
Microsoft TechnologiesMFC (Microsoft Foundation Classes) Study Notes
C++ · 30 topics
Microsoft TechnologiesXAML Study Notes
.NET · 30 topics
Microsoft TechnologiesWPF (Windows Presentation Foundation) Study Notes
.NET · 30 topics
Microsoft TechnologiesMVVM Design Pattern Study Notes
.NET · 30 topics