Pregunta

Ok, esta es solo una idea que tengo flotando en mi cabeza con respecto a una especie de propiedad de dependencia 'pseudo-escritura, solo'. yo digo algo así como Porque en realidad ni siquiera quiero que el valor se almacene, sino que quiero que el valor que pase al setter establezca otro propiedades. Como ejemplo hipotético, me gustaría hacer esto ...

<button UIHelper.Bounds="10,10,40,20" />

en lugar de esto...

<button Canvas.Left="10" Canvas.Top="10" Width="40" Height="20" />

Solo una cosa de conveniencia de tipo XAML que me permite establecer las cuatro propiedades reales con algo más fácil de escribir gracias para decir una propiedad adjunta de solo escritura. Piense en el camino de las reglas CSS colapsadas. En realidad, a ese sentido, aquí hay otro ...

<border UIHelper.BrushSpec="AliceBlue Red 2 4" />

en vez de...

<border Background="AliceBlue" BorderBrush="Red" BorderThickness="2" CornerRadius="4" />

Ahora, utilizando el primero como ejemplo, una idea es almacenar una estructura de este tipo internamente, luego sincronizarla con el ancho existente, la altura, el canvas.left y las propiedades de la tope. Entonces eso no es necesario. (Técnicamente podría ignorar el almacenamiento por completo y simplemente llamar a ClearValue en el manejador de propiedad de propiedad, pero nuevamente, no es realmente para leerlo, así que eso es solo por consistencia).

Técnicamente, ni siquiera quiero/necesito que esto sea un DP, excepto que tengo entendido, si necesita configurarlo de XAML, tiene que ser un DP, de ahí lo que busque. Sería perfecto si pudiéramos establecer una propiedad .NET directa, ya que podría hacer que la implementación se ajuste y reconstruirse según sea necesario, pero nuevamente, entiendo que no puede acceder a las propiedades de .NET desde XAML, por lo tanto, yo '' m de regreso aquí.

Ahora sí, sé que este concepto estará mal visto por mucha gente, especialmente los puristas de Xaml, pero estoy preguntando cómo no por qué Entonces, si por otra razón, considere esto un ejercicio en 'se puede hacer' no 'si se hace'. Ni siquiera estoy sugiriendo que esto sea lo que usaré. Solo estoy tratando de comprender mejor los límites de DPS y XAML y considero que los ejercicios como este son realmente útiles.

Entonces, ¿pensamientos?

METRO

No hay solución correcta

Otros consejos

Sin ir al extremo de escribir su propio compilador XAML, creo que lo mejor que puede hacer es una propiedad adjunta que establece el grupo de propiedades que le interesan en función de alguna sintaxis compacta que define. Sí, esto significa que ha asignado almacenamiento para la representación compacta, pero como usted dice que podría eliminarlo inmediatamente después de aplicar. Sería un poco poco ortodoxo, pero técnicamente funcionaría.

También podría intentar no declarar un campo de propiedad adjunto para que se acceda al valor a través de los métodos GET/SET (no he probado esto, pero creo que funciona cuando el DP es privado, por lo que tal vez esto funcione). De esta manera, en realidad podría tenerlo legible también sin tener problemas para escuchar los cambios en las propiedades relevantes. Por supuesto, significa que su propiedad no tendrá una notificación de cambio:

public static string GetBounds(UIElement uiElement)
{
    return Canvas.GetLeft(uiElement) + "," + ...;
}

public static void SetBounds(UIElement uiElement, string compact)
{
    // parse and apply compact
}

Solo estoy poniendo la representación compacta en un string Arriba, pero probablemente desee usar un tipo específico. Una vez más, lo anterior puede no funcionar: es posible que necesite el asociado DependencyProperty instancia. Si estuviera en una máquina de Windows, lo intentaría.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top