Rob Relyea


WPF Attached Properties

post on the Avalon Forum from Jaffi raised a question

WPF is not straight forward. Simple actions, like setting rectangles X position, requires using myRectange.SetValue(Canvas.LeftProperty, Value). I'm sure there is a performance penalty for such use (Which caused the performance problem).

Why can't it be simple as myRectangle.X = value.


That is why Every simple action I'm looking for require hours of searching


What were those WPF folks thinking?

We tried to balance extensibility and usability in WPF.  There are new concepts, we hope to make them easy to learn and make sense once you learn them.


Reason for Attached properties:

When dealing with out Layout system, we want to provide the ability for anybody to build new Panels.  Inside of those panels you should be able to put normal elements:



   <Button />

   <Button />



Often, the new panel will need to define a property that the user can place on the children of that panel to control how the panel arranges the children.



   <Button RotationsPerMinute="60" />

   <Button RotationsPerMinute="3" />


Unfortunately that won't work.  RotationsPerMinute is a newly invented property.  The Button class shipped before the RobPanel was ever built and the Button class designers forgot to include this important property!


So WPF has the concept of attached properties.  One class defines the property.  You attach it to instances of other objects.


   <Button Name="b1" my:RobPanel.RotationsPerMinute="60" />

   <Button Name="b2" my:RobPanel.RotationsPerMinute="3" />



The challenge is how can you expose this to developers now.

RobPanel.SetRotatationsPerMinute(b1, 30);


int currentRotationsPerMinute = RobPanel.GetRotationsPerMinute(b1);


So if you buy the need for this extensibility, then you need to ask why is Canvas.Top and Canvas.Left modeled as an attached property, but Height and Width are modeled as normal properties.

Top and Left are modeled as attached properties because they are only respected inside of a Canvas.  If I set Top or Left on a Button inside a StackPanel or DockPanel, it would have no effect.


Object Model should Function

We feel it is very bad form to have a number of methods or propeties on an object that actually don't do anything.

My work with DHTML + CSS left me frustrated.  I could set any of the ~200 (?) style properties on any element.  Unfortunately I could never tell if it was supposed to work or not.


Performance Penalty

Jaffi asked if the static method syntax was a performance problem.

There is cost, but marginal cost between a Top property defined on an element and an attached property Top defined on the panel.


In WPF, regardless of attached vs. normal, most properties need some special capabilities: databinding, setting via style, animation, etc.

The property system that enables this is something that is perf critical.  That is probably why we have reimplemented it 3-4 times during our development.


Other Links

A few more places to go learn about Attached Properties:

Posted on Feb 09 2006, 01:21 PM by rrelyea
Filed under:


  • MichaelLatta said:
    The current property system for WPF is a reasonable solution to the set of problems it is addressing, and implemented in a reasonable way for the existing CLR. I would like to see however in the next version more direct support. For example in C# 3.0 would it be possible to have dynamic properties? Some way for the property system of WPF to be tied to the language? Just as C# 3.0 allows static methods to be declared that appear to be instance methods, could there be a way to declare static properties that appear to be instance properties?
    February 9, 2006 11:20 AM
  • rrelyea said:
    Yes, we would love something like this. It is the ideal model for the user.

    We've worked with language teams in the past asking for better language support for our property system including using attached properties.

    I'll ping them again now to make sure they keep it in mind and get an update.
    Thanks, Rob
    February 9, 2006 1:06 PM
  • xasd said:
    That's all nice and offs,everywhere trade offs.
    But I don't get it,why you not like DHTML+CSS?It's most extensible/flexible property system ever existent,particularly in IE with their attached behaviors+dynamic expressions in css/properties-simple and powerful,when used with thinking-nothing can beat that,even XAML(in present state)-AOP in action;-)I build xml binding system a'la XAML only ~5Kb in size for IE,dynamically updateable and replaceable in runtime!!!Because it's web oriented.You build client side oriented,not very dynamic by nature system and say-that's a right thing?Well...Avalon is dynamic but to which extent and for what price(for developer)?
    Excuse me,but Avalon(XAML) is only in begining of it's way to compare with IE/iis(7?+Atlas?) abilities IMHO.
    Managed browser is my dream;-)

    February 11, 2006 7:46 AM
  • rrelyea said:
    I was a DHTML program manager from IE5 to IE6 working on many of the features you mentioned. As such, I appreciate many of the strengths of DHTML, but I am also very familiar with many of the shortcomings.

    The property system of DHTML has been one of the inspirations for several of the things we have done in WPF: databinding, styles, inheritance, etc...

    We'd love to hear concrete feedback about what capabilities you find lacking in WPF/XAML's property system (or other things.)

    Thx, Rob

    February 12, 2006 6:10 AM

  • Rob Relyea, in his&amp;nbsp;great blog on all things Avalon/WPF, recently posted a discussion of Attached...
    February 14, 2006 9:08 AM
  • jfo's coding said:
    I thought I'd put up a few good reads:

    Mapping PIs are going away in the next CTP. Rob promises to...
    February 14, 2006 11:14 PM
  • I sat down to look at WPF/E this evening. WPF/E is Microsoft's cross-platform XAML engine that runs...

    December 27, 2006 11:21 PM
  • I sat down to look at WPF/E this evening. WPF/E is Microsoft's cross-platform XAML engine that runs in

    December 27, 2006 11:26 PM
  • December 3, 2007 4:39 AM
  • That is certainly the way to go

    May 1, 2010 1:16 AM