Personalizando el árbol de herencia DependencyObject

Question

Estoy luchando por encontrar información suficiente sobre la propiedad Árbol de herencia (o contexto de herencia) utilizada por DependencyObject y DependencyProperty .

Me gustaría utilizar la capacidad de herencia de valores de DependencyProperty fuera de una página WPF típica, de modo que el Objeto A sea el Objeto B lógico padre y, por lo tanto, un valor asignado a una propiedad en el Objeto A se propagará automáticamente al Objeto B a menos que se haya establecido localmente (un poco como la propiedad FlowDirection funciona en WPF).

Si el Objeto A y el Objeto B están exentos de DependencyObject , y no son hijos de un UIElement (en otras palabras, el Objeto A es es su propia raíz ), entonces, ¿cómo establece el árbol lógico para que DependencyProperty entienda que B es hijo de A?

El Hillberg Freezable Trick as así como La bolsa de trucos de Josh Smith no son exactamente lo que estoy buscando para. no quiero recuperar propiedades de un árbol de elementos existente ... Quiero crear mi propio árbol de elementos no visual ... es decir, tener control sobre el contexto de herencia.

¿Alguien sabe dónde se esconde este cuerpo de conocimiento?

Answer 1

Después de mucha investigación y confusión a través del código fuente de DependencyObject , aquí está la respuesta corta:

El InheritenceContext (la propiedad que revela el padre lógico de una instancia) es (como el 90% de la implementación útil de DependencyObject ) marcado como interno y por lo tanto se mantiene oculto de todo el código fuera de WindowsBase.dll

Es posible utilizar la reflexión para establecer el campo _contextParent , así como llamar a estos métodos ocultos para establecer el InheritenceContext , pero al final del día es su no es una solución limpia.

Después de recorrer el código fuente de DependencyObject , debo decir que no estoy impresionado. DependencyObject podría y debería haber sido una clase muy limpia, ubicua y reutilizable. En su lugar, está vinculado estructuralmente y por su comportamiento a sus herederos, e incluso contiene constantes, campos, métodos y soluciones específicas para ayudar a Freezable a coexistir con el resto de las subclases, que no solo se aleja del buen diseño de OO, sino que también también hace que una clase por lo demás excelente sea completamente inutilizable fuera del marco de trabajo de WPF.

Answer 2

Supongo que está preguntando acerca de la propagación de valores a los hijos que no anulan los valores por sí mismos.

El concepto de un elemento WPF que tiene un hijo es introducido por ContentControl hasta donde yo sé. Esto entra en juego mucho más abajo en la jerarquía de lo que quiere ir. Por lo tanto, supongo que si simplemente derivara de DependencyObject , este comportamiento no se manifestaría.

Específicamente, un niño debe saber preguntarle a su padre si no tiene un valor para una propiedad determinada.

Pregunta interesante. También me gustaría saber la respuesta completa.