When is the "Path=" xaml syntax required when specifying a binding to a property? I see this "Path=" pretty much exclusively when there is a nested property binding (ex: Path=Person.FirstName).
Thanks!
asked May 23, 2011 at 3:06
Add a comment
|
2 Answers
Think of it like initializing a class in C#. If the "Binding" class has a constructor that takes a path, you could do this:
new Binding("Person.FirstName");
... or this:
new Binding { Path = "Person.FirstName" };
The two are the same, for all intents and purposes. XAML is doing the same thing. If you omit the "Path=" you're passing a path into the constructor for Binding, but if you include it you're setting the value after the fact.
I often leave the "Path=" out, especially if I'm declaring a binding with no other properties set, like {Binding FirstName}.
answered May 23, 2011 at 3:12
4 Comments
AlvinfromDiaspar
Cool. I also leave the Path part out for simple properties. So does this mean I could also leave it out when binding something like this: {Binding Person.FirstName} ???
Matt Hamilton
Yep, you definitely can. You can even include other attributes, like {Binding Person.FirstName,Converter={StaticResource NameConverter}}.
AlvinfromDiaspar
Ok Matt. I think i MIGHT have found my problem. But let me ask you this before I jump up and down. Will nested property binding work if, say FirstName, is a property that exists in a base class (not directly owned by the Person class)? If not, then this would answer my problem.
Matt Hamilton
Yep, that's fine. It would have to be a public property, but it doesn't matter where it's defined in the class hierarchy.
You use this when the object you are binding to is not the same object that is set to the control's DataContext property
answered May 23, 2011 at 3:12
