[Curso] WPF para programadores de Windows Forms 9 : Templates

[Curso] WPF para programadores de Windows Forms 9 : Templates

En el post anterior comentábamos como en WPF existen el árbol visual y el árbol lógico que nos permite definir como un control se comporta y como se dibuja en la pantalla, pues bien lo que vamos a ver ahora es como se pueden modificar el árbol visual y cómo podemos crear un árbol visual para una clase que no tiene árbol visual.

Todas los tipos de plantillas heredan de la misma clase, FrameworkTemplate que permite definir plantillas para diferentes tipos de controles.

image

Si nos fijamos en el diagrama, tenemos tres tipos de plantillas que definir:

· DataTemplate: permite definir una plantilla de datos, es decir asociar un árbol visual a una clase o tipo. Podemos definir cómo se va a visualizar la clase Employee.

· ControlTemplate: permite cambiar la plantilla visual de un control de WPF.

· ItemsPanelTemplate: permite cambiar la platilla de un control que es una lista de elementos, como por ejemplo un ListBox.

· HierarchicalDataTemplate: permite definir una plantilla de datos para una estructura jerárquica, como por ejemplo un árbol y asociar este a un TreeView.

DataTemplate

La clase DataTemplate permite definir una plantilla visual para un tipo cualquiera. Normalmente las plantillas se definen en XAML. Si tenemos un tipo como este:

public class Employee
{
    public string Name { get; set; }
    public int Age { get; set; }
    public string Company { get; set; }
}

Si lo establecemos como contenido de algún control WPF lo que hará será llamar al ToString() de este objeto para dibujarlo, podemos sobrescribir ToString() para darle otro sentido pero no podemos personalizar como el objeto se dibuja en pantalla.

Lo que podemos hacer es definir su plantilla visual mediante la clase DataTemplate en xaml, normalmente vamos a tener que definir nuestra DataTemplate en un diccionario de recursos o podemos hacerlo directamente en la propiedad ItemTemplate de algunos controles.

<DataTemplate DataType="{x:Type local:Employee}">
   <StackPanel>
       <TextBlock Text="{Binding Path=Name}" />
   </StackPanel>
</DataTemplate>

Como se puede observar en este ejemplo hemos definido un DataTemplate dentro del diccionario de recursos de Window, pero no hemos establecido la propiedad x:Key necesaria para poder acceder a ese valor en el diccionario, sino que lo único que hemos hecho es definir la propiedad DataType de la clase DataTemplate. Al hacer esto WPF automáticamente utilizará esta plantilla para dibujar el tipo Employee cuando se lo encuentre dentro del ámbito de la ventana. Esto es extremadamente útil, porque podemos definir esta plantilla en un ResourceDiccionary a nivel de Application y hacer que esté disponible para toda la aplicación.

Para asociar propiedades de la clase para mostrarla se realiza con un binding como se puede ver en el TextBlock, no quiero centrarme en eso ahora sino simplemente mostrar cuales son las capacidades de personalización de la DataTemplate.

Si hubiéramos utilizado un ContentControl para dibujar nuestro objeto Employe podríamos haber definido la plantilla directamente en la propiedad ContentTemplate, sin necesidad de asociar el DataType o establecer el x:Key.

<ContentControl>
    <ContentControl.ContentTemplate>
        <DataTemplate>
            <StackPanel>
                <TextBlock Text="{Binding Path=Name}" />
            </StackPanel>
        </DataTemplate>
    </ContentControl.ContentTemplate>
</ContentControl>

ControlTemplate

ControlTemplate nos permite definir o redefinir la plantilla de un control, es decir de cualquier control que herede de Control, que es donde está definida la propiedad Template. La manera de proceder es igual, para un Button tenemos:

<ControlTemplate TargetType="{x:Type Button}" x:Key="ButtonControlTemplate">
    <Microsoft_Windows_Themes:ButtonChrome x:Name="Chrome" >
        <Border BorderThickness="3" BorderBrush="red">
            <ContentPresenter />
        </Border>
    </Microsoft_Windows_Themes:ButtonChrome>
</ControlTemplate>

Lo que hemos hecho en este ejemplo es redefinir la plantilla de Button para tener esto:

clip_image004

Como se puede observar lo que tenemos en pantalla no se parece a un botón, no tiene el aspecto que esperamos de un botón, pero si preguntamos su tipo es un Button, así que lo que hemos conseguido es modificar su árbol visual sin necesidad de heredad de Button y generar un tipo nuevo, simplemente cambiado su plantilla.

Este cambio de plantilla normalmente viene integrado en un estilo (Style) pero eso lo veremos en otro post.

ItemsPanelTemplate

Esta clase permite definir la plantilla para un control de tipo ItemsControl, como por ejemplo TreeView, TabControl, etc. En este ejemplo vamos a cambiar la plantilla del ListBox para hacerlo con UniformGrid.

<ItemsPanelTemplate x:Key="ItemsPanel">
    <UniformGrid IsItemsHost="True">
    </UniformGrid>
</ItemsPanelTemplate>

Aquí podemos ver el resultado:

clip_image006clip_image008

Las posibilidades son infinitas, pues podemos personalizar cualquier control como nosotros queramos sin necesidad de tener que tocar una sola línea de código simplemente con un poco de xaml.

HierarchicalDataTemplate

Esta plantilla basada en un DataTemplate permite generar plantillas jerárquicas para nuestros tipos de datos, como está pensada para usarse con un tipo de datos, primero vamos a definir un tipo de dato en árbol y generar algunos elementos.

public class Node
{
    public string Name { get; set; }
    public ObservableCollection<Node> Items { get; set; }

    public Node()
    {
        Items = new ObservableCollection<Node>();
    }
}

Esta clase Node contiene un nombre una colección de elementos y una colección de elementos del mismo tipo en Items. Podemos definir una plantilla jerárquica como esta:

<HierarchicalDataTemplate ItemsSource="{Binding Path=Items}" x:Key="NodeTemplate">
    <TextBlock Text="{Binding Path=Name}" />
</HierarchicalDataTemplate>

Tenemos que definir cuál va a ser la propiedad que se va a usar como origen de datos para los Items que se van a generar, la propiedad ItemsSource nos permite definir mediante un Binding que la propiedad Items, de nuestra clase Node, será la encargada de generar los elementos hijos. Por cada uno de las clases Node que nos encontremos vamos a generar un TextBlock en el que vamos a asociar la propiedad Text del control, con un Binding, a la propiedad Name de nuestra clase Node.

Ahora tenemos que generar algunos elementos de ejemplo:

private Node GenerateRandomNodes()
{
    Node n = new Node();
    n.Name = "Raiz";
    for (int i = 0; i < 20; i++)
    {
        Node tmp = new Node();
        tmp.Name = i.ToString();
        n.Items.Add(tmp);
        for (int x = 0; x < 10; x++)
        {
            Node tmp2 = new Node();
            tmp2.Name = string.Format("{0} - {1}", i, x);
            tmp.Items.Add(tmp2);
        }
    }
    return n;
}

Una vez ejecutado este es el resultado:

clip_image010

Resumiendo

Como se puede observar una de las cosas buenas de tener un árbol visual y un lógico es que podemos redefinir como nuestro control o clase se visualiza en pantalla simplemente generando una plantilla. Las plantillas son el mecanismo natural por el cual se pueden personalizar los controles en WPF y son la principal herramienta de los diseñadores para personalizar.

Avanzado

Para terminar el artículo me gustaría hablar sobre un tema que a todos se nos plantea en algún momento, generar plantillas de manera dinámica, por código. En WPF, se pueden generar plantillas dinámicamente, pero el tema es algo complicado y abstracto. Veamos un ejemplo.

Vamos a intentar definir una plantilla dinámica para nuestro tipo de dato Employee por código, si empezamos a generar código vemos que podemos generar una instancia de la clase DataTemplate pasando por parametro el tipo del objeto al que queremos generar la plantilla, la propiedad VisualTree de tipo FrameworkElementFactory nos permite definir como queremos que sea nuestra plantilla.

Todo el trabajo está en esta clase FrameworkElementFactory, para definir los elementos tenemos que especificar cómo se construirán, así que siguiendo nuestro ejemplo de DataTemplate, en el que tenemos un StackPanel y dentro un TextBlock así es como se definiría en código:

   1: private DataTemplate GenerateDataTemplate()
   2: {
   3:     DataTemplate dt = new DataTemplate(typeof(Employee));
   4:     FrameworkElementFactory stackPanel = new FrameworkElementFactory();
   5:     stackPanel.Type = typeof(StackPanel);
   6:     stackPanel.SetValue(StackPanel.BackgroundProperty, new SolidColorBrush(Colors.Yellow));
   7:     FrameworkElementFactory text = new FrameworkElementFactory(typeof(TextBlock));
   8:     text.SetBinding(TextBlock.TextProperty, new Binding("Name"));
   9:     stackPanel.AppendChild(text);
  10:     text = new FrameworkElementFactory(typeof(TextBlock));
  11:     text.SetBinding(TextBlock.TextProperty, new Binding("Company"));
  12:     stackPanel.AppendChild(text);
  13:     text = new FrameworkElementFactory(typeof(TextBlock));
  14:     text.SetBinding(TextBlock.TextProperty, new Binding("Age"));
  15:     stackPanel.AppendChild(text);
  16:     dt.VisualTree = stackPanel;
  17:     return dt;
  18: }

La idea es establecer en cada uno de los FrameworkElementFactory las DependencyProperties, Bindings y Childrens que definen a un control.

El código fuente lo podéis descargar de aquí http://www.luisguerrero.net/downloads/templates.zip

Saludos. Luis.

[Curso] WPF para programadores de Windows Forms 8

Ha pasado mucho tiempo desde mi último post de esta serie, el trabajo y haberme mudado de casa no me han permitido escribir este tipo de posts. Ahora un poco más relajado podemos continuar con esta serie de post sobre como programar WPF para los programadores de Windows Forms.

En este post vamos a hablar sobre los dos tipos de arboles de controles que hay que WPF: el árbol visual (Visual Tree) y el árbol lógico (Logical Tree). Estos dos conceptos son muy importantes para un programador de WPF porque permite conocer muy bien cómo trabaja WPF con los controles y cómo podemos personalizar los nuestros. En WF solamente tenemos el árbol lógico, siendo este la relación entre los controles que son contenedores con sus hijos.

En WF podemos tener un Panel y dentro de este podemos tener un botón o podemos tener un TabPage y dentro de este podemos tener otro panel y dentro un label. Las relaciones entre los padres e hijos forman un árbol de controles.

image

En este grafico podemos ver cuál es el árbol de controles de un formulario cualquiera de Windows Forms. Con este árbol lo único que estamos especificando es que control está dentro de cual y por tanto cual será su espacio de dibujado.

En WF para especificar el rectángulo de dibujado de un control tenemos la propiedad Location (Size) y tenemos Size (Size), dentro de ese rectángulo podemos dibujar con GDI lo que queramos que después será compuesto formando la imagen final del formulario. La manera en la que se definen visualmente los objetos en Windows Forms es a través del código que se ejecuta en OnRender pero no tenemos ninguna otra manera de definir el aspecto de un control, es decir si queremos cambiar el aspecto del control tenemos que sobreescribir el método OnRender teniendo así que cambiar código del control y generando un tipo nuevo, puesto que la única manera de sobrescribir un método virtual es heredando. Esto tiene una serie de problemas puesto que tenemos que modificar el código de nuestro control y desde la perspectiva de un diseñador gráfico es inviable sentarlo con el Visual Studio a dibujar con GDI.

En WPF la cosa cambia mucho. Ahora, como ya he comentado antes, tenemos dos arboles el visual y el lógico. El árbol visual, como su nombre indica, se encarga de definir cuáles son las clases que se encargan de definir como un control se visualiza en pantalla y el árbol lógico es como el control se comporta.

Para explicar este concepto vamos a escoger el botón de WPF para ver cuáles son su árbol visual y lógico.

clip_image004

Árbol Lógico:

image

Árbol Visual:

image

Como podeos observar la cosa cambia mucho porque, del árbol lógico, que es al que estamos todos acostumbrados, cambia mucho con respecto al árbol visual. Pero vayamos por partes.

Button es un caso especial porque este control hereda de ContentControl lo que significa que podemos establecer como contenido lo que queramos (object) en este caso un string. Esto está relacionado con el árbol lógico porque como vemos, el único hijo del botón es el contenido (Content) lo que desde luego tiene sentido porque en WPF podemos establecer como hijo de un botón lo que queramos como por ejemplo un checkbox.

Vayamos ahora a por el árbol visual: si nos fijamos el árbol visual tiene 3 elementos, un ButtonChrome, un ContentPresenter y un TextBlock. Vamos a identificar esos elementos en la imagen del botón.

clip_image010

· ButtonChrome: corresponde el borde más el degradado del botón

· ContentPresenter: es el hueco donde se dibujará el contenido del control

· TextBlock: es el control en WPF para dibujar texto

Podemos modificar el contenido del botón haciendo que en vez de que contenga un string que contenga un checkbox y este tenga un texto asignado.

clip_image012

Árbol Lógico:

image

Árbol Visual:

image

Ahora como hijo del ContentPresenter tenemos al CheckBox que a su vez tiene su árbol visual.

Como se puede observar para un ejemplo pequeño, el árbol visual contiene 7 elementos así que conforme se añaden nuevos elementos el árbol visual crece muy rápidamente.

Lo bueno que tiene los arboles visuales es que definen la manera en que el control se dibuja a sí mismo separando el aspecto del comportamiento. Ahora podemos modificar el aspecto del botón de WPF sin cambiar su comportamiento, como hacíamos en WF. Esto permite que se pueda definir el árbol visual de un control con XAML permitiendo esto que diseñadores puedan generar estilos o temas de los controles desde herramientas como Expression Blend.

La siguiente pregunta es cómo se modifican o generan estos tipos de plantillas visuales, pero eso lo veremos en el siguiente post que hablaré sobre las diferentes tipos de plantillas para WPF.

Ah, por cierto, si programais para Silverlight decir que todo lo dicho aquí es aplicable igualmente a esta tecnología.

Saludos. Luis.

Virtual Tech Days 09

El 1 de abril se celebro un evento mundial online en Microsoft llamado Virtual Tech Days 09, que duro 24 horas ininterrumpidamente desde diferentes localizaciones del planeta, una agenda cargada de contenidos para que podáis aprender sobre lo nuevo que viene en Microsoft.

Yo participé en este evento como conferenciante hablando de WPF, en concreto de los problemas que se puede encontrar los programadores de Windows Forms cuando quieren migrar a WPF. Hay que recordar que yo mantengo una lista de post llamados “WPF para programadores de WF” y justamente de eso hable, una casualidad que Microsoft me propusiera esa charla.

Aquí tenéis la grabación de la charla desde Msn Video,

WPF para programadores de Windows Form

también os dejo la presentación usada

image

y el enlace a la web oficial. 

http://www.msfttechdays.com/public/home.aspx

Espero que os guste.

[Curso] WPF para programadores de Windows Forms 7

Hola a todos de nuevo, volvemos a la carga con otro artículo sobre WFP para programadores de Windows Forms. En este articulo voy a hablar sobre los diferentes tipos de controles que hay en WPF y como encontramos similitud con los controles de WF.

En artículos anteriores estuvimos hablando sobre el árbol de herencia de WPF y sobre las diferentes clases de las que heredaba un control normal de WPF, pusimos como ejemplo Label, al ser un control que vamos a usar mucho en nuestras aplicaciones.

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.Controls.Label

Ahora en este curso nos vamos a posicionar en System.Windows.UIElement y vamos a ver las diferentes ramas de las cuales salen los demás controles de WPF y ver que funcionalidad nos proporciona.

UIElement es la primera clase de WPF que tiene soporte para dibujado (heredado de Visual), soporte para entrada (Input, heredado de DispatcherObject) y soporte para RouteEvents. Así que técnicamente esta es la clase que tendríamos que usar si queremos empezar a dibujar algo en la pantalla, es la clase que da un soporte más primitivo para el dibujado. En la clase UIElement tenemos un método virtual OnRender que podemos sobreescribir en nuestras clase para poder implementar la funcionalidad personalizada de dibujado de esa clase, en la que se nos pasa un DrawingContext con el que dibujamos la UI del control. DrawingContextes muy parecido a la clase Graphics de GDI y de hecho tiene métodos muy parecidos.

Aquí podemos ver un ejemplo de un control que se dibuja a si mismo con este método.

public class WigoVisual : UIElement
    {
        private Pen pincel;
        public WigoVisual()
        {
            pincel = new Pen(new SolidColorBrush(Colors.Red), 20);
        }
        protected override void OnRender(DrawingContext drawingContext)
        {
            base.OnRender(drawingContext);
            drawingContext.DrawLine(pincel, new Point(0, 0), new Point(100, 100));
            drawingContext.DrawRectangle(new SolidColorBrush(Colors.Green), new Pen(new SolidColorBrush(Colors.Blue), 5),
                new Rect(0, 0, 20, 20));
        }
    }

El control dibuja una línea desde (0,0) hasta (100,100) con el bolígrafo especificado, evidentemente esta clase no tiene soporte para Layout de ninguna manera porque nosotros al dibujar el control no tenemos en cuenta propiedades con Width o ActualWidth para dibujar la línea.

Como podréis comprender esta clase es muy básica en cuanto al soporte de Layout pero muy ponente para un dibujado más personalizado, si queremos ganar en funcionalidad existente tenemos que bajar en el árbol de herencia. La única clase pública del framework que hereda de UIElement es FrameworkElement, y es en esta clase donde se define mucha de la funcionalidad común de todos los controles del Framework, (es por eso que creo que se llama FrameworkElement).

FrameworkElement añade una serie de funcionalidad para que el soporte de Layout de la clase sea mucho más rico que con UIElement. Veámosla.

· Definición del sistema de Layout: define una serie de métodos que eran virtuales en UIElement para implementar el sistema de Layout de WPF.

· Define el árbol lógico de una aplicación WPF y deja la responsabilidad de definir cuál es a las clases herederas.

· Define los eventos del ciclo de vida de un control, eventos como Initialized, Loaded, Unloaded.

· Soporte para enlace a datos dinámico y búsqueda dinámica de recursos estáticos dentro del control.

· Define los estilos (Style) para los controles.

· Define el soporte para las animaciones de los controles.

FrameworkElement define una serie de propiedades básicas con las que podremos empezar a definir el Layout y los demás propiedades de la UI, a partir de esta clase podemos empezar a realizar Layout más complicados sin tener que explícitamente programarlos.

WPF permite que los programadores puedan sacar todo el partido del Layout a partir de una serie de clases que añaden funcionalidad especifica del nivel en el que se encuentran. Si volvemos atrás en el tiempo y recordamos como en Visual Basic 6 se hacían las cosas, los programadores más avanzados se hacían los cálculos ellos mismos para hacer que el control se moviese o fluyera a través del formulario, pero todos los cálculos tenían que ser hechos a mano, después con Windows Forms Microsoft nos dio dos propiedades muy interesantes de la clase Control Anchor y Dock, que permiten que un control se puedan quedar pillado a alguna de sus caras, o lo que es lo mismo que mantenga siempre la misma distancia. Todo este trabajo que antes se hacía a mano en Visual Basic ahora lo tenemos de “serie” dentro de Windows Forms, pues si seguimos avanzando en WPF ese cálculo de distancias se ha llevado al extremo, eso no significa que no se calcule internamente sino que no somos nosotros los responsables de hacer esos cálculos sino que WPF los hace por sí mismo.

Saludos. Luis.

[Curso] WPF para programadores de Windows Forms 6

En la última entrega del curso de WPF para programadores de Windows Forms, hablamos de los DataTemplate, que permitían modificar el aspecto visual de un control. Ahora en este articulo vamos a hablar un poco más sobre esta característica y como se puede extender.

Imaginemos por un momento que empezamos a usar esta característica que junto con los estilos permiten modificar el aspecto de un control de una manera muy sencilla, pero que ahora queremos que el usuario, por ejemplo, elija un tema de una lista de temas disponibles. ¿Cómo podríamos encajar esta funcionalidad con los DataTemplate tendríamos que tener algún mecanismo para poder decidir en tiempo de ejecución que DataTemplate tenemos que elegir. Pero la pregunta es cuando hacemos esto ¿cuando el control se ha cargado?, ¿en el constructor?, la respuesta es DataTemplateSelector .

Esta clase, DataTemplateSelector provee una manera de elegir un DataTemplate en tiempo de ejecución, cuando el control se va a enlazar y se va a construir el árbol visual de controles de nuestro elemento.

DataTemplateSelector tiene un método virtual,

public virtual DataTemplate SelectTemplate(Object item, DependencyObject container)

En el que se nos pasa la referencia del objeto de datos el cual el control está enlazado y el control en sí que es pasado en el container. De esta manera y a través de un enlace a datos podemos decidir que DataTemplate tenemos que establecer. Una vez que tenemos una clase que hereda de DataTemplateSelector, y hemos sobreescrito el método SelectTemplate, tenemos que crear una instancia de esta clase y establecerlo en la propiedad ContentTemplateSelector de la clase ContentControl.

Sería algo parecido a esto:

using System.Windows;
using System.Windows.Controls;

namespace SDKSample
{
    public class TaskListDataTemplateSelector : DataTemplateSelector
    {
        public override DataTemplate

                SelectTemplate(object item, DependencyObject container)
        {
            if (item != null && item is Task)
            {
                Task taskitem = item as Task;
                Window window = Application.Current.MainWindow;
                if (taskitem.Priority == 1)
                    return
                    window.FindResource("importantTaskTemplate") as DataTemplate;
                else
                    return
                    window.FindResource("myTaskTemplate") as DataTemplate;
            }
            return null;
        }
    }
}

Otra necesidad que se nos puede surgir es de generar DataTemplates a partir de código, esto que a priori no es recomendable puesto que añade complejidad extra al código y no permite modificar el aspecto del control a través del xaml y puede que en algún momento sea necesario además de que es necesario recompilar la aplicación.

Si echamos un vistazo a la clase DataTemplate vemos que tiene una propiedad VisualTree, que es el nodo raíz del DataTemplate, el control raíz del DataTemplate. Pero si nos paramos a ver por un momento el tipo de esta propiedad vemos que es de tipo FrameworkElementFactory y no DependencyObjecto Control como podríamos esperar. Esta clase FrameworkElementFactory es en realidad una factoría de FrameworkElement, y es usada por el constructor de controles para inicializar un control. Si nos fijamos en el construcor de esta clase el parámetro que se nos pide es un System.Type que después usara para crear un objeto de ese tipo con System.Activator.

Si miramos los métodos de que dispone esta clase tenemos:

· AddHandler, que nos permite añadir un manejador a un RouteEvent.

· AppendChild, que permite añadir un hijo al elemento actual.

· RemoveHandler, que permite eliminar un manejador previamente creado.

· SetBinding, que permite añadir un binding.

· SetValue, esta es si cabe es el método más interesante de todos ya que nos permite establecer valores de los DP de nuestro control.

En una inicialización normal de un control de WPF podríamos hacer algo así:

Grid grid = new Grid();

Grid.Margin = new Thinkness(3);

Realmente la propiedad Margien es un wrapper en una propiedad del CLR de un DependencyProperty llamado MarginProperty.

Esta sería la manera de hacerla con WPF:

Grid grid = new Grid();

Grid.SetValue(Grid.MarginProperty,new Thinkness(3));

Así que la clase FrameworkElementFactory guarda una lista de los DP que se han establecido para después establecerlos en el control que instancia internamente.

[Curso] WPF para programadores de Windows Forms 5

[Básico – Medio]

Hola de nuevo, hoy vamos a hablar de una característica muy interesante de WPF, los DataTemplate o Data Templating.

¿Qué es un DataTemplate?

Es, como su nombre incica, una plantilla de datos. Pero, ¿a que se refiere con datos?, pues con datos se refiere a cualquier elemento dentro del árbol de controles de WFP. Eso incluye controles, controles de usuario y en general cualquier instancia de una clase. Eso significa que podemos añadir a un ListBox un elemento nuevo y que este sea una clase de negocio que represente un pedido.

Esta característica está muy bien, ya que no necesitamos utilizar ningún tipo de patrón a la hora de añadir a la presentación de nuestras aplicaciones nuestros objetos de negocio. Simplemente añadiéndolo. Pero el caso es que, cuando alguien añada una clase de objeto de negocio a una lista de elementos de un ListBox, el ListBox no sabe como “pintar” o representar ese elemento dentro de la UI, así que lo único que hace es llamar al método ToString() de nuestra clase de negocio.

Podemos por supuesto sobrescribir el método ToString() de nuestra clase de negocio pero el caso es que solamente seremos capaces de representar texto en la interfaz de usuario, y teniendo en cuenta las capacidades de WPF eso es algo que no se puede permitir. Tenemos que tener alguna manera de especificar cómo queremos que se dibuje ese Tipo de dato en pantalla.

Aquí es donde entran los DataTemplate, esta clase es una árbol de controles que van a representar nuestro objeto de negocio.

Imaginemos por un momento que tenemos una clase Cliente tal que así:

public class ClienteV1
  {
      public string Nombre { get; set; }
      public int CodigoCliente { get; set; }
      public DateTime Fecha { get; set; }
  }

Tenemos una serie de propiedades que definen el estado de nuestro cliente, pues bien lo que vamos a hacer es definir un árbol de controles en XAML para representar la clase cliente.

<DataTemplate>
    <WrapPanel>
        <Label/>
        <TextBox/>
        <TextBlock/>
    </WrapPanel>
</DataTemplate>

Ahora mismo únicamente tenemos un XAML que define un árbol de controles que podríamos utilizar para representar nuestra clase cliente, lo único que nos falta es “mapear” o enlazar a datos (DataBinding) las propiedades del objeto de negocio cliente con los controles de nuestro árbol. Se hace así:

<DataTemplate>
    <WrapPanel>
        <Label Content="{Binding Path=Nombre}" />
        <TextBox Text="{Binding Path=Fecha}" />
        <TextBlock Text="{Binding Path=CodigoCliente}" />
    </WrapPanel>
</DataTemplate>

Si nos fijamos por ejemplo en la etiqueta Label, en el atributo “Content” tenemos esto:

Content=”{Binding Path=Nombre}”

¿Qué estamos especificando ahí?, pues básicamente lo que le queremos decir a WPF es que si en el objeto de destino (nuestra clase Cliente) encuentra por reflexión una propiedad, y repito solo funciona con propiedades, con ese nombre pues que obtenga su valor y que lo establezca en la Dependency Property Content del control Label.

Pues ya esta!!.

Ya tenemos definido nuestro DataTemplate para el objeto de negocio Cliente. Es más aunque tenemos sobrescrito el método ToString() en nuestra clase Cliente WPF no hace caso y simplemente establece el DataTemplate.

Características avanzadas de los DataTemplate.

Nosotros en el ejemplo que hemos realizado hemos establecido el valor de este DataTemplate para el control en que estamos, en nuestro caso un ListBox. Puede ser muy común que este DataTemplate se tenga que usar en más sitios dentro de WPF, y lo suyo sería tenerlo como un recurso compartido para que sea accesible desde cualquier sitio. Esto se puede hacer así:

<ListBox HorizontalAlignment="Right" Margin="0,70,57,45" Width="85" IsSynchronizedWithCurrentItem="True" ItemTemplate="{DynamicResource DataTemplate1}"/>

Ahora bien tenemos que definir ese DynamicResource con valor DataTemplate1. Esto se hace a través de unos ficheros llamados ResourcesDiccionary que son una especie de ficheros xaml que solamente contiene recursos compartidos por la aplicación, podemos ver uno aquí:

<ResourceDictionary
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
    <DataTemplate x:Key="DataTemplate1">
        <Grid/>
    </DataTemplate>
    <!-- Resource dictionary entries should be defined here. -->
</ResourceDictionary>

Aunque se haya creado este fichero se tiene que especificar de alguna manera como se tiene que hacer referencia en todo el proyecto, para eso existen los recursos a nivel de aplicación, que los tenemos disponibles en el fichero app.xaml.

Pero lo que tenemos en este fichero son los recursos en sí, no referencias a ficheros externos. Así que tenemos que combinar todos los diccionarios en uno para que sean usados de manera global.

<ResourceDictionary>
    <ResourceDictionary.MergedDictionaries>
        <ResourceDictionary Source="ResourceDictionary.xaml"/>
    </ResourceDictionary.MergedDictionaries>
</ResourceDictionary>

Y así es como se combinan los diccionarios para que estén disponibles en toda la aplicación.

El codigo de la aplicación esta aquí [CursoWPF5.zip]

En el siguiente post del curso hablaremos un poco más en detalle de los DataTemplates, como subscribirse a eventos dentro de los controles que están en la DataTemplate y además como hacer DataTemplates a partir de código.

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

Hola de nuevo a todos, continuamos con el curso de WPF para programadores de Windows Forms, en esta cuarta entrega del curso vamos a empezar a ver cosas mucho más prácticas que teóricas de WPF.

En el post anterior vimos como se creaba una ventana en WPF y como se creaba un objeto System.Windows.Application para empezar a utilizar esa ventana. En este post nos vamos a centrar en ver cuáles son las características que Application nos ofrece y Window, además de ver los dos tipos de aplicaciones que tenemos disponibles en WPF: Windows Application y Browser Application.

Lo que hemos visto hasta ahora son aplicaciones de WPF de ventana “Windows Application” y la ventana representa el contenedor de más alto nivel de la aplicación, este es el modo tradicional de desarrollo de aplicaciones. Después tenemos WPF Browser Application que como su nombre indica la aplicación de wpf es hosteada en un navegador como Internet Explorer o Firefox. Eso que significa que ya no tenemos ventana sino que tenemos un host que ya no es Windows sino una ventana de un navegador y dentro de esa ventana podemos programar.

Yo me voy a centrar en el desarrollo de aplicaciones de escritorio por ser las más comunes. Vamos a empezar a ver cuáles son los métodos, propiedades y eventos que Window define en su ámbito de clase. Nos vamos a centrar en los métodos o propiedades que no estaban disponibles en WF o que son específicos de WPF. Entre los métodos más interesantes tenemos:

  • DragMove, permite que cuando se llame a este método se pueda mover la ventana sin necesita de hacer click en la barra de título.
  • OnContentChanged, método que se llama cuando el contenido de la ventana se modifica, (recordemos que Windows hereda de ContentControl)
  • OnContentRendered, lanza el event ContentRedered.
  • OnCreateAutomationPeer, este método crea un objeto WindowAutomationPeer que se utiliza para hacer pruebas de la UI.

Ahora vamos a ver las propiedades y dependency property

  • AllowsTransparency, es una propiedad que indica si la ventana soporta transparencia.
  • OwnedWindows y Owner, son, respectivamente, la lista de ventanas de las que esta ventena es propietario y el propietario de la ventana actual, esta propiedad es usada para los diálogos modales en WPF.
  • SizeToContent, esta propiedad establece como se va a resizar la ventana en sí, basada en el contenido que muestra.

Vamos ahora a ver algunos ejemplos de ventanas creadas Visual Studio.

image

image

image

Todas estas ventanas están creadas en el mismo proyecto de Visual Studio, solamente se puede seleccionar una ventana al inicio y si queremos ir cambiando que ventana queremos iniciar tenemos que irnos al fichero App.xaml que contiene el Xaml del objeto Application de nuestro proyecto. Dentro de este fichero App.Xaml hay un atributo en el nodo Application StartupUri que es la Uri (Uniform Resource Identifier) de inicio de la aplicación, en mi caso está en VentanaNormal.xaml pero se puede cambiar por cualquier uri que contenga una ventana.

Aquí teneis el proyecto de Visual Studio con los tres ejemplos de ventanas creadas en WPF. [CursoWPF4.zip]

Espero que os guste.

[Curso] WPF para programadores de Windows Forms &ndash; Parte 3

Ahora que ya hemos las diferencias entre las arquitecturas en WPF y Windows Forms es el momento de comparar como se programa en ambas tecnologías. Vamos a comparar cuales son las características para programar con WPF y WF, además de hacer el típico Hola Mundo.

Ambas tecnologías se programan con algún lenguaje incluido en .net framework, WF viene desde la versión 1.0 del framework, mientras que WPF viene incluido en la versión 3.0, 3.0 SP1, 3.5 y 3.5 SP1.

En WPF tenemos dos maneras de definir la interfaz de usuario de nuestros programas, a través de código trasero o a través de XAML. Es algo parecido a como se programa en ASP.NET, se tiene un fichero con extensión aspx que contiene el html y el código de los controles de servidor de ASP.NET y además tenemos el fichero de código trasero asociado con este fichero aspx, por ejemplo podemos tener un Default.aspx y un Default.aspx.cs. Los dos ficheros están asociados a través de la clase que contienen.

Pues bien en WPF es igual, tenemos un fichero Window1.xaml que contiene el código XAML de la UI de la ventana y además tenemos el Window1.xaml.cs que contiene el fichero de código fuente asociado a este fichero xaml. En WPF, como en ASP.NET, se tiene que asociar de alguna manera el fichero xaml con el fichero cs para que se pueda acceder a los controles definidos en el xaml. Por ejemplo tenemos un fichero Window1.xaml definido así

<Window
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        x:Class="WpfApplication1.Window1"
        x:Name="Window"
        Title="Window1"
        Width="640" Height="480">
    <Grid x:Name="LayoutRoot"/>
</Window>

Y tenemos otro fichero Window1.xaml.cs definido de esta manera:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Windows;
using System.Windows.Controls;
using System.Windows.Data;
using System.Windows.Documents;
using System.Windows.Input;
using System.Windows.Media;
using System.Windows.Media.Imaging;
using System.Windows.Navigation;
using System.Windows.Shapes;

namespace WpfApplication1
{
    /// <summary>
    /// Interaction logic for Window1.xaml
    /// </summary>
    public partial class Window1 : Window
    {
        public Window1()
        {
            InitializeComponent();
        }
    }
}

Si nos fijamos en el fichero Window1.xaml.cs está definido un namespace WpfApplication1 y este contiene una clase parcial Window1 que hereda de Syste.Windows.Window, pues bien esta clase Window1 es la que contiene la lógica de la ventana que estamos creando. En el fichero Window1.xaml dentro del nodo Window hay un atributo del namespace {x} definido así xmlns:x=http://schemas.microsoft.com/winfx/2006/xaml y este tiene una propiedad Class en que está establecido el nombre de la clase a la que está asociada esta ventana, hay que tener en cuenta que esta el namespace completo WpfApplication1.Window1 y no directamente Window1, esto es porque después la clase se localizará por reflexión y dentro en la definición de IL no existen namespaces como en C# así que técnicamente el nombre de esa clase no es Window1, sino WpfApplication1.Window1.

Esta sería la manera de asociar un fichero xaml con su correspondiente fichero cs de code behind. Nosotros en este primer ejemplo de Hola Mundo lo vamos a hacer directamente el código todo para familiarizarnos con el entorno y con las clases que hay disponibles.

Primero vamos a definir el código fuente mínimo necesario para insertar un botón dentro de un formulario y al pulsar ese botón que salga un mensaje de Hola Mundo. Así sería en Windows Forms

using System;
using System.Drawing;
using System.Windows.Forms;

namespace WindowsFormsApplication1
{

    static class Program
    {
        [STAThread]
        static void Main()
        {
            Form form = new Form();
            Button button = new Button();
            button.Text = "Hola Mundo Windows Forms";
            button.Location = new Point(10, 10);
            button.Click += new EventHandler(OnButtonClick);
            form.Controls.Add(button);
            Application.Run(form);
        }

        static void OnButtonClick(object sender, EventArgs e)
        {
            MessageBox.Show("Hola mundo WF");
        }
    }
}

Y así sería en WPF.

using System;
using System.Windows;
using System.Windows.Controls;

namespace WpfApplication1
{
    class Program
    {
        [STAThread]
        public static void Main()
        {
            Window window = new Window();
            Button button = new Button();
            button.Content = "Hola Mundo Windows Presentation Foundation";
            button.Click += new RoutedEventHandler(OnButtonClick);
            window.Content = button;
            Application app = new Application();
            app.Run(window);
        }

        static void OnButtonClick(object sender, RoutedEventArgs e)
        {
            MessageBox.Show("Hola Mundo WPF");
        }
    }
}

El código generado es muy parecido, pero podemos ver alguna de las características que hemos estado comentando de WPF. Por ejemplo Window hereda de ContentControl con lo que no tiene una propiedad Controls sino un Content (object) en el que establecemos el botón. El objeto Application en Windows Forms es directamente un singleton, mientras que en WPF tienes que crear una instancia de tu propia aplicación o heredad de esta clase y llamar al método Run, de instancia y no estático como en WF.

En los siguientes post me centraré en WPF y empezaré a hablar de características especificas de WPF.

Espero que os guste.

Luis.

[Curso] WPF para programadores de Windows Forms &ndash; 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.

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

Hola a todos, como programador de Windows Forms, a veces trabajando con WPF me encuentro con problemas que en Windows Forms solucionaba de una manera muy rápida y también me encuentro con problemas que en Windows Forms en WPF son muy sencillos de solucionar. Pues bien esta serie de post son una introducción a WPF para programadores de Windows Forms, que cosas son iguales, similitudes y en que características se diferencian.

Tenemos que decir que Windows Forms es la tecnología que viene con el .Net Framework desde la versión 1.0 y sigue actualmente. Es la tecnología de Microsoft para realizar formularios en Windows y para que lo entendamos completamente es un wrapper muy grande de la api de Win32. Aunque Windows Forms es completamente administrado hay que decir que es compatible con las tecnologías actuales, puedes interpolar con COM y hacer llamadas al sistema operativo, además de que soporta el procesado de mensajes de Windows, como cualquier aplicación Win32.

En contra tenemos WPF que, según Microsoft, es el modelo de programación de la siguiente generación de aplicaciones de escritorio, es como una versión mucho más potente de Windows Forms. Pero no se queda solo en esto las similitudes y las diferencias son a primera vista muy grandes pero en verdad son tecnologías muy similares.

Cualquier programador de C o C++ de Windows sabrá perfectamente cómo funciona el procesado de mensajes de Windows, hay un método en la API de Win32 sendmessage que nos permite enviar mensajes personalizados y que Windows lo enrute al elemento correspondiente.

LRESULT SendMessage(HWND hWnd,     UINT Msg,     WPARAM wParam,     LPARAM lParam );

Esta es la manera que tiene Windows de funcionar con la UI de cualquier programa pues se envía mensajes para cualquier evento que se produzca en el sistema, como por ejemplo:

  • El ratón a entrado en el área de una ventana
  • Se ha movido el ratón
  • Se ha hecho click

Y por ejemplo, otros mensajes no tan sutiles o perceptibles con el usuario como:

  • Se ha conectado un dispositivo USB
  • Se ha creado un proceso
  • Se ha enchufado el adaptador de corriente del equipo (portátil)

Windows Forms y WPF son dos tecnologías que siguen utilizando este procesado de mensaje y lo podemos ver presente claramente en las dos tecnologías.

En Windows Forms podemos sobrescribir una función dentro de la clase System.Windows.Forms.Control llamada WndProc(ref Message m) que justamente lo que hace es procesar esos mensajes de la interfaz de usuario, para que, por ejemplo, cuando alguien pulse en un botón, esta función capture ese mensaje y lance el evento Click. Por eso nosotros no tenemos que estar comprobando cada cierto tiempo que alguien ha pulsado el botón, es porque ese método lo hace por nosotros, los programadores de C++, seguro, conocerán muy bien esta función por ser una función en la que suele haber un switch muy grande que dependiendo del mensaje (UINT Msg) así se llamada a una función o a otra. Aquí tenemos un ejemplo de ese procesado de mensajes de Windows en C++.

LRESULT CALLBACK WndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam) {     int wmId, wmEvent;     PAINTSTRUCT ps;     HDC hdc;      switch (message)     {     case WM_COMMAND:         wmId    = LOWORD(wParam);         wmEvent = HIWORD(wParam);         switch (wmId)         {         case IDM_ABOUT:             DialogBox(hInst, MAKEINTRESOURCE(IDD_ABOUTBOX), hWnd, About);             break;         case IDM_EXIT:             DestroyWindow(hWnd);             break;         default:             return DefWindowProc(hWnd, message, wParam, lParam);         }         break;     case WM_PAINT:         hdc = BeginPaint(hWnd, &ps);         EndPaint(hWnd, &ps);         break;     case WM_DESTROY:         PostQuitMessage(0);         break;     default:         return DefWindowProc(hWnd, message, wParam, lParam);     }     return 0; }

WPF tampoco se queda lejos de este comportamiento, de hecho está también muy integrado ese concepto en WPF. Si nos fijamos en un control cualquiera de WPF, por ejemplo Label, y vemos su árbol de herencia, en concreto de la clase de la cual hereda System.Object.

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.Controls.Label

Esta clase System.Windows.Threading.DispatcherObject, es una clase especial pues es un sistema de procesado de mensajes implementados por un Dispatcher, de hecho funciona igual que el procesador de menajes de Windows Forms y que el método WndProc, y WPF utiliza los mensajes de Win32 para enviarse mensajes entre los hilos y de la UI. Si nos fijamos bien en la clase nos damos cuenta de que es una clase abstracta y por tanto no tiene implementación en todos los métodos, si buscamos con el Reflector si existe un método igual en Windows Forms (WndProc) resulta que tal método no existe. Pero se nos ha asegurado que WPF utiliza este mismo sistema que las demás aplicaciones de Windows, así que ¿dónde está ese método especial?. El hecho de que esta clase sea abstracta no es casual porque resulta que este sistema de Dispatcher puede funcionar de varias maneras, si exploramos con el reflector y vemos las clases que heredan de esta (DispatcherObject) nos encontramos en un namespace interno de Microsoft una clase llamada HwndWrapper (MS.Win32.HwndWrapper) que hereda de DispatcherObject y resulta que esta clase tiene un método WndProc. Bingo. Hemos encontrado la clase que procesa estos mensajes de Windows en las aplicaciones de WPF de la misma manera que lo hace Windows Forms y C++.

Como os he dicho Windows Forms y WPF están construidas de la misma manera en Windows, y el hecho de que las dos sean “HwndReady” permite que podamos interpolar con Windows de manera transparente y el caso es que en una aplicación de Windows Forms podemos hostear un control de WPF y al revés, en WPF podemos hostear un control de Windows Forms. Esto aunque puede parece algo obvio, es una característica que hace que estas dos tecnologías que aunque a priori sean muy diferentes resulta que son muy parecidas y pueden comunicarse de una manera muy transparente.

En el siguiente post sobre como conocer WPF para programadores de Windows Forms haremos una comparación entres los elementos básicos para la UI, las ventanas, los controles, los eventos de teclado y ratón, como se dibujan las aplicaciones y los enlaces a datos.

Espero que os guste!!.

Luis.