Personnalisation de l'arbre d'héritage DependencyObject

Question

Je ne parviens pas à trouver suffisamment d'informations sur la propriété Arborescence d'héritage (ou Contexte d'héritage) utilisée par DependencyObject et DependencyProperty .

J'aimerais utiliser la fonctionnalité d'héritage de valeurs de DependencyProperty en dehors d'une page WPF typique, telle que l'Objet A soit le parent logique Objet B, et donc une valeur affectée à une propriété sur l'objet A se propagera automatiquement à l'objet B à moins qu'il n'ait été défini localement (un peu comme la propriété FlowDirection fonctionne dans WPF).

Si les objets A et B sont dérivés de DependencyObject et que ne sont pas les enfants d'un UIElement (en d'autres termes, l'objet A est root ), comment établir l’arborescence logique de sorte que DependencyProperty comprenne que B est un enfant de A?

Le Hillberg Freezable Trick comme ainsi que le Les astuces de Josh Smith ne sont pas tout à fait ce que je cherche pour. Je ne souhaite pas extraire les propriétés d'un arbre d'éléments existant ... Je veux créer mon propre arbre d'éléments non visuel ... c'est-à-dire avoir le contrôle du contexte d'héritage.

Quelqu'un sait où se cache cet ensemble de connaissances?

Answer 1

Après de nombreuses recherches et une confusion dans le code source de DependencyObject , voici la réponse courte:

Le InheritenceContext (la propriété qui révèle le parent logique d'une instance) est (comme 90% de l'implémentation utile de DependencyObject ) marqué comme interne et donc caché. à partir de tout code en dehors de WindowsBase.dll

Il est possible d’utiliser la réflexion pour définir le champ _contextParent , ainsi que d’appeler cette méthode cachée pour définir le InheritenceContext , mais à la fin de la journée, pas une solution propre.

Après avoir parcouru le code source de DependencyObject , je dois dire que je ne suis pas impressionné. DependencyObject pourrait et aurait dû être une classe très propre, omniprésente et réutilisable. Au lieu de cela, il est lié structurellement et comportementalement à ses héritiers, et contient même des constantes, champs, méthodes et solutions de contournement spécifiques pour aider Freezable à coexister avec le reste des sous-classes, ce qui non seulement éloigne loin de la bonne conception OO, mais rend également une classe superbe sinon totalement inutilisable en dehors du framework WPF.

Answer 2

Je suppose que vous parlez de la propagation de valeurs aux enfants qui ne remplacent pas les valeurs elles-mêmes.

Le concept d'élément WPF ayant un enfant est introduit par ContentControl pour autant que je sache. Cela entre en jeu beaucoup plus loin dans la hiérarchie que vous ne le souhaitez. Donc, je suppose que si vous deviez simplement dériver de DependencyObject , ce comportement ne se manifesterait pas.

Plus précisément, un enfant doit savoir demander à son parent s'il n'a pas de valeur pour une propriété donnée.

Question intéressante. J'aimerais aussi connaître la réponse complète.