2012-06-17 17 views
10

Me puede faltar algo sobre los fundamentos del diseño de WPF, pero me preguntaba por qué muchas propiedades en los controles de WPF están expuestas como el tipo 'Objeto'?¿Por qué hay muchas propiedades en WPF como 'Objeto' en lugar de una interfaz?

Por ejemplo, MenuItem.Icon es un objeto, al igual que MenuItem.ToolTip. Como usuario casi nuevo, esto me resultaba muy confuso (parecía que estaba usando un lenguaje de programación dinámico, sin tener ni idea de si la configuración de ToolTip en un tipo de cadena funcionaría o no). Además, traté de configurar el ícono como 'System.Drawing.Icon' y recibí una ArgumentException de "Argument 'picture' debe ser una imagen que se puede usar como un ícono". ¿No debería escribirse la propiedad de modo que al menos pueda describir qué se supone que debes darle en el mundo?

Honestamente, creo que la razón es porque no se puede implementar una interfaz en un tipo que no se creó (sin crear un contenedor), pero eso es solo una suposición.

¡Muchas gracias por sus respuestas y opiniones!

Respuesta

2

La razón principal en mi opinión es que desde una Object es la "última clase base de todas las clases en .Net Framework". Esto le da flexibilidad, en WPF no está limitado a un tipo predefinido. Wpf es diferente y tiene una curva de aprendizaje, pero le ofrece muchas más opciones para crear un producto que se vea bien.

es decir

Se puede asignar un cuadro de texto a una información sobre herramientas:

TextBox tb = new TextBox(); 
tb.Text = "Hello World"; 
this.ToolTip = tb; 

un mapa de bits

BitmapImage myBitmapImage = new BitmapImage(new Uri((@"C:\Temp\20100706.jpg"))); 
Image image = new Image(); 
image.Source = myBitmapImage; 
this.ToolTip = image; 

y asignar una imagen a una Menultem

BitmapImage myBitmapImage = new BitmapImage(new Uri((@"C:\Temp\20100706.jpg"))); 
Image image = new Image(); 
image.Source = myBitmapImage; 
menuItem1.Icon = image; 
+0

Creo que es genial, pero ¿no tiene que ser el objeto una especie de elemento UI? Tanto TextBox como Image son FrameworkElements. Lo único que he visto que puedes asignar que no es un FrameworkElement es un String ... ¿es eso realmente lo único? Si es así, parece que no es una buena razón para que sea 'Objeto', ya que podría crear una Etiqueta o envoltorio alrededor de mi Cadena. – Trevor

+0

@Rovert No, depende de la propiedad, si hay un aspecto visual y una forma de que WPF lo convierta en una Imagen, entonces se mostrará. Puede asignar * cualquier cosa * a un objeto. Creo que es un subproducto de [TypeConversion] (http://msdn.microsoft.com/en-us/library/aa970913.aspx) necesario para hacer que el marcado Xaml funcione. –

+0

Punto interesante sobre TypeConversion. Eso realmente tiene mucho más sentido en cuanto a cómo y qué puede decidir mostrar. Por ejemplo, mirar a ImageSource para descubrir cómo funcionan conduce a una gran confusión, pero ahora sé que debe haber un comportamiento dinámico detrás de las escenas. ¡Gracias! – Trevor

1

en cuenta la ToolTip por ejemplo. Una información sobre herramientas es ContentControl, que puede contener cualquier tipo de objeto CLR (Common Language Runtime) (como una cadena o un objeto DateTime) o un objeto UIElement (como un Rectángulo o un Panel). Esto le permite agregar contenido enriquecido a controles como Button y CheckBox.

Por esta razón, elementos como ToolTip están expuestos como Object, que es la raíz de la jerarquía de tipos (con la facilidad de uso resultante, la flexibilidad y la claridad del código).

0

Imagine que estas propiedades se escriben como UIElements (u otro objeto específico de WPF). ¿Cómo agregaría objetos a sus controles que no eran UIElements?

Debería proporcionar un contenedor derivado de un objeto WPF que expone la información que necesita. La mayoría de las veces, el contenedor simplemente llama al ToString() del objeto que se va a envolver. Dado que la mayoría de los tipos que utilizará proporcionan una implementación predeterminada lo suficientemente buena de ToString() tiene sentido llamar esto en lugar de hacer que el desarrollador escriba envolturas para todo.

En segundo lugar, imagine si se escribieron como alguna interfaz. ¿Qué pasa si quieres comunicar algo que esta interfaz no puede?Las únicas opciones son (a) el desarrollador vive con las limitaciones del marco o (b) Microsoft actualiza la interfaz y rompe todos los códigos existentes que ya se han escrito.

Considere también si está utilizando un patrón como MVVM. El diseño actual significa que sus modelos de visualización pueden exponer propiedades que no están vinculadas a WPF de ninguna manera, lo que hace que su código sea más reutilizable en diferentes tecnologías.

Finalmente, recuerde que hay una diferencia entre el objeto que representa la propiedad y la forma en que WPF representa esa información. P.EJ. si utiliza un tipo primitivo como System.String, WPF creará un bloque de texto y establecerá la propiedad del texto en el resultado de ToString(). Esto permite una separación muy clara entre los datos que se muestra en la interfaz de usuario y de qué manera la información es representa por la interfaz de usuario.

Tomar una clase simple que representa un elemento de menú, por ejemplo:

public class MenuItem 
{ 
    public string Text { get; set; } 
    public bool IsChecked { get; set; } 
    public bool IsEnabled { get; set; } 
} 

Este tipo sólo expone datos sobre el elemento de menú y no tiene información acerca de cómo esta información debe ser prestados. De hecho, aparte del nombre de la clase (MenuItem), esto ni siquiera es específico de un elemento de menú y los mismos datos podrían usarse en otro control de UI, como un cuadro de lista revisado sin cambios necesarios. Si la clase expuso elementos de interfaz de usuario específicos de WPF, entonces la información necesitaría ser adaptada por otro tipo para cada control de interfaz de usuario diferente.

Cuestiones relacionadas