32

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

Diego Mijelshon
  • 52,548
  • 16
  • 116
  • 154

5 Answers5

53

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

H.B.
  • 166,899
  • 29
  • 327
  • 400
  • 1
    @DiegoMijelshon: You're welcome, i would suggest you accept Joe White's answer though, the accepted one is two vague, as outlined in the comment on it. For most practical purposes White's answer is the one i think is most correct. (Wouldn't mind if you accept mine either of course) – H.B. Feb 22 '12 at 00:37
  • I accepted it because nobody came with a different one for several hours :-) It wouldn't be fair to change the accepted answer without actually testing others - keep in mind this was 15 months ago. – Diego Mijelshon Feb 22 '12 at 02:03
  • 3
    @DiegoMijelshon: Well, there is no rule that says you need to accept an answer that fast, i for one often left my questions without accepted answer for days unless it was obvious. This however is a knowledge based question and the accepted answer is at the very least misleading and does not even mention that one way uses a constructor. It's your question, you are free to accept whatever you want, there still is the "community accepted" answer identified by highest score after all. – H.B. Feb 22 '12 at 02:27
  • One more difference I've discovered is that one can use `{Binding {StaticResource PathResource}}` but not `{Binding Path={StaticResource PathResource}}`, if `PathResource` is a `string`. And only `{Binding Path={StaticResource PathResource}}` if `PathResource` is a `PropertyPath`. – Vlad Aug 07 '16 at 15:19
  • @Vlad: That makes sense, the constructor takes a string, the property itself has type `PropertyPath`. If you use `StaticResource` there is no implicit type conversion. – H.B. Aug 08 '16 at 13:27
  • @H.B.: Yes, I know the reason, the interesting part is that usually there is a conversion which kind of hides the difference. If I am not mistaken, the conversion is applied to markup extension's constructor arguments, but not to the properties (http://stackoverflow.com/a/29381103/276994). – Vlad Aug 08 '16 at 13:31
  • @Vlad: It has to happen for the properties as well, you pretty much never construct a `PropertyPath` in XAML. – H.B. Aug 08 '16 at 13:33
  • @Vlad: I commented on the linked answer to explain the confusion. – H.B. Aug 08 '16 at 13:40
  • @H.B.: I see. I've just checked this myself (and of course the conversion worked with properties as well). Thanks for the clarification! – Vlad Aug 08 '16 at 13:47
24

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.

Joe White
  • 94,807
  • 60
  • 220
  • 330
  • 5
    It might be of interest to you that there are corner cases where they are not equivalent, see my answer for details. – H.B. Feb 21 '12 at 18:33
18

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.

David Brunelle
  • 6,528
  • 11
  • 64
  • 104
  • 7
    While it's superficially like content properties, the mechanism is totally different. Content properties work because of the ContentPropertyAttribute. (In the case of Button, that comes from the ContentControl base class.) That attribute tells Xaml that content is equivalent to the Content property. But with Binding, it works simply because Binding offers a 1-argument constructor that happens to do the same thing as the Path property. Totally different mechanism - see Joe White's answer. – Ian Griffiths Nov 30 '10 at 10:30
  • There must be something different. I came across issue with omit the Path then the behavior was changed. In my case, one project I used {binding propertyname} then the property update two way and working fine. However, I put the exact same xaml to another project with using the same view model binary but it seems that the binding working in one way. To fix this, I have to explicit define {binding path=propertyname, mode=twoway} and then it's working fine. – Supawat Pusavanno Mar 11 '15 at 11:02
  • I believe H.B. mentionned something about that in the answer. In the end, if you are more explicit, you get less surprises, but I find those 'shortcut' usefull. – David Brunelle Mar 11 '15 at 13:01
  • *"{binding path=propertyname, mode=twoway}"* - but did you try `{binding propertyname, mode=twoway}`? That would be how to set mode, while using the shorthand notation. – ToolmakerSteve Feb 28 '23 at 00:38
5

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.

Tim Lloyd
  • 37,954
  • 10
  • 100
  • 130
  • It's actually a constructor parameter. There's no such thing as a "default property" for markup extensions. – Joe White Nov 29 '10 at 21:51
  • @Joe Sure, it has default behaviour\meaning. It is a convention. – Tim Lloyd Nov 29 '10 at 22:20
  • Yes, but it's unhelpful to use the term "the default property" because there isn't any such thing. And the problem with an explanation that depends on a non-existent concept is that people are liable to try and apply that concept in other situations, which is not going to be helpful. (What's the 'default property' of ArrayExtension? That has two 1-arg constructors!) You could improve you answer substantially by editing it to remove that "It is the default property" sentence. – Ian Griffiths Nov 30 '10 at 10:37
  • Down voter (@Ian?). This scenario is very often referred to as the "default" property, including in MSDN documentation. NB I understand how it is implemented, the question was about semantics. – Tim Lloyd Nov 30 '10 at 10:39
  • Yes, I downvoted it for the reasons explained in the previous comment. (I've spent so much time helping people who've hit problems as a result of an incorrect internalized model of how things work that I think it's important to know when a model is really only a rough conceptual aid, rather than an explanation of how things work.) The MSDN docs did at least use "scare quotes" to make it clear that "default property" isn't a real thing. I've reversed my previous vote based on your update - thanks for the clarification. – Ian Griffiths Nov 30 '10 at 10:58
3

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

cristobalito
  • 4,192
  • 1
  • 29
  • 41