There is a significant difference here which you will run into as soon as you have a complex property path with typed parameters.
Conceptually they are equivalent as they both end up setting the Binding.Path
, one via the parameterized Binding
constructor, the other directly via the property. What happens internally is very different though as the Binding.Path
is not just a string which in both cases would be passed on to the property, it is a PropertyPath
.
When XAML is parsed, type converters are used to turn strings into the types expected by properties. So when you use Path=
a PropertyPathConverter
will be instantiated to parse the string and return a PropertyPath
. Now here is the difference:
(In the case of the Binding
constructor the Object[]
will be empty)
How does this matter?
If you for example have multiple indexers in a class e.g. one that expects a string
and one that expects an int
and you try to cast the value to target the latter, the cast will not work:
{Binding [(sys:Int32)0]}
The PropertyPath
is lacking the ITypeDescriptorContext
because the public constructor is invoked so the type System.Int32
cannot be resolved from the string sys:Int32
.
If you use Path=
however the type converter will be used instead and the type will be resolved using the context, so this will work:
{Binding Path=[(sys:Int32)0]}
(Aren't implementation details fun?)
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…