Canvas and DockPanel

Analogy categoryAnalogies

Canvas and DockPanel sit at opposite ends of the WPF layout spectrum. Canvas is the only built-in panel that supports true absolute positioning: children are placed using the attached properties Canvas.Left, Canvas.Top, Canvas.Right, and Canvas.Bottom, and Canvas performs no automatic sizing or repositioning as its own size changes, which makes it ideal for diagramming tools, custom drawing surfaces, or game-like overlays where exact coordinates matter. DockPanel sits closer to the flexible end: children declare which edge of the remaining space they want to occupy via the DockPanel.Dock attached property (Top, Bottom, Left, or Right), and DockPanel consumes space from the outside in, shrinking the remaining area for each subsequently docked child, which makes it the natural choice for classic application shells with menus, toolbars, status bars, and a central content region.

🏏

Cricket analogy: Canvas is like plotting the exact pitch map coordinates of every ball a bowler delivers (precise X/Y data points), while DockPanel is like arranging fielders around the boundary edge first and leaving the remaining space for the rest of the field, matching each panel's positioning philosophy.

Canvas: Absolute Positioning

Canvas.Left and Canvas.Top position a child relative to the Canvas's top-left origin, while Canvas.Right and Canvas.Bottom position relative to the bottom-right; if both Canvas.Left and Canvas.Right are set on the same element, Canvas.Left wins and Canvas.Right is ignored. Because Canvas gives each child essentially infinite available space during Measure, HorizontalAlignment and VerticalAlignment have no effect on Canvas children, and setting Width/Height on a child is the only way to control its size — Canvas never stretches or shrinks children to fit. Canvas also introduces a ZIndex attached property (inherited from Panel but especially relevant here) that controls paint order among overlapping children, which is essential for diagramming scenarios where connector lines need to render behind the nodes they connect.

🏏

Cricket analogy: Wagon-wheel shot charts plot the exact origin (batsman's crease) and destination coordinates of every shot, just like Canvas.Left/Top positions a child relative to a fixed origin.

xml

<Canvas Width="400" Height="300" Background="White">
    <!-- Connector line drawn behind the nodes it connects -->
    <Line X1="60" Y1="50" X2="220" Y2="150" Stroke="Gray" StrokeThickness="2" Panel.ZIndex="0" />

    <Ellipse Canvas.Left="20" Canvas.Top="20" Width="80" Height="60"
             Fill="LightBlue" Panel.ZIndex="1" />

    <Ellipse Canvas.Left="200" Canvas.Top="120" Width="80" Height="60"
             Fill="LightGreen" Panel.ZIndex="1" />

    <!-- Positioned relative to the bottom-right corner instead -->
    <TextBlock Canvas.Right="10" Canvas.Bottom="10" Text="v1.0" Foreground="Gray" />
</Canvas>

DockPanel: Docking Children to Edges

DockPanel processes its children in the order they appear in XAML, consuming space from the edge specified by each child's DockPanel.Dock value and shrinking the remaining available rectangle for subsequent children. This means order matters: if you dock a child Top and then a second child Left, the left-docked child only occupies the space beneath the top-docked one, not the full original height. A common real-world layout docks a Menu to the top, a ToolBar beneath it (also Top), a status bar to the Bottom, and a navigation TreeView to the Left, leaving the remaining central rectangle — typically filled by the final, undocked child — as the primary content area for the actual application content.

🏏

Cricket analogy: Setting the field for a new over — first the boundary riders (outer edge), then infield catchers (remaining inner space) — mirrors how DockPanel consumes space from outside in as each child docks to an edge.

DockPanel.Dock is an attached property, so you set it on the child, not the parent — for example <Menu DockPanel.Dock="Top" /> — while the DockPanel itself only exposes the LastChildFill boolean.

LastChildFill and Layout Order

DockPanel's LastChildFill property, true by default, determines whether the final child (the one with no explicit dock direction, or simply the last one in markup order) automatically expands to fill whatever space remains after all the docked siblings have claimed their edges. If LastChildFill is set to false, the last child instead docks to whatever direction its own DockPanel.Dock specifies, and no child automatically fills the remaining central area — which is rarely what you want, since it typically leaves a visible unfilled gap. Because dock order is determined purely by XAML declaration order rather than any explicit z-index or priority property, reordering elements in markup directly changes the resulting layout, which is a frequent source of confusion when refactoring a DockPanel-based shell.

🏏

Cricket analogy: The last recognized batsman in the order is expected to anchor the innings and use up all the remaining overs, similar to how DockPanel's LastChildFill lets the final child claim all remaining space by default.

If LastChildFill is true (the default) but you also set an explicit DockPanel.Dock value on the last child, that Dock value is silently ignored — the last child always fills the remaining space regardless of its own Dock setting, which surprises developers who expect Dock to always take priority.

Canvas positions children with Canvas.Left/Top/Right/Bottom and provides no automatic resizing or reflow.
HorizontalAlignment and VerticalAlignment have no effect on Canvas children.
Panel.ZIndex controls paint order for overlapping Canvas children.
DockPanel children declare an edge via the DockPanel.Dock attached property (Top, Bottom, Left, Right).
DockPanel consumes space from the outside in, in XAML declaration order, shrinking what remains for later children.
LastChildFill (default true) makes the final child automatically fill remaining space, overriding any Dock value it has.
Use Canvas for pixel-precise diagrams and Use DockPanel for edge-anchored application shells.