A 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:
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.
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.
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.
A few more places to go learn about Attached Properties: