Difference between {Binding PropertyName} and {Binding Path=PropertyName}

I've seen both styles used in the same project, and I wonder if there's any semantic difference between them,开发者_Go百科 or if any would be recommended over the other and why.

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:

• Binding(string path) invokes public PropertyPath(string, Object[])
• PropertyPathConverter invokes internal PropertyPath(string, ITypeDescriptorContext)

(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?)

They mean the same thing. Where they differ is in how the Binding object is instantiated and populated.

{Binding Path=Foo}

creates a Binding instance using its parameterless constructor, and then sets the instance's Path property.

{Binding Foo}

creates a Binding instance using its single-parameter constructor, and passes the value "Foo" to that constructor parameter. The single-parameter constructor just sets the Path property, which is why the two syntaxes are equivalent.

It's very much like the syntax for custom attributes, where you can also pass constructor parameters and/or set property values.

There is none.

When not specified, the Path property is assigned the value. In other words, Path is the default property of a binding.

It's like the "Content" property, which is the default property for many controls. For example

<Button>Hello</Button> Is the same as <Button><Button.Content><TextBlock Text="Hello"/></Button>

Hope that helps.

There is no semantic difference, the first property in the binding will be interpreted as the "Path" property if no property name is supplied.

It's a matter of coding style.

Update

Removed the sentence "It is the default property".

I realize that there is no formal support for "default properties", but the scenario is often referred to as the "default property", and is supported by convention.

Example, from the MSDN documentation for the Path property of the Binding markup extension:

The Binding markup extension uses Binding.Path as a conceptual "default property", where Path= does not need to appear in the expression.

I do not think I am wrong and completely misguided to use this terminology as is being suggested. I also understand how it is implemented.

Don't think there's any difference, expect perhaps the second is more explicit.