Luis Guerrero Hablando de .NET, Silverlight, WPF, Windows Phone 7 y depuración

5Jul/081

[Curso] WPF para programadores de Windows Forms – Parte 2

En el post anterior sobre WPF para programadores de Windows Forms estuvimos hablando de la compatibilidad Hwnd de las dos tecnologías y de cómo estas se integraban perfectamente en Windows. Ahora viene el turno de comparar los objetos de primer nivel que tenemos en Windows Forms y WPF para crear ventanas. Vamos a centrarnos en comparar cuales son los arboles de herencia de las clase Ventana de WF y WPF para así ver cuáles son las diferencias y similitudes que tienen.

image

image

Si nos fijamos en árbol de herencia de WF, encontramos esto:

System.Object
  System.MarshalByRefObject
    System.ComponentModel.Component
      System.Windows.Forms.Control
        System.Windows.Forms.ScrollableControl
          System.Windows.Forms.ContainerControl
            System.Windows.Forms.Form

System.Windows.Forms.Form es la clase que representa al formulario, la ventana de WF, esta as u vez hereda de ContainerControl que es una clase que provee funcionalidad específica para la administración de controles que son contenedores de otros controles, como por ejemplo un Panel, esta a su vez hereda de ScrollableControl, clase la cual habilita la funcionalidad de scroll del contenido del control. Ahora llegamos a System.Windows.Forms.Control que es la clase base de todos los controles de UI de WF y que además maneja el manejador del control (hWnd), tanto la posición del control Location, como el tamaño Size, como los colores, etc.

Esta clase Control hereda de System.ComponentModel.Component que es la primera clase que no está dentro del namespace System.Windows.Forms, esta clase representa los controles o componentes (como su nombre indica) que pueden usarse dentro de la programación de aplicaciones con soporte para interfaz de usuario. Esta clase es importante pues habilita que nuestros componentes o en este caso controles de Windows Forms soporten un tiempo de diseño. Tiempo de diseño como por ejemplo el diseñador de UI de Visual Studio, es importante aclarar esto porque el soporte del diseñador de WF no es de Visual Studio es de .Net Framework, ya que nosotros mismo podemos habilitar un host de diseño para los componentes de la UI y tendríamos las mismas características que Visual Studio nos ofrece para hostear controles de WF.

Además Component implementa IComponent que habilita el soporte para componentes y IDisposable para la recolección de elementos no administrados dentro de la clase. Component hereda de MarshalByRefObject, clase la cual hereda de System.Object. Esta clase, MarshalByRefObject, habilita que los objetos que hereden puedan ser llamados fuera del dominio de aplicación en el que está el objeto, como por ejemplo en las aplicaciones de Remoting y además especifica que la manera de referenciar objetos remotos es a través de referencia. Fijaros que todos los componentes de Windows Forms heredan de esta clase MarshalByRefObject con lo cual tendrían soporte “de serie” para remoting. En lo que nos concierne e Windows Forms, decir que la clase más importante de todos es System.Windows.Forms.Control que es la que habilita que la ventana sea un control al fin y al cabo, pero un control de alto nivel.

Ahora vamos a ver cuál es el árbol de herencia de una ventana en WPF:

System.Object
  System.Windows.Threading.DispatcherObject
    System.Windows.DependencyObject
      System.Windows.Media.Visual
        System.Windows.UIElement
          System.Windows.FrameworkElement
            System.Windows.Controls.Control
              System.Windows.Controls.ContentControl
                System.Windows.Window

En WPF la clase que representa una ventana es System.Windows.Window y está en el ensamblado PresentationFramework.dll, esta clase hereda de System.Windows.Controls.ContentControl que representa un control de WPF que únicamente tiene un solo hijo o contenido principal, este concepto es muy usado en WPF, un control que únicamente puede contener a otro control. Nosotros en WF tenemos una propiedad Controls que es una lista de todos los controles que contiene ese control, en controles como Panel tiene sentido, pero en Label no tiene sentido tener una lista de controles porque Label no admite más controles hijos, pues bien en WPF todos los controles pueden contener otro control, sin límite y sin excepción. Esto puede resultar algo chocante pero es así, por ejemplo la clase System.Windows.Controls.Label hereda de esta clase con lo que Label tiene una propiedad llamada Content de tipo object en el que nosotros podemos establecer lo que queramos, desde un string, un double, otro Label, un Button, o un MediaElement con un video reproduciéndose. Esto no es como en WF que Label tiene una propiedad Text de tipo string para establecer un texto, en WPF los controles que heredan de ContentControl pueden establecer en su contenido (Content) lo que queramos, incluso una clase de lógica de negocio (esto ya lo veremos más adelante).

Pero no nos despistemos, ContentControl hereda de System.Windows.Controls.Control que es la clase que representa una UI que una un ControlTemplate para definir su apariencia. ¿Esto qué significa?, pues que la clase Control, tiene una propiedad ControlTemplate para definir el árbol de controles que representa a este control. Ahora justo es el momento para introducir el concepto de XAML. WPF utiliza para definir la interfaz de usuario unos ficheros con extensión .xaml que son básicamente ficheros XML con una estructura jerárquica. Cada nodo de un fichero .xaml representa una clase de WPF y a través de los atributos se establecen las propiedades de la clase, así por ejemplo podemos tener la representación de un Label así 

<Label Content="Nombre" Width="75" />.

Pues bien esta clase ControlTemplate, es justamente eso la plantilla del árbol de controles del control actual, algo así como:

<ControlTemplate TargetType="Button">
    <Grid>
        <Ellipse Fill="{TemplateBinding Background}"/>
        <ContentPresenter HorizontalAlignment="Center"
        VerticalAlignment="Center"/>
    </Grid>
</ControlTemplate>

Podéis pensar que esta clase System.Windows.Controls.Control es la equivalente a System.Windows.Forms.Control, pero no porque la clase Control de WPF tiene muchas más cosas que la de WF y hay una clase base que tiene más similitudes con las clase Control de WF.

Llegado a este punto vamos a seguir otro orden explicando el árbol de herencia porque necesitamos explicar demasiados conceptos que hacienda al revés sería mucho más fácil. Así que ahora el orden que vamos a seguir es:

System.Windows.FrameworkElement
    System.Windows.UIElement
        System.Windows.Media.Visual
            System.Windows.DependencyObject
                System.Windows.Threading.DispatcherObject
                    System.Object

Vamos a ir desde System.Object hacia System.Windows.FrameworkElement. Empezamos con la clase System.Windows.Threading.DispatcherObject que la clase que asocial un objeto con un Dispatcher, ahora bien que es un Dispatcher, vamos primero a repasar un concepto de WF.

En WF la UI de no es multihilo, eso que significa que si desde un Thread diferente al Thread que creo que control se intenta modificar alguna propiedad del control, es una operación no autorizada un puede lanzar una excepción o el programa hacer cosas extrañas. Eso que significa, que si tengo un control y quiero modificar, por ejemplo, la propiedad Text desde otro Thread, ¿no puedo?. Claro que se puede modificar, pero se tiene que hacer de una manera muy especial, utilizando un método definido en la clase System.Windows.Forms.Control llamado Invoke. Este método invoke nos permite pasarle un delegado, para que ese delegado se ejecute dentro del Thread que creo que control. Invoke es un método de instancia con lo que lo tenemos que llamar desde el control que queremos modificar. Y si yo no se cuando tengo que llamar a este método porque no se estoy en un Thread diferente al que lo creo?, pues tienes la propiedad InvokeRequired (bool) que en caso de que sea necesario llamada al método Invoke devolverá true. Pues bien este patrón de llamadas entre hilos para los controles de WF, también está presente en WPF y justamente el Dispatcher es la clase que se encarga de ese cometido. La clase DispatcherObject es la clase que contiene una propiedad llamada Dispatcher que es justamente el que maneja las llamadas entre Threads de los controles de WPF. Esta clase Dispatcher (se llama igual que la propiedad), tiene un método igual que en WF llamado Invoke, pero a diferencia de la propiedad InvokeRequired, aquí para comprobar si el Thread actual es diferente del Thread que creo que control de WPF tenemos el método CheckAccess que devuelve, ojo, true en caso de que el Thread actual sea el mismo Thread que creó el control y false en otro caso, justo al revés que en WF. Además tenemos VerifyAccess que hace lo mismo pero lanza una excepción del tipo InvalidOperationException en caso de que el Thread actual no tenga Dispatcher.

Como veis son dos conceptos análogos pero están implementados de manera diferente en WF y WPF, tengo un post pendiente de cómo funciona el Invoke de WP porque es bastante interesante hablar sobre ello.

La siguiente clase de nuestra lista es DependencyObject la cual es un sistema de propiedades dentro de WPF que soportan herencia y se propagan a través del árbol lógico de una aplicación, para que cuando un valor de una propiedad cambie, por ejemplo, en una ventana todos los controles que están en esa ventana sean notificados del cambio. Si cambiamos el color de la letra en una ventana que todos los controles que están dentro de esa ventana sean notificados, esto ahora mismo en WF es posible, pero la característica principal de esto es que nosotros podemos hacer también nuestras propias dependencias. Esto como imaginareis en WF no tiene ninguna equivalencia.

Y ahora llegamos a System.Windows.Media.Visual una clase muy importante dentro de la UI de WPF. Esta clase provee soporte para dibujado (redering) de la UI, soporte para detención de elementos (hit testing), transformación de coordenadas, recuadrado del contenido. Esta clase es la clase básica para el desarrollo de un control de WPF que tiene soporte para dibujado, y además esta clase tiene soporte para manejador de ventana (hWnd). Las características que tiene son:

  • Soporte para dibujado
  • Transformaciones de los elementos visuales (rotación, translación, escala, etc)
  • Recorte (Clipping)
  • Prueba de coordenadas (Hit testing)
  • Calculo del recuadro de dibujado

Como veis es un soporte muy básico para el dibujado en pantalla no soporta manejo de eventos, layout, estilos o enlace a datos.

La clase System.Windows.UIElement es el punto de inicio para los controles que soportan los diferentes tipos de layout que hay en WPF. En WF estamos acostumbrados a hacer el layout de los controles a través de la posición del control y el tamaño del objeto (Location(Point), Size(Size)), pues bien en WPF hay varios tipos de layout dependiendo del control actual en que contenedor esté. Para que os hagáis una idea es parecido al layout de una web (html) en la que se puede usar Top, Left, Right, Bottom y se pueden usar grids. Esta clase expone una serie de métodos virtuales que las clases que lo heredan pueden sobreescribir para modificar el comportamiento de layout del control. Además este es el primer control dentro del árbol de herencia que soporta eventos de teclado, ratón y estilos. Todos estos eventos están implementados como “routed events” que son un tipo de eventos de WPF que permiten que se propaguen hacia arriba (bubbling) y hacia abajo (tunneling).

Esta clase si se puede comparar como un elemento básico de los controles de Win32 y la podemos comparar más con la clase Control de WF, además de poder compararla también con un elemento de DHTML.

Y llegamos por fin a la clase FrameworkElement la cual aglutina todas las características vistas en las clases anteriores y representa el elemento básico de todos los controles o elementos de framework de WPF. FrameworkElement extiendo UIElement y añade estas características:

  • Define un sistema de layout: FrameworkElement define una serie de métodos virtuales que estaban definidos en UIElement para generar el sistema de layout de los controles, pero define otros métodos para que los controles puedan interactural con ese sistema de layout. Entre los métodos más importantes para el cálculo del layout tenemos, Arrange(Rect final) y Measure(Size size). Arrange posiciona los elementos hijos del control y determina cual es el tamaño en el que los elementos hijos están de manera confortable y Measure los controles hijos calculan cual su tamaño ideal para su dibujado.
  • Define un árbol de controles para que los controles puedan interactuar
  • Define eventos para el ciclo de vida de un objeto.
  • Soporte para enlace a datos
  • Soporte para estilos
  • Soporte para animaciones

Esta parte ha sido un poco más larga, pero hay que tener en cuenta que WPF define mucha más funcionalidad para los controles de la UI que WF. Resumiendo un poco WPF tiene más capas de abstracción para definir la misma funcionalidad que WF y además añade soporte para otras características que en WF no teníamos, como estilos, enlace a datos, layout más complejos, ect. Además de la idea de que un control puede contener a otro control, cosa que en WF no es posible, ahora que tenemos claro cuál es la arquitectura de los controles de WPF, de una manera rápida en el siguiente post vamos a verlo de una manera práctica y con ejemplos concretos de control y ventana.

Luis.

¿Te ha gustado este artículo?

¡Considera subscribirte al RSS para estar al día!

Filed under: .Net, Windows, WPF -> Windows Forms Leave a comment