Différence entre {Binding PropertyName} et {Binding Path = PropertyName}

Question

J'ai vu les deux styles utilisés dans le même projet, et je me demande s'il y a une différence sémantique entre eux, ou si l'un serait recommandé par rapport à l'autre et pourquoi .

Answer 1

Il n'y en a pas.

Lorsqu'elle n'est pas spécifiée, la propriété Path est associée à la valeur. En d'autres termes, Path est la propriété par défaut d'une liaison.

C'est comme la propriété "Content", qui est la propriété par défaut pour de nombreux contrôles. Par exemple

<Button>Hello</Button> est le même que <Button><Button.Content><TextBlock Text="Hello"/></Button>

espoir qui aide.

Answer 2

Ne pensez pas qu'il y a une différence, attendez peut-être que la seconde soit plus explicite.

Answer 3

Il n'y a pas de différence sémantique, la première propriété de la liaison sera interprétée comme la propriété "Path" si aucun nom de propriété n'est fourni.

C'est une question de style de codage.

Mise à jour

Suppression de la phrase: "Il est la propriété par défaut".

Je réalise qu'il n'y a pas de support formel pour les "propriétés par défaut", mais le scénario est souvent appelé la "propriété par défaut", et est supporté par la convention.

Exemple, à partir du MSDN documentation pour la propriété Chemin de l'extension de balisage Reliure:

L'extension de balisage liaison utilise Binding.Path comme une « propriété par défaut » conceptuel, où Path = n'a pas besoin de apparaître dans l'expression.

Je ne pense pas que je me trompe et complètement erroné d'utiliser cette terminologie comme cela est suggéré. Je comprends également comment il est mis en œuvre.

Answer 4

Ils veulent dire la même chose. Où ils diffèrent est dans la façon dont l'objet Binding est instancié et peuplé.

{Binding Path=Foo} 

crée une instance de liaison à l'aide de son constructeur sans paramètre, puis définit la propriété Path de l'instance.

{Binding Foo} 

crée une instance de liaison en utilisant son constructeur unique paramètre, et passe la valeur « Foo » à ce paramètre constructeur. Le constructeur à un seul paramètre définit simplement la propriété Path, ce qui explique pourquoi les deux syntaxes sont équivalentes.

Cela ressemble beaucoup à la syntaxe des attributs personnalisés, où vous pouvez également passer des paramètres de constructeur et/ou définir des valeurs de propriété.

Answer 5

est une différence significative ici que vous rencontrerez dès que vous avez un chemin de propriété complexe avec des paramètres typés.

D'un point de vue conceptuel, ils sont équivalents puisqu'ils finissent tous deux par définir le Binding.Path, l'un via le parameterized Binding constructor, l'autre directement via la propriété. Ce qui se passe est très différent en interne mais que le Binding.Path est non seulement une chaîne qui dans les deux cas seraient transmis à la propriété, il est PropertyPath.

Lorsque XAML est analysé type converters sont utilisés pour transformer les chaînes dans les types attendus par les propriétés. Ainsi, lorsque vous utilisez un Path=PropertyPathConverter sera instancié pour analyser la chaîne et retourner un PropertyPath. Maintenant, voici la différence:

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

(Dans le cas du constructeur Binding la Object[] sera vide)

Comment est-ce si matière?

Si par exemple vous avez par exemple multiple indexers in a class qui attend un string et qui attend un int et vous essayez de jeter la valeur pour cibler ce dernier le casting ne fonctionnera pas:

{Binding [(sys:Int32)0]} 

Le PropertyPath fait défaut le ITypeDescriptorContext parce que le constructeur public est invoqué le type System.Int32 ne peut pas être résolu à partir de la chaîne sys:Int32.

Si vous utilisez Path= mais le convertisseur de type sera utilisé à la place et le type sera résolu en utilisant le contexte, donc cela va fonctionner:

{Binding Path=[(sys:Int32)0]} 

(Ne sont pas les détails de mise en œuvre fun?)