Binding d'une dependency property vers une autre

Bonjour,

si un control en contient un autre est-il possible de binder une propriété du premier vers une dependency property du deuxième ?

Voici une illustration :
un control "ControlTest" contient un autre control "InnerControlTest".
"InnerControlTest" affiche une valeur "InnerValue" en l'entourant d"une bordure bleue.
"ControlTest" quant à lui affiche une valeur "Value" en l'encapsulant dans un "InnerControlTest" et en entourant le tout d'une bordure verte.

L'objectif est que la valeur à afficher soit passée par l'utilisateur à "ControlTest" via la dependency property "Value", puis que "ControlTest" la transmette à "InnerControlTest" via la dependency property "InnerValue".

La valeur passe bien à "ControlTest" via "Value" comme le confirme le "Label" contenu dans "ControlTest".
En revanche la valeur n'est pas transmise à "InnerControlTest" comme le montre le "Label" contenu dans "InnerControlTest", qui contient la valeur par défaut d'un "int" : 0.

En pièce jointe se trouve un projet VS 2008 qui illustre le problème.


Merci.

Bonjour,

si tu mets ça dans le ControlTest.xaml, ça marche :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

<UserControl x:Class="TestCustomControl.ControlTest" xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" xmlns:local="clr-namespace:TestCustomControl" x:Name="TheControl"> <Border BorderBrush="Green" BorderThickness="2"> <Grid> <Grid.RowDefinitions> <RowDefinition Height="Auto"/> <RowDefinition Height="Auto"/> </Grid.RowDefinitions> <Grid.ColumnDefinitions> <ColumnDefinition Width="Auto" /> </Grid.ColumnDefinitions> <Label x:Name="CTLabel" Content="{Binding Value}" Grid.Row="0"/> <local:InnerControlTest x:Name="CTInnerCT" InnerValue="{Binding Value, ElementName=TheControl}" Grid.Row="1"/> </Grid> </Border> </UserControl>

---

J'ai nommé le UserControl, et changé la source dans le InnerControlTest. Il ne trouve pas la propriété Value sinon quand tu fais le Binding, parce qu'il se réfère à l'objet dans le DataContext, et tu as mis un this.DataContext = this; dans le InnerControlTest.

Tout simplement parfait, merci beaucoup.

En fait je pensais que dans le "contexte XAML" "ControlTest.xaml" le "DataContext" serait partout celui de "ControlTest".

Du coup ça casse un peu la cohérence puisque le binding "{Binding Value}" n'a pas le même sens pour le "Label" au dessus.
De plus c'est moins élégant syntaxiquement car obligeant à référencer explicitement le "ControlTest".

Quelle est la raison de ce choix ?

ben... je crois que ça casse la cohérence parce que dans ton contrôle, tu réaffectes le DataContext.
La notation différente vient juste de la façon dont ton UserControl est designé, c'est toi qui force ce 'choix' :)

Oui en effet c'est le problème.

Et donc une bonne pratique serait de toujours indiquer explicitement le "DataContext", par exemple via "ElementName" ?

En effet, dans le cas contraire où le "DataContext" est implicite, si un sous-control le remplace par un autre, comme c'était le cas ici, le binding ne fonctionne plus comme attendu.

Oula ! Loin de moi l'idée de dire que c'est une 'bonne pratique'. Faut demander aux MVP pour ce genre de trucs.

D'usage, je ne surcharge pas le DataContext dans mes UserControl. Mais j'ai pas trouvé de solution élégante.

Citation:

---

Oula ! Loin de moi l'idée de dire que c'est une 'bonne pratique'. Faut demander aux MVP pour ce genre de trucs.

---

Dans ce cas attendons l'avis de Thomas ;)

On parle de moi ? :D

Citation:

---

Envoyé par seriousme

Et donc une bonne pratique serait de toujours indiquer explicitement le "DataContext", par exemple via "ElementName" ?

---

Affecter le DataContext est une bonne pratique pour faire du binding. Après, que tu le fasses par ElementName, Source, etc.. peut importe ;)

Citation:

---

Affecter le DataContext est une bonne pratique pour faire du binding. Après, que tu le fasses par ElementName, Source, etc.. peut importe

---

Ok, merci.

Plus généralement en développement il faut éviter de reposer sur des règles implicites même si elles permettent d'alléger le code.