There is a very good reason not to use ActualWidth for snapping (obviously ActualHeight respectively). When you set the Width element to ActualWidth another, you can break the layout chain .
In the best case, your element / control needs to be analyzed after the completion of the linking process of the parent (binding source). This means extra time. If it is at the same hierarchy level as the parent, the layout process requires two runs (at least) to calculate the final size.
For example, I had a control that had a size property overridden in a style that would set it to TemplatedParent (do not) :
<Rectangle DockPanel.Dock="Top" Width="{TemplateBinding ActualWidth}" Height="1" Fill="#000000"/>
If you resize the window contained in it, the control will prevent the container from being reduced in size and layout inhibited. Setting it to Width will solve the (do) problem:
<Rectangle DockPanel.Dock="Top" Width="{TemplateBinding Width}" Height="1" Fill="#000000"/>
If you need to use ActualWidth , something is wrong with your xaml. Itβs better to fix this, instead of messing up the final dimensions of the layout.
Pascal 04 Oct '13 at 11:32 2013-10-04 11:32
source share