Comparar el marco de trabajo del Diseñador de Windows Forms con el marco de trabajo de WPF Designer
Actualización: noviembre 2007
La arquitectura de WPF Designer es significativamente diferente de la arquitectura del Diseñador de Windows Forms, que se caracteriza por la interfaz IComponent y el espacio de nombres System.ComponentModel. Si ha creado implementaciones personalizadas en tiempo de diseño para controles de formularios Windows Forms, observará que la arquitectura de WPF Designer es más fácil de utilizar y extender.
La arquitectura de WPF Designer conserva las clases TypeConverter y TypeDescriptor del modelo de objetos del Diseñador de Windows Forms. La mayoría de los demás aspectos de la arquitectura de WPF Designer son diferentes. Para obtener más información sobre la arquitectura en tiempo de diseño de formularios Windows Forms, vea Ampliar compatibilidad en tiempo de diseño.
Diferencias clave entre los marcos de trabajo de ComponentModel y de WPF
Las diferencias entre la arquitectura de WPF Designer y del marco de trabajo de System.ComponentModel se resumen en la tabla siguiente.
Marco de trabajo de ComponentModel |
Marco de trabajo de WPF Designer |
|---|---|
Se basa en las interfaces IComponent, IContainer y ISite. |
Se basa en la clase FrameworkElement. |
Utiliza los servicios en tiempo de diseño proporcionados por un host. |
Los diseñadores publican los requisitos mínimos mediante declaración. |
Tipo de diseñador dedicado para cada tipo de control. |
En un tipo de control puede funcionar cualquier cantidad de características. |
Los metadatos se codifican de forma rígida para cada tipo de control; se fijan en el tiempo de compilación del control. |
Los metadatos se implementan en un ensamblado independiente; se pueden personalizar o reemplazar por herramientas. Esto permite actualizar los datos en tiempo de diseño con independencia del control. |
Una interfaz IDesignerHost contiene el estado del diseñador. |
La clase EditingContext contiene el estado del diseñador. |
Los servicios se recopilan y comparten con una implementación de IServiceContainer. |
La clase EditingContext contiene las referencias de servicios. |
BehaviorService administra las interacciones con el teclado, el mouse y los comandos. |
La arquitectura de herramienta de WPF Designer administra las interacciones con el teclado, el mouse y los comandos. |
El modelo de objetos de edición está compuesto de los controles en tiempo de ejecución, con acceso enlazado en tiempo de ejecución a través de la clase PropertyDescriptor. |
El modelo de objetos de edición proporciona una capa de direccionamiento indirecto para abstraer los controles en tiempo de ejecución. Los editores de categorías permiten la edición de varias propiedades en una misma interfaz de usuario. |
IComponent frente a FrameworkElement
Los elementos de WPF se derivan de la clase FrameworkElement, que proporciona la conexión entre los servicios principales de WPF y las clases de elementos del nivel del marco de trabajo.
Los elementos de WPF no implementan la interfaz IComponent. Ésta es una de las razones fundamentales por las que WPF Designer no utiliza el marco de trabajo de System.ComponentModel. Esto significa que los controles de WPF nunca se alojan. Por consiguiente, los controles de WPF no pueden solicitar los servicios del diseñador del entorno de diseño de System.ComponentModel.
Servicios en tiempo de diseño
Los diseñadores del marco de trabajo de System.ComponentModel solicitan servicios al entorno de diseño. En el marco de trabajo de WPF Designer, puede lograr la mayoría de las tareas sin consultar los servicios en el entorno.
En el marco de trabajo de System.ComponentModel, no se garantiza que los servicios del diseñador estén presentes en un host del diseñador, por lo que el código del diseñador personalizado siempre debe comprobar si existe una referencia a null después de llamar al método GetService. El código del diseñador debe aplicar la degradación correcta cuando un servicio no está presente y, en muchos casos, no se puede cumplir esta restricción.
En el marco de trabajo de WPF Designer, un diseñador personalizado publica sus requisitos mínimos mediante declaración. Si un host no puede cumplir el contrato, el diseñador no se carga. Esto hace que la implementación global sea más simple y robusta.
Tipos de diseñador dedicados y desacoplamiento de metadatos
En el marco de trabajo de System.ComponentModel, un tipo de diseñador se asocia a su componente correspondiente a través del atributo de metadatos DesignerAttribute. Esto significa que la relación se establece en tiempo de compilación y fuerza una dependencia codificada de forma rígida entre los comportamientos del componente en tiempo de ejecución y en tiempo de diseño. Para asociar otro diseñador, debe cambiar la declaración de DesignerAttribute y volver a compilar la base de código del componente.
En WPF Designer, los metadatos del diseñador se factorizan en un ensamblado independiente, con lo que se desacoplan físicamente de la implementación en tiempo de ejecución. Esta libertad permite que herramientas diferentes presenten experiencias de diseño completamente distintas para el mismo tipo en tiempo de ejecución. Para obtener más información, vea Almacén de metadatos.
Editar el modelo de objetos
En el marco de trabajo de System.ComponentModel, los diseñadores personalizados tienen acceso a los controles de forma enlazada en tiempo de ejecución a través de la clase PropertyDescriptor. El entorno de diseño no exige esta regla, lo que provoca errores si un programador se olvida de obtener acceso a un control a través de la clase PropertyDescriptor.
En el marco de trabajo de WPF Designer, los diseñadores personalizados interactúan con los controles en tiempo de ejecución mediante un modelo de objetos de edición. Este modelo proporciona una capa de direccionamiento indirecto que abstrae los controles y los convierte en un modelo y una vista. Este modelo de objetos elimina la necesidad de obtener acceso a los controles a través de la clase PropertyDescriptor.
Similitudes con el marco de trabajo del diseñador de ComponentModel
Los contextos de edición constituyen la base de WPF Designer. La clase EditingContext contiene el estado contextual sobre un diseñador.
El contexto de edición es conceptualmente similar a la interfaz IDesignerHost del espacio de nombres System.ComponentModel.Design. La interfaz IDesignerHost define muchas características en su interfaz, pero la clase EditingContext se centra únicamente en los datos y las características de comportamiento.
El contexto de edición expone los servicios de manera similar a la interfaz IServiceContainer. El contexto de edición admite la enumeración, pero no permite quitar los servicios una vez agregados. Para obtener más información, vea Arquitectura de contexto de edición.
Diferencias en el uso de atributos
Los atributos de diseñador tienen significados diferentes en las arquitecturas de WPF Designer y de formularios Windows Forms. En la tabla siguiente se describen las diferencias de uso de los atributos relacionados con los diseñadores entre ambos marcos de trabajo.
Attribute |
Ventana Propiedades de Formularios Windows Forms |
Ventana Propiedades de WPF Designer e inspector de propiedad de Expression Blend |
|---|---|---|
Especifica el valor para pasar a una propiedad que hace que la propiedad obtenga su valor de otro origen. Esto se conoce como ambiente. |
N/D |
|
Especifica si una propiedad o un evento debe mostrarse en la ventana Propiedades. |
Especifica si una propiedad o evento se debería mostrar en una ventana Propiedades. Cuando se establece explícitamente en true para una propiedad que habitualmente no se muestra, se mostrará esa propiedad. |
|
Especifica el nombre de la categoría en la que se agrupa la propiedad o el evento cuando se muestra en un control PropertyGrid establecido en el modo Por categorías. |
Especifica el nombre de la categoría en la que agrupar la propiedad cuando se muestra en un ventana Propiedades. |
|
Especifica el valor predeterminado para una propiedad. |
Para los tipos de datos de CLR, especifica el valor predeterminado de una propiedad. Se omite en las propiedades de dependencia. |
|
Especifica una descripción para una propiedad o evento. |
N/D |
|
Especifica el nombre para mostrar de una propiedad, evento o método void público que no toma ningún argumento. |
Especifica el nombre que aparecerá en la ventana Propiedades de la propiedad a la que se aplica este atributo. |
|
Especifica el editor que se va a utilizar para cambiar una propiedad. |
Especifica el editor que se utiliza para cambiar una propiedad, incluidos los editores de categorías de varias propiedades. |
|
N/D |
EditorBrowsableState.Advanced coloca un editor de categorías o propiedad en el ampliador Advanced. |
|
Especifica la palabra clave de contexto para una clase o miembro. |
N/D |
|
Especifica si se debería localizar una propiedad. |
N/D |
|
Indica los caracteres que ocultan la representación del texto de un objeto, como los asteriscos. |
N/D |
|
Especifica si la propiedad a la que se enlaza este atributo es de sólo lectura o de lectura y escritura en tiempo de diseño. |
Especifica si la propiedad a la que se enlaza este atributo es de sólo lectura o de lectura y escritura en tiempo de diseño. Las propiedades que se marcan con ReadOnlyAttribute mostrarán el objeto de sólo lectura al editor de cadenas en el Inspector de propiedad. |
|
Indica que la ventana Propiedades debe actualizarse cuando cambie el valor de la propiedad asociada. |
N/D |
|
Especifica qué tipo utilizar como convertidor para el objeto al que está enlazado este atributo. |
Especifica qué tipo utilizar como convertidor para el objeto al que está enlazado este atributo. |
|
Especifica el evento predeterminado del componente. |
Especifica el evento predeterminado para un componente, que determina el controlador de eventos que se va a crear al hacer doble clic. |
|
Especifica la propiedad predeterminada del componente. |
Especifica la propiedad predeterminada para un componente, que determina qué propiedad está seleccionada de forma predeterminada. |
|
Especifica la clase utilizada para implementar, en tiempo de diseño, los servicios para un componente. |
N/D |
|
Especifica que el diseñador de una clase pertenece a determinada categoría. |
N/D |
|
Representa un atributo de un elemento de cuadro de herramientas. |
N/D |
|
Especifica la cadena del filtro y el tipo de filtro que se va a utilizar para un cuadro de herramientas. |
N/D |
|
N/D |
Se utiliza para evitar que un tipo se muestre en el cuadro de herramientas cuando se examina un ensamblado para buscar tipos que agregar al cuadro de herramientas. |
|
N/D |
Se utiliza para especificar qué elementos se agregan al cuadro combinado para el editor de colección o el editor de subpropiedades. Permite especificar un generador que personaliza la creación. |
|
N/D |
Se utiliza para especificar el orden en el que se mostrarán las propiedades en la ventana Propiedades. |
Los atributos siguientes se utilizan en el marco de trabajo de WPF Designer, pero no en el marco de trabajo del Diseñador de Windows Forms.
Diferencias al especificar los iconos de cuadro de herramientas
En el marco de trabajo del Diseñador de Windows Forms, para especificar un icono de cuadro de herramientas para el control personalizado se aplica ToolboxBitmapAttribute a la clase del control.
En el marco de trabajo de WPF Designer, se utiliza un recurso incrustado y una convención de nomenclatura para especificar un mapa de bits de cuadro de herramientas. Además, se utiliza ToolboxBrowsableAttribute para restringir qué tipos de un ensamblado están disponibles para rellenar un cuadro de herramientas.
Diferencias al especificar los metadatos
En formularios Windows Forms, los metadatos del diseñador se especifican mediante declaración, aplicando atributos como DesignerAttribute.
En la arquitectura de WPF Designer, los metadatos del diseñador se especifican en un almacén de metadatos. Para obtener más información, vea Almacén de metadatos.
Vea también
Otros recursos
Extensibilidad de WPF Designer