Markup Extensions Cheat Sheet
The four markup extensions used constantly in real XAML are {Binding Path, ...}, {StaticResource key}, {DynamicResource key}, and {x:Static member}: Binding connects a property to a data source with optional Mode, Converter, and ElementName/RelativeSource qualifiers; StaticResource/DynamicResource pull values from a ResourceDictionary (once vs live); and x:Static reaches a static CLR field, property, or enum value at compile time, useful for referencing enum members or constants without a converter. Knowing these four cold, plus their curly-brace syntax for nested property setters like Mode=OneWay or Converter={StaticResource MyConverter}, covers the overwhelming majority of everyday XAML markup.
Cricket analogy: It's like knowing the four most common dismissal types (bowled, caught, LBW, run out) cold — together they account for the overwhelming majority of wickets, just as these four extensions cover the overwhelming majority of markup you'll write.
<!-- The four workhorse markup extensions -->
<TextBlock Text="{Binding Path=CustomerName, Mode=OneWay,
Converter={StaticResource UpperCaseConverter}}" />
<Border Background="{StaticResource PrimaryBrush}" />
<Border Background="{DynamicResource ThemeBrush}" />
<TextBlock Text="{x:Static local:Constants.AppVersion}" />
<ComboBox SelectedItem="{Binding Status}"
ItemsSource="{x:Static local:OrderStatusValues.All}" />Layout Panels at a Glance
Grid arranges children in rows/columns with RowDefinitions/ColumnDefinitions using Auto, a fixed pixel value, or star (*) proportional sizing; StackPanel lays children out in a single Orientation with no wrapping; WrapPanel flows children left-to-right and wraps to a new line/column when space runs out; and Canvas positions children with absolute Left/Top/Right/Bottom coordinates and no automatic reflow at all. Choosing the wrong panel is one of the fastest ways to fight the layout system — Canvas for anything that needs to reflow with window resizing, or StackPanel for a form that needs proportional column widths, both produce layouts that look right at one size and break at another.
Cricket analogy: It's like choosing the wrong field placement for the conditions — a defensive ring set for a spinner on a turning pitch will leak boundaries if the same fielders stay put once a quick starts bowling on a flat deck; the panel (field setting) has to match the situation.
<!-- Grid: precise proportional layout -->
<Grid>
<Grid.ColumnDefinitions>
<ColumnDefinition Width="Auto" />
<ColumnDefinition Width="*" />
<ColumnDefinition Width="2*" />
</Grid.ColumnDefinitions>
</Grid>
<!-- StackPanel: single-direction, no wrapping -->
<StackPanel Orientation="Vertical" Spacing="8">
<TextBlock Text="Label" />
<TextBox />
</StackPanel>
<!-- WrapPanel: flows and wraps -->
<WrapPanel Orientation="Horizontal">
<Button Content="Tag1" />
<Button Content="Tag2" />
</WrapPanel>
<!-- Canvas: absolute positioning, no reflow -->
<Canvas>
<Ellipse Canvas.Left="20" Canvas.Top="40" Width="50" Height="50" />
</Canvas>Binding Modes and Common Attached Properties
Binding Mode has four values worth memorizing: OneWay (source to target only), TwoWay (source and target, needed for input controls like TextBox), OneTime (reads once, never updates — cheapest for static data), and OneWayToSource (target to source only, rare, useful for capturing UI state like a ScrollViewer's offset into a ViewModel). Attached properties like Grid.Row, Grid.Column, Canvas.Left, DockPanel.Dock, and Panel.ZIndex are set on a child element but actually apply meaning defined by the parent panel — mixing up which panel a given attached property belongs to is a common source of 'why isn't this doing anything' confusion, since setting Grid.Row on a child of a StackPanel is silently ignored.
Cricket analogy: It's like knowing when to bat defensively and just survive (OneTime — read once, no more engagement) versus actively rotating strike every ball (TwoWay) versus purely accumulating without ever adjusting your approach to the bowler (OneWay) — each mode fits a different match situation.
Quick recall trick: TwoWay is required for any control the user directly edits (TextBox.Text, CheckBox.IsChecked, Slider.Value); everything else defaults to each control's own sensible default Mode, which is usually OneWay for read-only display properties.
Attached properties are scoped to their defining panel: Grid.Row/Grid.Column only have effect when the element's direct parent is a Grid, Canvas.Left/Canvas.Top only apply inside a Canvas, and DockPanel.Dock only applies inside a DockPanel. Setting them on a child of the wrong panel type compiles fine but is silently ignored at layout time.
- The four workhorse markup extensions are {Binding}, {StaticResource}, {DynamicResource}, and {x:Static} — together they cover the vast majority of everyday XAML markup.
- Grid uses Auto/fixed/star sizing for precise proportional layout; StackPanel is single-direction with no wrapping; WrapPanel flows and wraps; Canvas is absolute positioning with no reflow.
- Binding Mode has four values: OneWay, TwoWay, OneTime, and OneWayToSource, each suited to a different data-flow scenario.
- TwoWay binding is required for any control the user directly edits, such as TextBox.Text or CheckBox.IsChecked.
- Attached properties like Grid.Row, Canvas.Left, and DockPanel.Dock only take effect when the element's direct parent is the matching panel type.
- Setting an attached property on a child of the wrong panel type compiles without error but is silently ignored during layout.
- OneTime binding is the cheapest mode for genuinely static data since it reads once and never re-evaluates.
Practice what you learned
1. Which markup extension reads a static CLR field, property, or enum member at compile time?
2. Which layout panel positions children using absolute Left/Top coordinates with no automatic reflow?
3. Which Binding Mode is required for a TextBox whose text the user can edit and have flow back to the ViewModel?
4. What happens if you set Grid.Row on an element whose direct parent is a StackPanel?
Was this page helpful?
You May Also Like
Debugging XAML Bindings
Practical techniques for diagnosing and fixing broken data bindings in XAML applications, from reading Output window trace errors to using Snoop and Live Visual Tree.
Common XAML Pitfalls
A tour of the most frequent mistakes XAML developers make with resource lookup, StaticResource vs DynamicResource, and layout sizing, plus how to fix each one.
XAML Performance
How UI virtualization, profiling, and per-item template design determine real-world XAML app responsiveness, with concrete techniques to fix common bottlenecks.
XAML Interview Questions
The core conceptual questions XAML interviews actually ask — DependencyProperty internals, MVVM binding gotchas, and Style vs ControlTemplate — with the reasoning behind each answer.
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 TechnologiesSilverlight Study Notes
.NET · 30 topics
Microsoft TechnologiesWPF (Windows Presentation Foundation) Study Notes
.NET · 30 topics
Microsoft TechnologiesMVVM Design Pattern Study Notes
.NET · 30 topics