Este equipo de expertos pasados varios días de trabajo y recopilación de de información, han obtenido los datos necesarios, queremos que resulte útil para ti para tu plan.
Solución:
Aquí hay dos conceptos: propiedades de dependencia y propiedades de dependencia adjuntas. Las “propiedades adjuntas” son propiedades de dependencia y, como tales, admiten la herencia del valor de la propiedad de dependencia.
Acerca de las propiedades de dependencia básicas, una declaración muy aproximada sería que básicamente heredan sus valores de los elementos principales en el árbol wpf (lógico/visual). Una propiedad de dependencia (adjunta o no) hereda su valor “hacia abajo” si sus metadatos se establecen con FrameworkPropertyMetadataOptions.Heredar bandera, y en muchos casos esto es así.
Las propiedades adjuntas son propiedades que se pueden establecer en cualquier objeto wpf (básicamente, por lo menos un DependencyObject) a través del método DependencyObject.SetValue. El propósito de este mecanismo es “adjuntar” a otros objetos la información que necesitan los objetos principales, no los propios objetos secundarios. Por ejemplo, Grid.Row es una propiedad adjunta requerida por Grid para colocar elementos dentro de su área de representación.
Las propiedades de dependencia son heredadas “hacia abajo” automáticamente por el sistema de objetos wpf.
Las propiedades adjuntas se examinan “hacia arriba” explícitamente, en el código de objetos específicos. En el caso de Grid, al determinar dónde colocar sus elementos, comprueba el valor de las propiedades adjuntas Grid.Row y Grid.Column en cada elemento contenido.
También es a menudo la técnica para crear propiedades adjuntas personalizadas que modifican de alguna manera los objetos a los que están adjuntos (por ejemplo, la funcionalidad de arrastrar y soltar a través de propiedades adjuntas).
Como nota adicional, un buen ejemplo de una propiedad adjunta heredada es TextElement.FontFamily. Las propiedades Grid.Row y Grid.Column no tienen establecida la marca Inherits.
TextElement.FontFamily, de Reflector:
FontFamilyProperty = DependencyProperty.RegisterAttached("FontFamily", typeof(FontFamily), typeof(TextElement), new FrameworkPropertyMetadata(SystemFonts.MessageFontFamily, FrameworkPropertyMetadataOptions.Inherits | FrameworkPropertyMetadataOptions.AffectsRender | FrameworkPropertyMetadataOptions.AffectsMeasure), new ValidateValueCallback(TextElement.IsValidFontFamily));
Grid.Row, de Reflector:
RowProperty = DependencyProperty.RegisterAttached("Row", typeof(int), typeof(Grid), new FrameworkPropertyMetadata(0, new PropertyChangedCallback(Grid.OnCellAttachedPropertyChanged)), new ValidateValueCallback(Grid.IsIntValueNotNegative));
Desde MSDN:
Aunque las propiedades adjuntas se pueden establecer en cualquier objeto, eso no significa automáticamente que establecer la propiedad producirá un resultado tangible, o que el valor será utilizado alguna vez por otro objeto. En general, las propiedades adjuntas están pensadas para que los objetos que provienen de una amplia variedad de posibles jerarquías de clases o relaciones lógicas puedan informar información común al tipo que define la propiedad adjunta. El tipo que define la propiedad adjunta normalmente sigue uno de estos modelos:
-
El tipo que define la propiedad adjunta está diseñado para que pueda ser el elemento principal de los elementos que establecerán valores para la propiedad adjunta. Luego, el tipo itera sus objetos secundarios a través de la lógica interna contra alguna estructura de árbol de objetos, obtiene los valores y actúa sobre esos valores de alguna manera.
-
El tipo que define la propiedad adjunta se utilizará como elemento secundario para una variedad de posibles elementos principales y modelos de contenido.
-
El tipo que define la propiedad adjunta representa un servicio. Otros tipos establecen valores para la propiedad adjunta. Luego, cuando el elemento que establece la propiedad se evalúa en el contexto del servicio, los valores de propiedad adjuntos se obtienen a través de la lógica interna de la clase de servicio.
Un ejemplo de una propiedad adjunta definida por padres
El escenario más típico en el que WPF define una propiedad adjunta es cuando un elemento principal admite una colección de elementos secundarios y también implementa un comportamiento en el que los detalles del comportamiento se notifican individualmente para cada elemento secundario.
DockPanel define la propiedad adjunta DockPanel.Dock, y DockPanel tiene código de nivel de clase como parte de su lógica de representación (específicamente, MeasureOverride y ArrangeOverride). Una instancia de DockPanel siempre verificará si alguno de sus elementos secundarios inmediatos ha establecido un valor para DockPanel.Dock. Si es así, esos valores se convierten en entrada para la lógica de representación aplicada a ese elemento secundario en particular. Cada una de las instancias anidadas de DockPanel trata sus propias colecciones de elementos secundarios inmediatos, pero ese comportamiento es específico de la implementación de cómo DockPanel procesa los valores de DockPanel.Dock. En teoría, es posible tener propiedades adjuntas que influyan en elementos más allá del padre inmediato. Si la propiedad adjunta DockPanel.Dock se establece en un elemento que no tiene un elemento primario DockPanel para actuar sobre él, no se genera ningún error ni excepción. Esto simplemente significa que se estableció un valor de propiedad global, pero no tiene un padre actual de DockPanel que pueda consumir la información.
Reseñas y valoraciones de la guía
Más adelante puedes encontrar las observaciones de otros desarrolladores, tú incluso tienes la habilidad mostrar el tuyo si lo deseas.