What is the difference between Width and ActualWidth in WPF?

Question

I am currently working with Panels in WPF, and I noticed that as regards the Width and Height properties, there are also two other properties called ActualWidth and ActualHeight.

ActualWidth

Gets the rendered width of this element. This is a dependency property. (Inherited from FrameworkElement.)

Width

Gets or sets the width of the element. This is a dependency property. (Inherited from FrameworkElement.)

Reference: MSDN

Can anyone point out the differences between the two and when to use either one ?

score 78 · Accepted Answer · edited Feb 02 '20 at 02:33

78

Width/Height is the requested or layout size. If you set to Auto, then the value is double.NaN when you access the property in code behind.

ActualWidth/ActualHeight and RenderSize.Width/RenderSize.Height both return the element's rendered size, as RenderSize is of type Size. If you want/need the actual size of the item, then use any of these attributes.

edited Feb 02 '20 at 02:33

luismiguelss

155
2
16

answered Mar 03 '09 at 19:48

Muad'Dib

28,542
5
55
68

8

It is actually the layout size not the rendered size. – chuckj Mar 04 '09 at 09:40
2

@chuckj, what attribute would one use to get the rendered size? – dumbledad Jul 05 '15 at 15:39
2

@dumbledad `.RenderSize.Width` – Mafii Jul 12 '16 at 12:39

score 11 · Answer 2 · edited Jun 13 '13 at 15:51

I find ActualWidth most useful when I want to bind the width or height of one element to another.

In this simple example I have two buttons arranged side by side and a comment underneath that is constrained to the width of the StackPanel containing the two buttons.

<StackPanel>

    <StackPanel Margin="0,12,0,0" Orientation="Horizontal" Name="buttonPanel" HorizontalAlignment="Left" >
         <Button Content="Yes - Arm the missile" FontWeight="Bold" HorizontalAlignment="Left"/>
         <Button Content="No - Save the world" HorizontalAlignment="Left" Margin="7,0,0,0"/>
    </StackPanel>

    <TextBlock Text="Please choose whether you want to arm the missile and kill everybody, or save the world by deactivating the missile." 
               Width="{Binding Path=ActualWidth,ElementName=buttonPanel}" Margin="0,5,0,0" HorizontalAlignment="Left" TextWrapping="Wrap"/>

</StackPanel>

TWood · Answer 3 · 2015-02-09T21:46:41.137

7

ActualWidth accounts for padding in the value so anytime you need to know that number you can call Actualwidth instead of width and avoid the calculation.

edit: removed Margin b/c it isn't part of ActualWidth.

edited Feb 09 '15 at 21:46

answered Oct 21 '10 at 16:20

TWood

2,563
8
36
58

score 3 · Answer 4 · edited Sep 01 '15 at 00:39

3

There is a very good reason not to use the ActualWidth to bind to (obviously ActualHeight accordingly). When you set the Width of an element, to the ActualWidth of another one you may break the layout chain.

In the best case your element/control needs to be parsed after the layout process of the parent (the binding source) finished. That means additional time. If it is at the same hierarchy level as the parent the layout process needs two runs (at least) to calculate a definitive size.

For example I had a control which had it's size property overridden in a style that would set it to the TemplatedParent (don't do):

<Rectangle DockPanel.Dock="Top" Width="{TemplateBinding ActualWidth}" 
           Height="1" Fill="#000000"/>

When resizing the containing window, the control would prevent the container from becoming smaller and brake the layout. Setting it to the Width will resolve the problem (do):

<Rectangle DockPanel.Dock="Top" Width="{TemplateBinding Width}" 
           Height="1" Fill="#000000"/>

If you have to use the ActualWidth in general something is wrong with your xaml. Better fix that instead of messing up with the final sizes of the layout run.

edited Sep 01 '15 at 00:39

Noctis

11,507
3
43
82

answered Oct 04 '13 at 11:32

Pascal

2,197
3
24
34

1

Your code snippets ("dont do" and "do") are exactly the same?!?! – PIntag Aug 19 '14 at 18:15
2

@tuner I disagree with this: "If you have to use the ActualWidth in general something is wrong with your xaml". There is nothing wrong with binding to `ActualWidth` (or `ActualHeight`), indeed in certain cases this may be the easiest way of solving a particular layout problem. Just because binding to these properties causes problems on (rare) occasions is no reason to avoid them completely. – Steven Rands Feb 06 '15 at 11:13
2

@StevenRands : The problem with your rare occasions is that it is very hard to find the source of a problem. If you bind properties that determine the size of an component to `ActualWidth` or similar, there need to be at least two layout passes to determine the size of the component. My personal experience is, that this works at first. Then, after introducing other non-standard behavior (which it is), stuff breaks and you have real problems nailing it down. – Pascal Feb 06 '15 at 12:23
1

@tuner I've used this technique a fair number of times and never had any of the problems you mention. Maybe I've just been lucky. There are places where I wouldn't use it but I think a blanket statement that basically says "use this and you're doing it wrong" isn't helpful. I take your point about the multiple layout passes but I think this kind of binding is often the easiest way of saying in XAML: I want *this* element to be the same width (or height) as *that* element. Just an opinion anyway. – Steven Rands Feb 06 '15 at 12:33
@Pascal: I have the behavior of requiring to issue a menu command to redraw my screen to get the ActualHeight to not be 0. So, in the code I hardwire the Height until the control makes it available. Why is this? And how to avoid? I do not see where set or remove Auto on Label control. – J W Dec 14 '20 at 17:20
@JW: You might look into your control if it actually requests a size at all. If other controls are set to grow and your particular control is not requesting a minimum size, it will be shrunk to zero until that is changed. – Pascal Jan 02 '21 at 19:43

score 3 · Answer 5 · answered Mar 03 '09 at 19:46

ActualWidth is set by the rendering system, and may be different depending on the widths of other elements and overall size constraints. As a result, it can not be changed. Width is a property that can be changed, and should be used to increase or decrease the width of the element.

From MSDN:

This property is a calculated value based on other width inputs, and the layout system. The value is set by the layout system itself, based on an actual rendering pass, and may therefore lag slightly behind the set value of properties such as Width that are the basis of the input change.

score 0 · Answer 6 · answered Mar 03 '09 at 19:47

It's exactly that, the render width != layout width. One is intended to be used for layout the other one is intended for render. It like with WinForms, there was a Size and a ClientSize property, the differ slightly and you should use the Atual/Client size of rendering and the Width/Height for layout.

score 0 · Answer 7 · edited Jun 13 '13 at 15:50

You can set the Width property, but not the ActualWidth property.

The Width property is used to determine how the panel is rendered, then the ActualWidth is set to the actual width that was used. This may not be the same value as Width, depending on the size of it's child elements and constrictions from it's parent element.

The ActualWidth is not set immediately when setting the Width property, but will be updated (one or more times) during rendering.

What is the difference between Width and ActualWidth in WPF?

7 Answers7

Linked

Related