XAML Quick Reference

Analogy categoryAnalogies

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.

xaml

<!-- 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.

xaml

<!-- 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.