Presentación de Windows Presentation Foundation

 

David Chappell
Chappell & Associates

Septiembre de 2006

Se aplica a:
   Windows Vista
   Windows Presentation Foundation
   Microsoft .NET Framework 3.0

Resumen: El objetivo principal de Windows Presentation Foundation (WPF) es ayudar a los desarrolladores a crear interfaces de usuario atractivas y eficaces. Obtenga información sobre cómo la plataforma unificada de WPF ayuda a los diseñadores a participar activos en la creación de interfaces de usuario y proporciona un modelo de programación común para aplicaciones independientes y de explorador. (34 páginas impresas)

Contenido

Descripción de Windows Presentation Foundation
   Ilustración del problema
   Solucionar el problema: ¿Qué proporciona Windows Presentation Foundation?
Uso de Windows Presentation Foundation
   La tecnología de Windows Presentation Foundation
   Aplicación de Windows Presentation Foundation
Herramientas para Windows Presentation Foundation
   Para desarrolladores: Visual Studio
   Para diseñadores: expresión interactiva Designer
Windows Presentation Foundation y otras tecnologías de Microsoft
   Windows Presentation Foundation y Windows Forms
   Windows Presentation Foundation y Win32/MFC
   Windows Presentation Foundation y Direct3D
   Windows Presentation Foundation y AJAX/"Atlas"
   Windows Presentation Foundation y "WPF/E"
Conclusión
Acerca del autor

Descripción de Windows Presentation Foundation

Por definición, las personas técnicas se preocupan más por la tecnología. Muchos profesionales de software están mucho más interesados en cómo funciona una aplicación que en cómo interactúa con sus usuarios. Sin embargo, aquellos usuarios que son, después de todo, los que pagan por todo esto, se preocupan profundamente por las interfaces de usuario. La interfaz de una aplicación es una parte importante de la experiencia de usuario completa con ese software, y para sus usuarios, la experiencia es la aplicación. Proporcionar una mejor experiencia de usuario a través de una mejor interfaz puede mejorar la productividad, ayudar a crear clientes fieles, aumentar las ventas en un sitio web, etc.

Una vez satisfechos con interfaces puramente basadas en caracteres, los usuarios ahora están acostumbrados a las interfaces gráficas. Sin embargo, los requisitos de las interfaces de usuario siguen avanzando. Los gráficos y los medios se han vuelto más utilizados, y la Web ha condicionado a una generación de personas para esperar una interacción fácil con el software. Cuanto más tiempo las personas dediquen a interactuar con las aplicaciones, más importante serán las interfaces para esas aplicaciones. Para mantenerse al día con las expectativas crecientes, la tecnología utilizada para crear interfaces de usuario también debe avanzar.

El objetivo de Windows Presentation Foundation (WPF) es proporcionar estos avances para Windows. Incluido en la versión 3.0 de Microsoft .NET Framework, WPF permite crear interfaces que incorporan documentos, medios, gráficos bidimensionales, animaciones, características similares a web y mucho más. Al igual que todo lo demás en .NET Framework 3.0, WPF estará disponible para Windows Vista, Windows XP y Windows Server 2003, y está programado que se publique cuando Windows Vista se publique. En este documento se presenta WPF, que describe sus diversas partes. El objetivo es aclarar los problemas que aborda esta tecnología y, a continuación, encuestar las soluciones que proporciona WPF.

Ilustración del problema

Supongamos que un hospital quiere crear una nueva aplicación para examinar y supervisar a los pacientes. Los requisitos para la interfaz de usuario de esta nueva aplicación pueden incluir lo siguiente:

• Mostrar imágenes y texto sobre el paciente.
• Mostrar y actualizar gráficos bidimensionales que muestran los signos vitales del paciente, como la frecuencia cardíaca y la presión arterial.
• Proporcionar vistas tridimensionales y superposiciones de información del paciente.
• Presentar vídeo de ultrasonidos y otros diagnósticos, quizás permitiendo a los médicos y enfermeras agregar anotaciones.
• Permitir que el personal del hospital lea y haga notaciones en documentos que describen el paciente y su condición.
• Ejecutarse como una aplicación de Windows, lo que permite una funcionalidad completa para los empleados del hospital y en una aplicación de explorador web con restricciones de seguridad, lo que permite un acceso más limitado por parte de los médicos remotos a través de Internet.

Estos requisitos son ambiciosos, pero no son irrazonables. Las interfaces de usuario que presentan la información correcta de la manera correcta en el momento adecuado pueden tener un valor empresarial significativo. En situaciones como el ejemplo de atención médica que se describe aquí, pueden salvar vidas. En escenarios menos críticos, como comerciantes en línea u otras aplicaciones orientadas al consumidor, proporcionar una experiencia de usuario eficaz puede ayudar a diferenciar las ofertas de una empresa de sus competidores, aumentando tanto las ventas como el valor de la marca de la empresa. El punto es que muchas aplicaciones modernas pueden beneficiarse de proporcionar interfaces que integren gráficos, medios, documentos y otros elementos de una experiencia de usuario moderna.

La creación de este tipo de interfaz en Windows es posible con las tecnologías de 2006, pero es notablemente desafiante. Algunos de los principales obstáculos son:

• Muchas tecnologías diferentes se usan hoy en día para trabajar con gráficos, imágenes y vídeos. La búsqueda de desarrolladores que son competentes para trabajar con estas diversas tecnologías puede ser difícil y costosa, al igual que el mantenimiento de las aplicaciones que crean.
• Diseñar una interfaz que presenta eficazmente toda esta funcionalidad a los usuarios es difícil. Los diseñadores profesionales son necesarios ( los desarrolladores de software no tienen las aptitudes adecuadas), pero los diseñadores y desarrolladores se enfrentan a desafíos significativos al trabajar juntos, especialmente con interfaces completas como la que se describe aquí.
• Ofrecer una interfaz completa como una aplicación de escritorio de Windows independiente y una versión hospedada en explorador requeriría la creación de dos implementaciones independientes con dos conjuntos de tecnología diferentes. Es probable que la aplicación de escritorio de Windows use Windows Forms y otras tecnologías nativas de Windows, mientras que la aplicación hospedada en el explorador usaría HTML y JavaScript. Se necesitan dos grupos diferentes de desarrolladores con dos conjuntos de aptitudes bastante diferentes.

No hay ninguna razón inherente por la que crear interfaces de usuario eficaces y modernas debe ser tan compleja. Una base común podría abordar todos estos desafíos, ofreciendo un enfoque unificado a los desarrolladores al tiempo que permite a los diseñadores desempeñar un papel importante. Como se describe a continuación, esto es exactamente la intención de WPF.

Solucionar el problema: ¿Qué proporciona Windows Presentation Foundation?

Tres aspectos de lo que WPF proporciona destacan como más importantes. Son: una plataforma unificada para interfaces de usuario modernas, la capacidad de que los desarrolladores y diseñadores trabajen conjuntamente y una tecnología común para las interfaces de usuario de windows y explorador web. En esta sección se describe cada uno de estos tres.

Una plataforma unificada para interfaces de usuario modernas

En un mundo anterior a WPF, la creación de una interfaz de usuario de Windows como la descrita anteriormente requeriría el uso de varias tecnologías diferentes. En la tabla siguiente se resume la situación.

	Windows Forms	PDF	Windows Forms/ GDI+	Reproductor de Windows Media	Direct3D	WPF
Interfaz gráfica, por ejemplo, formularios y controles	x					x
Documentos en pantalla	x					x
Documentos de formato fijo		x				x
Imágenes			x			x
Vídeo y audio				x		x
Graphi cs bidimensional			x			x
Gráficos tridimensionales					x	x

Para crear los formularios, controles y otros aspectos típicos de una interfaz gráfica de usuario de Windows, lo más probable es que un desarrollador elija Windows Forms, parte de .NET Framework. Si la interfaz necesita mostrar documentos, Windows Forms tiene compatibilidad con documentos en pantalla, mientras que los documentos con formato fijo pueden usar el PDF de Adobe. Para imágenes y gráficos bidimensionales, el desarrollador usará GDI+, un modelo de programación distinto al que también se puede acceder a través de Windows Forms. Para mostrar vídeo y audio, puede basarse en Reproductor multimedia de Windows y para gráficos tridimensionales, usará Direct3D, una parte estándar de Windows.

Esta situación complicada existe únicamente por razones históricas. Nadie diría que tiene mucho sentido. Lo que tiene sentido es proporcionar una única solución unificada: WPF. Es probable que los desarrolladores que creen aplicaciones para máquinas con WPF instalado lo usen para abordar todas las áreas enumeradas anteriormente. Después de todo, ¿por qué no usar una base coherente para crear interfaces de usuario en lugar de una colección diversa de tecnologías independientes?

WPF no reemplaza todo en esta lista, por supuesto. Windows Forms aplicaciones seguirán teniendo valor, e incluso en un mundo de WPF, algunas aplicaciones nuevas seguirán usando Windows Forms. (Vale la pena señalar que WPF puede interoperar con Windows Forms, algo que se describe con más detalle más adelante en este documento). Reproductor multimedia de Windows sigue teniendo un papel independiente y se seguirán usando documentos PDF. Direct3D también sigue siendo una tecnología importante para juegos y otros tipos de aplicaciones. (De hecho, WPF se basa en Direct3D para toda la representación).

Sin embargo, al proporcionar una amplia gama de funcionalidades en una sola tecnología, WPF puede facilitar considerablemente la creación de interfaces de usuario modernas. Para obtener una idea de lo que este enfoque unificado permite, esta es una pantalla típica que una versión basada en WPF de la aplicación de atención médica descrita anteriormente podría presentar a un usuario:

Figura 1. Una interfaz de WPF puede combinar imágenes, texto, gráficos 2D y 3D, etc.

Esta pantalla contiene texto e imágenes junto con gráficos bidimensionales y bidimensionales. Todo esto se produjo con WPF: el desarrollador no necesita escribir código que use tecnologías gráficas especializadas como GDI+ o Direct3D. Del mismo modo, WPF permite mostrar y quizá anotar vídeo, como la fuente de ultrasonido que se muestra a continuación.

Ilustración 2. Una interfaz de WPF puede incluir vídeo, lo que permite al usuario realizar anotaciones de texto.

WPF también permite mostrar documentos de forma legible. En la aplicación del hospital, por ejemplo, un médico podría buscar notas sobre el tratamiento de un paciente o acceder a la investigación médica actual sobre un tema relevante. De nuevo, es posible que el médico pueda agregar anotaciones como se muestra en la pantalla siguiente.

Figura 3. La interfaz de WPF puede mostrar documentos de varias columnas, incluidas las anotaciones.

Observe que el documento se muestra en columnas legibles y que el usuario puede desplazarse por ella una página a la vez en lugar de desplazarse. Mejorar la legibilidad en pantalla es un objetivo digno y es un objetivo importante de WPF. Sin embargo, resulta útil, ya que los documentos en pantalla son documentos de formato fijo que a veces pueden ser la opción adecuada. Dado que tienen el mismo aspecto en pantalla y en una impresora, los documentos de formato fijo proporcionan un aspecto estándar en cualquier situación. Para definir este tipo de documento, Microsoft ha creado la Especificación de papel XML (XPS). WPF también proporciona un grupo de interfaces de programación de aplicaciones (API) que los desarrolladores pueden usar para crear y trabajar con documentos XPS.

Sin embargo, la creación de interfaces de usuario modernas significa algo más que simplemente unificar lo que una vez fueron diversas tecnologías. También significa aprovechar las tarjetas gráficas modernas, por lo que WPF aprovecha cualquier unidad de procesamiento de gráficos (GPU) disponible en un sistema descargando tanto trabajo como sea posible. Las interfaces modernas tampoco deben restringirse por las limitaciones de los gráficos asignados a bits. En consecuencia, WPF se basa completamente en los gráficos vectoriales, lo que permite cambiar automáticamente el tamaño de una imagen para ajustarse al tamaño y la resolución de la pantalla en la que se muestra. En lugar de crear gráficos diferentes para su visualización en un monitor pequeño y una televisión de pantalla grande, el desarrollador puede permitir que WPF controle esto.

Al unificar todas las tecnologías necesarias para crear una interfaz de usuario en una sola base, WPF puede hacer que la vida sea significativamente más sencilla para las personas que crean esas interfaces. Al requerir que esas personas aprendan solo un único entorno, WPF puede hacer que la creación y el mantenimiento de aplicaciones sean menos costosas. Y al facilitar la creación de interfaces que incorporan gráficos, vídeo y mucho más, WPF puede mejorar la calidad y el valor empresarial de cómo interactúan los usuarios con las aplicaciones de Windows.

La capacidad para que los desarrolladores y diseñadores trabajen juntos

Proporcionar una base tecnológica unificada para crear interfaces de usuario completas es algo bueno. Sin embargo, es probable que los desarrolladores usen esta eficacia, creando interfaces comprensibles y fáciles de usar. La creación de buenas interfaces de usuario, especialmente cuando son tan completas como se acaba de describir en el ejemplo del hospital, a menudo requiere aptitudes que la mayoría de los profesionales de software no tienen. Aunque muchas aplicaciones se crean sin ellas, la verdad es que la creación de excelentes interfaces de usuario requiere trabajar con diseñadores de interfaz profesionales.

¿Pero cómo pueden trabajar juntos los diseñadores y desarrolladores? La forma en que interactúan las dos disciplinas actualmente es problemática. Normalmente, un diseñador usa una herramienta gráfica para crear imágenes estáticas de los diseños de pantalla que debe mostrar una aplicación. A continuación, proporciona estas imágenes al desarrollador, cuyo trabajo es crear el código que los hace reales. Sin embargo, algo que es fácil para un diseñador dibujar puede ser difícil o imposible para que un desarrollador implemente. Las limitaciones tecnológicas, las presiones de programación, la falta de habilidad, los malentendidos o el simple desacuerdo podrían impedir que el desarrollador se realice completamente la visión del diseñador. Lo que se necesita es una manera mejor para que los miembros de estas dos disciplinas interdependientes funcionen juntos sin poner en peligro la calidad de la interfaz.

Para permitir esto, WPF presenta el lenguaje de marcado de aplicaciones (XAML) eXtensible. XAML define un conjunto de elementos XML como Button, TextBox, Label y muchos más para definir exactamente el aspecto de una interfaz de usuario. Normalmente, los elementos XAML también tienen atributos, lo que permite establecer varias opciones. Por ejemplo, este fragmento de código XAML simple crea un botón rojo que contiene la palabra "No":

<Button Background="Red">
 No
</Button>

Cada elemento XAML corresponde a una clase WPF y cada uno de los atributos de ese elemento tiene una propiedad o evento correspondiente en la clase . Por ejemplo, se podría generar el mismo botón rojo con este código de C#:

Button btn = new Button();
btn.Background = Brushes.Red;
btn.Content = "No";

Si todo lo que se puede expresar en XAML también se puede expresar en el código y es , ¿cuál es el valor de XAML? La respuesta es que crear herramientas que generan y consumen descripciones basadas en XML es mucho más fácil que hacer lo mismo con el código. Dado que XAML ofrece una manera fácil de describir una interfaz de usuario, proporciona una mejor manera de que los desarrolladores y diseñadores trabajen juntos. En la ilustración siguiente se muestra el proceso.

Figura 4. XAML ayuda a los diseñadores y desarrolladores a trabajar juntos

Un diseñador puede especificar cómo debe ser una interfaz de usuario e interactuar con una herramienta como Microsoft Expression Interactive Designer. Orientada completamente hacia la definición de la apariencia de una interfaz WPF, esta herramienta genera una descripción de esa interfaz expresada en XAML. (Aunque puede incluir un botón simple como el ejemplo que se muestra aquí, esta descripción es mucho más compleja que el fragmento de código anterior podría sugerir). A continuación, un desarrollador importa esa descripción XAML en una herramienta como Microsoft Visual Studio. En lugar de volver a crear la interfaz desde cero basada en imágenes estáticas producidas por un diseñador, la propia definición de interfaz se adopta al por mayor. A continuación, el desarrollador escribe el código de la interfaz, como los controladores de eventos, junto con cualquier otra funcionalidad que requiera la aplicación. También es posible crear estilos que se pueden aplicar globalmente a la interfaz de una aplicación, lo que le permite personalizarse según sea necesario para diferentes situaciones.

Al permitir que los diseñadores y desarrolladores trabajen juntos de esta manera, se reducen los errores de traducción que tienden a producirse cuando los desarrolladores implementan interfaces de imágenes creadas por el diseñador. También puede permitir que las personas de estos dos roles funcionen en paralelo, con iteración más rápida y mejores comentarios. Y dado que ambos entornos usan el mismo sistema de compilación, se puede pasar una aplicación WPF entre los dos entornos de desarrollo. También hay disponibles herramientas más especializadas para diseñar interfaces definidas por XAML, como zam 3D de Electric Rain para crear elementos de interfaz tridimensionales.

Las interfaces de usuario mejores pueden aumentar la productividad: tienen un valor empresarial medible. Sin embargo, para crear interfaces realmente eficaces, especialmente en el mundo multi faceted que PROPORCIONA WPF, los diseñadores deben convertirse en ciudadanos de primera clase en el proceso. Un objetivo principal de XAML y las herramientas que lo admiten es que esto sea posible.

Una tecnología común para las interfaces de usuario de Windows y explorador web

La creación de interfaces de usuario eficaces para aplicaciones de Windows es importante. Sin embargo, la creación de interfaces eficaces para aplicaciones basadas en web es al menos tan importante. Por definición, estas interfaces las proporciona un explorador web y el enfoque más sencillo es permitir que el explorador muestre pasivamente cualquier HTML que reciba. Las interfaces de explorador con mayor capacidad de respuesta proporcionan lógica que se ejecuta en JavaScript, quizás mediante JavaScript asincrónico y XML (AJAX). La interfaz puede incluso admitir animaciones, vídeo y mucho más mediante Flash Player de Adobe o alguna otra tecnología. A veces conocido como aplicaciones enriquecidas de Internet, el software web que proporciona este tipo de interfaz completa puede mejorar significativamente la experiencia del usuario. También puede agregar un valor empresarial sustancial haciendo que una aplicación web sea más atractiva para los usuarios.

La creación de este tipo de interfaz ha requerido tradicionalmente el uso de un conjunto completamente diferente de tecnologías de los usados para una interfaz nativa de Windows. En consecuencia, los desarrolladores suelen centrarse en uno de estos enfoques: ya sea un desarrollador de interfaz de Windows o es un desarrollador de interfaz web. Sin embargo, para aplicaciones enriquecidas de Internet a las que se accederá desde Windows, ¿por qué debería existir esta dictomía? No hay ninguna razón inherente por la que no se pueden usar las mismas tecnologías tanto para interfaces nativas de Windows como para interfaces de explorador web.

WPF permite esto. Un desarrollador puede crear una aplicación de explorador XAML (XBAP) mediante WPF que se ejecuta en Internet Explorer. De hecho, se puede usar el mismo código para crear una aplicación WPF independiente y un XBAP. En la pantalla siguiente, por ejemplo, se muestra una aplicación de servicios financieros que se ejecuta como una aplicación de Windows independiente. Al igual que la aplicación hospital mostrada anteriormente, esta mezcla texto, imágenes y varios tipos de gráficos. (Esta pantalla también muestra el escritorio de Windows Vista, incluidos gadgets como el reloj y el tema Aero que proporciona los bordes semitransparentes alrededor de la ventana de la aplicación).

Figura 5. Una aplicación de servicios financieros se puede ejecutar como una aplicación WPF independiente.

Este es el aspecto de esta interfaz dentro de Internet Explorer como un XBAP:

Figura 6. La misma aplicación se puede ejecutar potencialmente como un XBAP.

La interfaz ahora está enmarcada por el explorador en lugar de ejecutarse en su propia ventana, pero su funcionalidad sigue siendo la misma. El mismo código también se puede usar en ambos casos, lo que reduce la cantidad de trabajo necesario para abordar ambos tipos de interfaces. El uso del mismo código también significa usar las mismas aptitudes para desarrolladores. En lugar de forzar a los desarrolladores a los cuadros separados de desarrollador de interfaz de Windows o desarrollador de interfaz web, WPF puede dividir esas divisiones, lo que permite usar el mismo conocimiento en ambos casos.

Otra ventaja de usar la misma tecnología tanto para Windows como para las interfaces web es que el creador de una aplicación no necesariamente se ve obligado a decidir de antemano qué tipo de interfaz debe tener la aplicación. Siempre que los clientes de destino cumplan los requisitos para ejecutar XBAP, una aplicación puede proporcionar (o ambos) una interfaz de Windows y una interfaz web que usen en gran medida el mismo código.

Dado que un XBAP se descarga a petición de un servidor web, se enfrenta a requisitos de seguridad más estrictos que una aplicación de Windows independiente. En consecuencia, los XBAP se ejecutan en un espacio aislado de seguridad proporcionado por la seguridad de acceso al código de .NET Framework. XBAPs también se ejecuta solo en sistemas Windows con WPF instalado y solo con Internet Explorer versiones 6 y 7. Sin embargo, para las aplicaciones que cumplen estos requisitos, las aplicaciones enriquecidas de Internet ahora pueden usar la misma base que las aplicaciones de Windows independientes.

Uso de Windows Presentation Foundation

Saber qué problemas soluciona WPF es útil, pero tener cierto conocimiento de cómo soluciona esos problemas también es útil. En esta sección se examina la propia tecnología de WPF y, a continuación, se examinan las distintas formas en que se aplican en aplicaciones de escritorio de Windows, XBAPs y documentos XPS.

La tecnología de Windows Presentation Foundation

Aunque WPF ofrece una base unificada para crear interfaces de usuario, las tecnologías que contiene se pueden examinar en partes discretas y comprensibles. Estas partes incluyen documentos, imágenes, gráficos, animación, etc. Sin embargo, todos dependen del modelo de aplicación básico de WPF, que se describe a continuación.

Modelo de aplicaciones

Al igual que otras partes de .NET Framework, WPF organiza su funcionalidad en un grupo de espacios de nombres, todos incluidos en el espacio de nombres System.Windows . Independientemente de las partes de esta funcionalidad que use, la estructura básica de cada aplicación WPF es mucho igual. Tanto si se trata de una aplicación de Windows independiente como de un XBAP, la aplicación normalmente consta de un conjunto de páginas XAML y código asociados a esas páginas.

En su raíz, cada aplicación hereda de la clase Application estándar de WPF. Esta clase proporciona servicios comunes que son útiles para cada aplicación. Estos incluyen mantener el estado que debe estar disponible para toda la aplicación y proporcionar métodos estándar como Run, que inicia la aplicación y Shutdown, que finaliza.

Se puede crear un objeto Application con XAML, a través del elemento Application o código, mediante la clase Application . (Esto es cierto para prácticamente todo en WPF, pero para simplificar, este documento siempre usa la opción XAML). Esta es una ilustración XAML sencilla:

<Application xmlns=   
    "https://schemas.microsoft.com/winfx/2006/xaml/presentation"
              xmlns:x="https://schemas.microsoft.com/winfx/2006/xaml"
     StartupUri="Page1.xaml"
     x:Class="Example.SimpleApp">
. . . 
</Application>

Esta definición especifica primero el espacio de nombres de WPF como valor predeterminado para este elemento y, a continuación, define un prefijo para el espacio de nombres XAML. (XAML se usa para más de WPF, por lo que estos dos espacios de nombres no son sinónimos). A continuación, se usa el atributo StartupUri para indicar el nombre de la página XAML que se debe cargar y mostrar cuando se inicia la aplicación. El atributo final, Class, se usa para identificar la clase que contiene el código asociado a esta aplicación. Como se mencionó anteriormente, las aplicaciones WPF suelen contener código XAML y código escrito en C# o Visual Basic, por lo que se usa un archivo de código subyacente para contener código para esta clase. Después de esta etiqueta application de apertura aparece el resto del XAML usado para definir esta aplicación, todas las cuales se omiten aquí, seguidas de la etiqueta de cierre para el elemento Application .

Aunque todas las aplicaciones de WPF derivan de la misma clase raíz, todavía hay muchas opciones que un desarrollador debe tomar. Uno grande es decidir si una aplicación debe proporcionar una interfaz basada en diálogo tradicional o una interfaz de navegación. Una interfaz controlada por diálogo proporciona los botones y otros elementos con los que todos los usuarios de Windows están familiarizados. Una interfaz de navegación, por el contrario, actúa como un explorador. En lugar de abrir una nueva ventana para un cuadro de diálogo, por ejemplo, normalmente carga una página nueva. Las interfaces como esta se implementan como un grupo de páginas, cada una de las cuales consta de una interfaz de usuario definida en XAML junto con la lógica expresada en un lenguaje de programación. Al igual que las páginas del explorador definidas por HTML, XAML proporciona un elemento Hyperlink que se puede usar para vincular páginas juntas. Un usuario navega por estas páginas de la manera que lo haría a través de las páginas de una aplicación basada en web, dependiendo de una lista de historial para avanzar y avanzar. No se confunda, sin embargo, esto sigue siendo una aplicación de Windows. Aunque los XBAP suelen usar este tipo de interfaz, también es perfectamente legal para que una aplicación independiente de Windows interactúe con su usuario a través de una interfaz de navegación. La elección la realizan las personas que crean la aplicación.

Sea cual sea el estilo de interfaz que use una aplicación, normalmente muestra una o varias ventanas. WPF proporciona algunas opciones para hacerlo. La clase Window simple proporciona funciones básicas de ventanas, como mostrar, ocultar y cerrar una ventana, y normalmente se usa en una aplicación WPF que no usa una interfaz de navegación. NavigationWindow, que usan las aplicaciones que tienen una interfaz de navegación, amplía la clase Window básica con compatibilidad con la navegación. Esta compatibilidad incluye un método Navigate que permite a la aplicación pasar a una nueva página, un diario que realiza un seguimiento del historial de navegación del usuario y varios eventos relacionados con la navegación.

Diseño y controles

Para organizar las distintas partes de una interfaz, una aplicación WPF usa paneles para el diseño. Cada panel puede contener elementos secundarios, incluidos controles como botones y cuadros de texto, y otros paneles. Diferentes tipos de paneles proporcionan diferentes opciones de diseño. Un DockPanel, por ejemplo, permite colocar sus elementos secundarios a lo largo de los bordes del panel, mientras que grid permite colocar sus elementos secundarios precisamente en una cuadrícula, tal como sugiere su nombre. El desarrollador define el número de filas y columnas de la cuadrícula y, a continuación, especifica exactamente dónde se deben colocar los elementos secundarios. Un canvas permite a un desarrollador colocar sus elementos secundarios libremente en cualquier lugar dentro de los límites del panel.

Al igual que cualquier tecnología de interfaz de usuario, WPF proporciona un gran conjunto de controles y los desarrolladores también pueden crear controles personalizados. El conjunto estándar incluye Button, Label, TextBox, ListBox, Menu, Slider y otros átomos tradicionales del diseño de la interfaz de usuario. También se proporcionan controles más complejos, como SpellCheck, PasswordBox, controles para trabajar con entrada de lápiz (como con un pc tablet) y mucho más.

Como de costumbre en una interfaz gráfica, los eventos generados por el usuario, como los movimientos del mouse y las pulsaciones de teclas, se pueden detectar y controlar mediante los controles de una aplicación WPF. Aunque los controles y otros elementos de la interfaz de usuario se pueden especificar completamente mediante XAML, los eventos deben controlarse en el código. Por ejemplo, esta es una definición XAML de un botón simple en un lienzo:

<Canvas xmlns=
   "https://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="https://schemas.microsoft.com/winfx/2006/xaml"
    x:Class="Example.CodeForCanvas">
  <Button Click="Button_Click">
   Click Here
  </Button>
</Canvas>

La etiqueta Canvas de apertura comienza definiendo los espacios de nombres DE WPF y XAML habituales. A continuación, especifica que el código asociado a este XAML se puede encontrar en una clase denominada CodeForCanvas, que se encuentra en el ejemplo del espacio de nombres de .NET Framework. A continuación, se incluye la definición del propio botón , especificando "Haga clic aquí" como texto en pantalla. El atributo Click de la etiqueta Button de apertura indica que este botón se basa en un método denominado Button_Click para controlar el evento de clic. El código de ese método podría tener este aspecto:

namespace Example {
  public partial class CodeForCanvas : Canvas  {
    void Button_Click(object sender, RoutedEventArgs e)    {
      Button btn = e.Source as Button;
      btn.Background = Brushes.Purple; 
    }
  }
}

El espacio de nombres y el nombre de clase coinciden con los especificados en la etiqueta Canvas que se acaba de mostrar. La clase CodeForCanvas hereda de la clase Canvas base proporcionada por WPF y se define como una clase parcial. Las clases parciales eran una nueva adición en la versión 2.0 de .NET Framework y permiten combinar código definido por separado en una sola clase. En este caso, canvas definido por XAML genera una clase parcial que se combina con la clase parcial que se muestra aquí. El resultado es una clase completa capaz de mostrar un lienzo con un botón y controlar su evento.

El método Button_Click para controlar ese evento se proporciona dentro de la clase CodeForCanvas . Sigue las convenciones habituales de .NET Framework para un evento, aunque los argumentos del evento se transmiten mediante la clase RoutedEventArgs definida por WPF. La propiedad Source de esta clase contiene una referencia al button que generó el evento, que el método usa para cambiar el color del botón a púrpura.

Como sugiere este ejemplo sencillo, los elementos de una interfaz de usuario de WPF se organizan en un árbol visual. En este caso, el árbol consta de solo un canvas con un solo botón secundario, pero en una aplicación WPF real, este árbol suele ser mucho más complejo. Para crear realmente la interfaz en pantalla, este árbol visual debe representarse. Siempre que sea posible, WPF se basa en la representación de hardware, lo que permite que la tarjeta gráfica instalada en el equipo de la aplicación controle el trabajo. Sin embargo, si el hardware gráfico de la máquina no está en el trabajo, WPF representará la interfaz con su propio software. WPF toma la decisión en tiempo de ejecución: los desarrolladores no necesitan hacer nada especial.

Tanto si la representación se realiza en hardware como en software, WPF siempre se basa en un enfoque conocido como gráficos en modo retenido . Los creadores de una aplicación definen el aspecto del árbol visual, normalmente mediante una combinación de XAML y código. A continuación, WPF conserva la información de este árbol. En lugar de requerir que la aplicación vuelva a pintar todo o parte de una ventana cuando el usuario la descubra, por ejemplo, WPF lo controla por sí mismo. Los elementos que componen el árbol se almacenan como objetos, no como píxeles en la pantalla, por lo que WPF tiene suficiente información para controlar este tipo de representación. Incluso si se cambia el tamaño de una ventana y los controles que contiene, WPF puede volver a representar todo por sí solo. Dado que comprende la forma de los gráficos (líneas, puntos suspensivos, etc.) y porque se basa en gráficos vectoriales en lugar de mapas de píxeles, WPF tiene suficiente información para volver a crear la interfaz en el nuevo tamaño.

Estilos y plantillas

A menudo resulta útil poder definir el aspecto de algún elemento de interfaz de usuario una vez y, a continuación, aplicar esa apariencia y su posterioridad. Las hojas de estilos en cascada (CSS) permiten hacerlo en páginas HTML, por ejemplo. WPF proporciona algo similar a los estilos. La capacidad de definir estilos puede ser bastante útil, como sugiere la popularidad de las hojas de estilos CSS. Permiten una mejor separación entre diseñadores y desarrolladores, por ejemplo, lo que permite a un diseñador crear una búsqueda uniforme de una interfaz al tiempo que permiten al desarrollador ignorar estos detalles.

Con el elemento Style de XAML, el creador de una aplicación WPF puede definir uno o varios aspectos de cómo debe tener un aspecto algo y, a continuación, aplicar ese estilo sobre y más. Por ejemplo, un estilo denominado ButtonStyle podría definirse de la siguiente manera:

<Style x:Key="ButtonStyle">
  <Setter Property="Control.Background" Value="Red"/>
  <Setter Property="Control.FontSize" Value="16"/>
</Style>

Cualquier botón definido con este estilo se asignaría un fondo rojo y usaría un tamaño de fuente de 16. Por ejemplo:

  <Button Style="{StaticResource ButtonStyle}">
   Click Here
  </Button>

Como sugiere la apariencia de "StaticResource" en este ejemplo, los estilos de WPF se definen normalmente como un recurso, que es solo los datos definidos por separado del código de una aplicación.

Los estilos permiten más que el ejemplo simple que se muestra aquí podría sugerir. Un estilo se puede derivar de otro estilo, por ejemplo, heredando y quizá invalidando su configuración. Un estilo también puede definir desencadenadores que especifican aspectos comunes del comportamiento interactivo. Por ejemplo, un estilo podría especificar que mantener el mouse sobre un botón debería hacer que el fondo del botón se vuelva amarillo.

WPF también admite el uso de plantillas. Una plantilla es similar a un estilo y hay dos tipos diferentes disponibles:

• Plantillas de datos: permite usar el elemento DataTemplate de XAML para especificar un grupo de características para cómo se deben mostrar los datos. Los colores, la alineación y mucho más se pueden definir una vez en una plantilla de datos y, después, se pueden usar en otra parte de la interfaz de usuario de una aplicación.
• Plantillas de control: permite usar el elemento ControlTemplate de XAML para definir la apariencia de un control.

Proporcionar una manera sencilla de que los creadores de una aplicación definan la apariencia de su interfaz tiene sentido. En WPF, los estilos y las plantillas son mecanismos principales para hacerlo.

Texto

La mayoría de las interfaces de usuario muestran al menos algún texto y otros poco más. Sin embargo, para la mayoría de las personas, leer texto en una pantalla no puede compararse con la lectura de una página impresa. Nos hemos acostumbrado a las representaciones de alta calidad de las letras y las relaciones entre ellas normalmente encontradas en libros y revistas. Cuando leemos texto en pantalla, las cosas no son iguales, el texto de alguna manera no se siente como legible.

WPF tiene como objetivo cerrar esta brecha, lo que hace que el texto en pantalla sea legible como una página impresa. Hacia este final, WPF admite fuentes OpenType estándar del sector, lo que permite usar bibliotecas de fuentes existentes. También admite la tecnología ClearType definida más recientemente. A través del posicionamiento de sub píxeles, una técnica para iluminar individualmente los subelementos que componen cada píxel en pantallas de pantalla modernas, ClearType permite que el texto se vea más suave al ojo humano. WPF también proporciona compatibilidad de bajo nivel para representar texto a través de la clase Glyphs . Como se describe más adelante, los documentos XPS usan esta clase para representar caracteres.

Para mejorar aún más la legibilidad, WPF también permite extras, como ligaduras, donde un grupo de caracteres se reemplaza por una sola imagen conectada. Por ejemplo, el grupo "ffi" normalmente se reemplazará en una página impresa por una sola ligadura conectada que contenga esos tres caracteres. Agregar esto al texto en pantalla hace que el lector se sienta más en casa, incluso si no percibe conscientemente los detalles que crean esa sensación.

Documentos

Hacer que el texto sea más legible es algo bueno, ya que el texto aparece en botones y listas y muchos otros lugares en una interfaz de usuario. Sin embargo, nos preocupamos más sobre el texto cuando se leen fragmentos más largos, como en un documento. En consecuencia, mejorar la legibilidad en pantalla también requiere mejorar cómo se muestran los documentos. Hacia este fin, WPF admite dos tipos de documentos: documentos fijos y documentos de flujo .

Los documentos corregidos tienen el mismo aspecto si se representan en una pantalla o en una impresora. Saber que un documento siempre tendrá el mismo aspecto es importante para algunas formas, documentos legales y otros tipos de publicaciones, por lo que los documentos de formato fijo son importantes en una serie de áreas. Los documentos de formato fijo admitidos por WPF se definen mediante XPS, que se describe más adelante en este documento. El contenido de un documento fijo se puede especificar mediante el elemento FixedDocument de XAML. Este elemento simple contiene solo una lista de elementos PageContent , cada uno que contiene el nombre de una página en el documento fijo. Para mostrar un documento fijo, WPF proporciona el control DocumentViewer . Este control proporciona una visualización de solo lectura de un documento XPS, lo que permite al lector desplazarse hacia atrás y hacia delante en el documento, buscar texto específico, etc.

Aunque los documentos fijos están diseñados para usarse en una pantalla y en papel, los documentos de flujo están diseñados únicamente para la visualización en pantalla. Para que su contenido sea lo más legible posible, un documento de flujo puede ajustar cómo se muestran el texto y los gráficos de un documento en función del tamaño de la ventana y otros factores. Sin duda, los documentos de flujo se definen mediante un elemento XAML denominado FlowDocument. A continuación se muestra un sencillo ejemplo:

  <FlowDocument 
    ColumnWidth="300" 
    IsColumnWidthFlexible="True" 
    IsHyphenationEnabled="True">
      <Paragraph FontSize="12">
       <Bold>Describing WPF</Bold>
      </Paragraph>
      <Paragraph FontSize="10">
       WPF is the user interface technology for the .NET 
       Framework 3.0. It provides a unified foundation for modern 
       user interfaces, including support for documents, two- and 
       three-dimensional graphics, media, and more. It also 
       allows using the same approach (and the same code) for 
       creating standalone Windows applications and applications 
       that run inside a browser.
      </Paragraph>
  </FlowDocument>

Este documento pide que se muestre en una columna con un ancho no inferior a 300. (El ancho se mide en píxeles independientes del dispositivo, cada uno de los cuales se define como 1/96 de pulgada). Sin embargo, en la siguiente línea, el creador del documento dice que este ancho es flexible estableciendo la propiedad IsColumnWidthFlexible en true. Esto autoriza a WPF a cambiar el ancho y el número de columnas que se usarán para mostrar este documento. Si el usuario cambia el ancho de la ventana en la que se muestra este documento, por ejemplo, WPF puede aumentar o disminuir el número y el ancho de las columnas usadas para mostrar el texto del documento.

A continuación, el documento solicita guiones estableciendo la propiedad IsHyphenationEnabled en true. A continuación se muestran los dos párrafos que contiene este documento. El texto dentro de cada uno se encuentra dentro de un elemento Paragraph, cada uno estableciendo un tamaño de fuente diferente. El texto del primer párrafo también indica que debe mostrarse en negrita.

WPF define varias opciones de FlowDocument más para mejorar la legibilidad. Por ejemplo, si la propiedad IsOptimalParagraphEnabled está establecida en true, WPF distribuirá el espacio en blanco lo más uniforme posible a lo largo de un párrafo. Esto puede evitar los "ríos" de espacios en blanco que dañan la legibilidad, algo que normalmente se hace con documentos impresos. Los documentos de flujo también permiten anotaciones, como agregar notas en texto normal o, en equipos tablets, en la entrada de lápiz. Cada anotación consta de un delimitador que identifica qué contenido del documento está asociado a una anotación y carga que contiene el contenido de la propia anotación.

Para mostrar flowDocument, WPF incluye algunos controles diferentes. Son las siguientes:

• FlowDocumentPageViewer: permite pasar por un documento una página a la vez. Este control proporciona un botón hacia delante y atrás junto con un control de zoom que permite al usuario cambiar el tamaño del documento que está leyendo.
• FlowDocumentScrollViewer: proporciona una vista de desplazamiento más tradicional de FlowDocument, completa con una barra de desplazamiento en el lado derecho de la página.
• FlowDocumentReader: combina la funcionalidad de FlowDocumentPageViewer y FlowDocumentScrollViewer. Este control permite al usuario cambiar entre una vista orientada a páginas de un documento de flujo (incluida la visualización de dos páginas a la vez) y una vista de desplazamiento.

A medida que más y más información se entrega digitalmente, la calidad de la experiencia de lectura en pantalla se vuelve más importante. Al proporcionar una visualización adaptable de la información a través de documentos de flujo, WPF intenta mejorar esta experiencia para los usuarios de Windows.

Imágenes

Tanto si representan logotipos de la empresa, imágenes de puestas de sol o algo más, las imágenes son una parte fundamental de muchas interfaces de usuario. En WPF, las imágenes se muestran normalmente mediante el control Imagen . Para mostrar un archivo JPEG, por ejemplo, se podría usar el código XAML siguiente:

<Image 
 Width="200" 
 Source="C:\Documents and Settings\All Users\Documents\
  My Pictures\Ava.jpg" />

El ancho de la imagen se establece en 200 y, una vez más, las unidades aquí son píxeles independientes del dispositivo. El archivo que contiene la imagen se identifica mediante el atributo Source .

Un archivo de imagen puede contener información sobre la imagen(metadatos), como palabras clave y clasificaciones aplicadas por los usuarios, y las aplicaciones WPF pueden leer y escribir esta información. También se puede usar una imagen de maneras más interesantes, como pintarla en una cara de un objeto tridimensional giratorio. Aunque el ejemplo sencillo que se muestra aquí ilustra un caso común, WPF permite usar imágenes de forma significativamente más amplia.

El control Imagen de WPF puede mostrar imágenes almacenadas en varios formatos, como JPEG, BMP, TIFF, GIF y PNG. También puede mostrar imágenes almacenadas con el formato De Foto de Windows Media (WMPhoto) de Microsoft, nuevo con Windows Vista. Cualquier formato que se use, WPF se basa en el componente de creación de imágenes de Windows (WIC) para generar la imagen. Junto con los codificadores o descodificadores (comúnmente conocidos como códecs) para todos los formatos de imagen que se muestran, WIC también proporciona un marco para agregar códecs de terceros.

Vídeo y audio

A medida que las velocidades de red y procesador han aumentado, el vídeo se ha convertido en una parte mayor de la forma en que las personas interactúan con el software. Personas pasar mucho tiempo escuchando música y otros audios en sus ordenadores. En consecuencia, WPF proporciona compatibilidad integrada para ambos.

Esa compatibilidad depende del control MediaElement . Este es un sencillo ejemplo XAML de cómo se puede usar este control:

<MediaElement 
 Source="C:\Documents and Settings\All Users\Documents\
  My Videos\Ruby.wmv" /> 

Este control puede reproducir vídeo WMV, MPEG y AVI, junto con varios formatos de audio.

gráficos de Two-Dimensional

Durante los últimos veinte años, los creadores de gráficos bidimensionales en Windows se han basado en la interfaz de dispositivo gráfico (GDI) y su sucesor, GDI+. Sin embargo, incluso Windows Forms las aplicaciones deben acceder a esta funcionalidad a través de un espacio de nombres diferente: los gráficos 2D no se integran en la propia tecnología de la interfaz de usuario. La situación era aún peor para los gráficos tridimensionales, ya que se requería una tecnología completamente independiente, Direct3D. Con WPF, esta complejidad desaparece para una gran parte de las aplicaciones. Los gráficos 2D y 3D se pueden crear directamente en XAML o en código de procedimiento mediante las bibliotecas de WPF. Al igual que todo lo demás en WPF, los elementos que usan son solo otra parte del árbol visual de una aplicación.

Para gráficos 2D, WPF define un grupo de formas que las aplicaciones pueden usar para crear imágenes. Son las siguientes:

• Línea: dibuja una línea recta entre dos puntos.
• Elllipse: dibuja una elipse.
• Rectángulo: dibuja un rectángulo.
• Polígono: dibuja una forma cerrada definida por un grupo de líneas rectas conectadas.
• Polilínea: dibuja una forma abierta definida por un grupo de líneas rectas conectadas.
• Ruta de acceso: dibuja formas descritas por una ruta de acceso arbitraria. Las formas pueden estar abiertas o cerradas, y las líneas del trazado pueden ser rectas o curvadas. De hecho, todas las demás formas existen únicamente por comodidad, ya que Path se puede usar para dibujar líneas, puntos suspensivos, rectángulos, polígonos, polilíneas, etc.

El uso de estas clases para crear gráficos simples es sencillo. Por ejemplo, el código XAML siguiente dibuja una elipse roja:

<Ellipse Width="30" Height="10" Fill="Red" />

Rellenar una forma se basa en un pincel. En el ejemplo anterior se usa el valor predeterminado, que es un pincel de color sólido, pero WPF proporciona otras opciones. Por ejemplo, un rectángulo lleno de un degradado de color que cambia horizontalmente de rojo a amarillo se puede definir con:

<Rectangle Width="30" Height="10" 
 Fill="HorizontalGradient Red Yellow" />

También hay disponibles otros pinceles, como un degradado vertical, un gradiante radial y pinceles que pintan con imágenes, mapas de bits, etc. Aunque no se muestra aquí, las formas también pueden usar lápices para especificar el color, el ancho y el estilo de su contorno.

Un aspecto clave para entender sobre WPF es que, dado que todo se basa en una base común, combinar distintos aspectos es sencillo. Una aplicación puede mostrar una imagen dentro de un rectángulo, colocar una elipse dentro de un botón y mucho más. Por este motivo, combinar gráficos 2D con gráficos 3D y otras partes de una interfaz es sencillo.

Junto con las formas, WPF también proporciona otro grupo de clases para trabajar con gráficos bidimensionales. Conocidas como geometrías, estas clases son similares de muchas maneras a las formas. Al igual que las formas, que incluyen opciones como Line, Rectangle, Ellipse y Path, las geometrías proporcionan opciones como LineGeometry, RectangleGeometry, EllipseGeometry y PathGeometry. La diferencia más importante entre los dos tipos de clases es que, aunque las formas se usan normalmente para dibujar imágenes visibles, las geometrías se usan con más frecuencia para definir regiones. Si es necesario recortar una imagen cuadrada para ajustarse dentro de un círculo, por ejemplo, la clase EllipseGeometry se puede usar para especificar los límites del círculo. De forma similar, si una aplicación desea definir una región de prueba de posicionamiento, como un área en la que se detectarán clics del mouse, puede hacerlo especificando una geometría para esa región.

Por último, merece la pena mencionar que todo lo descrito en esta sección se implementa realmente sobre una interfaz de nivel inferior denominada capa visual. Es posible crear gráficos, imágenes y texto mediante esta capa directamente. Aunque hacerlo puede ser útil en algunas situaciones, como para crear gráficos simples y de alto rendimiento, la gran mayoría de las aplicaciones usará formas y las otras abstracciones de nivel superior que PROPORCIONA WPF.

gráficos de Three-Dimensional

Los gráficos bidimensionales son una parte común de las interfaces de Windows, por lo que WPF proporciona bastante tecnología en esta área. Los gráficos tridimensionales se usan con menos frecuencia hoy en día, aunque pueden proporcionar un valor sustancial a través de una mejor visualización de datos, gráficos 3D, representaciones de productos, etc. Tradicionalmente, trabajar en 3D ha requerido un conjunto de aptitudes distinto, uno que no se encuentra normalmente fuera de los desarrolladores de juegos y otros grupos especializados. Al hacer que la compatibilidad con gráficos 3D forme parte del entorno estándar, WPF pretende cambiar esto.

Sin WPF, el desarrollo 3D en Windows normalmente se basa en la API de Direct3D. Al igual que todo lo demás en WPF, su compatibilidad con gráficos 3D usa Direct3D en segundo plano, pero los desarrolladores se presentan con un mundo significativamente más sencillo. Aunque todavía hay casos en los que tiene sentido usar Direct3D en lugar de WPF, como se describe más adelante en este documento, la intención de Microsoft es que el desarrollo 3D estándar para interfaces de Windows use WPF.

Para mostrar gráficos 3D en WPF, una aplicación usa el control Viewport3D . Este control proporciona esencialmente una ventana en el mundo tridimensional que describe la aplicación. Un control Viewport3D se puede usar en cualquier parte de una interfaz WPF, lo que permite que los gráficos 3D aparezcan dondequiera que se necesiten.

Para crear una escena 3D, un desarrollador describe uno o varios modelos y, a continuación, especifica cómo se deben iluminar y ver esos modelos. Como de costumbre, todas estas cosas se pueden especificar mediante XAML, código o una combinación de las dos. Para describir un modelo, WPF proporciona una clase GeometryModel3D que permite definir la forma del modelo. Una vez definido un modelo, su apariencia se puede controlar aplicando diferentes tipos de material. La clase SpecularMaterial , por ejemplo, hace que una superficie parezca brillante, mientras que la clase DiffuseMaterial no.

Independientemente de los materiales que use, un modelo se puede iluminar de varias maneras. DirectionalLight proporciona luz que proviene de una dirección específica, mientras que AmbientLight proporciona iluminación uniforme para todo en una escena. Por último, para definir cómo se debe ver el modelo, el desarrollador especifica una cámara. Un PerspectiveCamera, por ejemplo, permite especificar la distancia y la perspectiva desde la que se ve un modelo, mientras que un OrthographicCamera hace lo mismo, excepto sin perspectiva: los objetos más allá de la cámara no aparecen más pequeños.

La creación de escenas 3D complejas directamente en XAML o código no es sencilla. Es seguro suponer que para la gran mayoría de las aplicaciones de WPF que usan 3D, los desarrolladores confiarán en herramientas gráficas para generar las definiciones necesarias. Sin embargo, la capacidad de usar gráficos 3D en una interfaz de usuario estándar tiene el potencial de mejorar significativamente la calidad de lo que ven los usuarios en sus pantallas.

Transformación y efectos

Además de proporcionar una manera de definir formas y otros elementos, WPF también ofrece a los desarrolladores la capacidad de transformar estos elementos girando, cambiando su tamaño, etc. En XAML, se usan elementos como RotateTransform y ScaleTransform para ello. Estas transformaciones se pueden aplicar a cualquier elemento de interfaz de usuario. A continuación se muestra un sencillo ejemplo:

</Button>
  <Button Content="Click Here">
   <Button.RenderTransform>
    <RotateTransform Angle="45" />
   </Button.RenderTransform>
  </Button>

El elemento RotateTransform gira el botón en 45 grados. Aunque girar un botón como este no es especialmente útil, el hecho de que es posible indica la generalidad del diseño de WPF. Dado que los distintos aspectos de una interfaz de usuario no se basan en diferentes tecnologías subyacentes, se pueden combinar de diversas maneras.

WPF también incluye algunos efectos predefinidos. Al igual que las transformaciones, estos efectos se pueden aplicar a varios aspectos de una interfaz de usuario, como Botones, Cuadros combinados y otros. Incluyen un efecto de desenfoque que hace que el elemento de interfaz aparezca aproximadamente, un efecto de brillo externo que hace que un elemento aparezca iluminado y un efecto de sombra de caída que agrega una sombra detrás de un elemento de interfaz.

Animación

La capacidad de hacer que los elementos de una interfaz se muevan ,para animarlos, pueden ser muy útiles. Al hacer clic en un botón, es posible que el botón aparezca hacia abajo y, por ejemplo, hacia arriba, dando mejores comentarios al usuario. Las animaciones más complejas pueden ayudar a crear interfaces que impliquen a sus usuarios dirigir su atención y contar historias. La compatibilidad con animaciones de WPF hace posible esto.

Al igual que con las transformaciones, las animaciones se pueden aplicar a muchos aspectos diferentes de la interfaz, incluidos botones, formas, imágenes, etc. La animación se logra cambiando el valor de una o varias de las propiedades de un objeto a lo largo del tiempo. Por ejemplo, una elipse puede parecer que se abastece lentamente disminuyendo incrementalmente su propiedad Height durante un período de dos segundos.

A menudo resulta útil definir un grupo de animaciones relacionadas. Para permitir esto, WPF proporciona la clase Storyboard . Cada guión gráfico puede contener una o varias escalas de tiempo, y cada una de ellas puede contener una o varias animaciones. Se proporcionan varios tipos de escalas de tiempo, lo que permite que las animaciones se ejecuten secuencialmente o en paralelo. Este es un ejemplo XAML simple (aunque ligeramente incompleto) que ilustra el aplastamiento de una elipse:

    <Ellipse Width="100" Height="50" Fill="Blue"
     Name="EllipseForSquashing">
     . . . 
     <Storyboard>
      <DoubleAnimation
       Storyboard.TargetName="EllipseForSquashing" 
       Storyboard.TargetProperty="Height"
        From="50" To="25" Duration="0:0:2" />
       </Storyboard>
       . . . 
    </Ellipse>      

El ejemplo comienza con la definición de una elipse, como se ha visto anteriormente en este documento. Sin embargo, aquí también se usa la propiedad Name , asignando un identificador que permite hacer referencia a esta elipse más adelante. Se omiten algunos detalles, pero para definir la animación en XAML, debe aparecer un elemento Storyboard . Dado que la propiedad Height de Ellipse es del tipo double, storyboard contiene un elemento DoubleAnimation. Este elemento especifica el nombre de la elipse que se va a animar, la propiedad que se va a cambiar y exactamente cuáles deben ser esos cambios. Aquí, el valor de Height se cambia de 50 a 25 durante un período de dos segundos.

Las animaciones pueden ser mucho más complejas que esto. Pueden desencadenarse mediante eventos, como los clics del mouse, pausarse y, a continuación, reanudarse, establecerse para repetir algún número de veces (o para siempre) y mucho más. El objetivo es permitir a los desarrolladores crear interfaces de usuario que proporcionen mejores comentarios, ofrecer más funcionalidad y que sean más fáciles de usar que de lo contrario.

Enlace de datos

La mayoría de las interfaces de usuario muestran algún tipo de datos. Para facilitar la vida a los desarrolladores que crean esas interfaces, se puede usar el enlace de datos para facilitar la visualización de datos. El enlace de datos permite conectar directamente lo que muestra un control WPF con datos que residen fuera de ese control. Por ejemplo, el valor de la propiedad Text en un control TextBox de WPF podría estar enlazado a una propiedad denominada Name en un objeto Employee que forma parte de la lógica de negocios de esta aplicación. Un cambio en cualquiera de las propiedades podría reflejarse en el otro. Si un usuario actualizó el valor en textBox, la propiedad Name del objeto Employee también cambiaría y viceversa.

La creación de este tipo de conexión entre propiedades en dos objetos requiere el uso de la clase Binding de WPF. Esta es una ilustración XAML ligeramente simplificada de cómo podría tener este aspecto:

<TextBox . . . >
 <TextBox.Text>
  <Binding Path="Name" />
 </TextBox.Text>
</TextBox>

En este ejemplo, el atributo Path del elemento Binding se usa para identificar la propiedad a la que se debe enlazar la propiedad TextBox. La ruta de acceso se usa cuando el objeto de esta propiedad forma parte (que se especificará en tiempo de ejecución) es un objeto de Common Language Runtime (CLR), definido en un lenguaje como C# o Visual Basic. Junto con los objetos CLR, el enlace de datos de WPF también puede conectarse a datos XML directamente mediante la propiedad XPath de Binding. Esta opción crea una consulta XPath que selecciona uno o varios nodos en un documento XML que hace referencia a los datos especificados.

También son posibles opciones de enlace de datos más complejas. Por ejemplo, los enlaces de lista permiten rellenar el contenido de un control ListBox desde cualquier objeto CLR que implemente la interfaz IEnumerable estándar. Si es necesario, los datos también se pueden filtrar o ordenar antes de que se muestren. (Aunque es posible enlazar a un conjunto de datos de ADO.NET, WPF no tiene compatibilidad directa con el enlace a datos en un sistema de administración de bases de datos relacionales). Sea cual sea la opción de enlace de datos que se use, la intención es hacer un requisito común(mostrar los datos en una interfaz de usuario) lo más sencillo posible.

Automatización de la interfaz de usuario

El usuario más común de una interfaz WPF es, por supuesto, una persona. Pero hay ocasiones en las que una interfaz de usuario debe ser controlada no por un ser humano, sino por otro software. La automatización de la interfaz de usuario (UI) de WPF hace posible esto.

Supongamos, por ejemplo, que un desarrollador desea crear scripts de prueba automatizados para una interfaz. Con el acceso mediante programación que proporciona la automatización de la interfaz de usuario, puede crear scripts que impulsen la interfaz como lo haría un usuario humano. La automatización de la interfaz de usuario también es útil para crear ayudas de accesibilidad, como una herramienta que lee en voz alta los distintos elementos de la interfaz. Dado que permite recorrer mediante programación el árbol que contiene esos elementos, la automatización de la interfaz de usuario hace posible la creación de estos tipos de herramientas.

Para permitir esto, WPF crea un árbol de automatización de la interfaz de usuario. Este árbol consta de objetos AutomationElement , cada uno de los cuales representa algo en la interfaz. La raíz del árbol es el escritorio y cada aplicación abierta es un elemento secundario de esta raíz. El árbol continúa en cada una de estas aplicaciones, con cada control WPF representado como uno (o a veces más de uno) AutomationElement objetos. Para permitir el acceso mediante programación completo a la interfaz, todo lo que un usuario puede interactuar con se representa como un automationElement distinto. Por ejemplo, un control con varios botones tendrá el propio control y cada botón representado como un objeto AutomationElement distinto. La creación de este nivel de granularidad en el árbol de automatización de la interfaz de usuario permite que una aplicación cliente, ya sea un script de prueba, una ayuda de accesibilidad o algo más, acceda a cada componente de la interfaz como haría un usuario humano.

La automatización de la interfaz de usuario no es el aspecto más estándar de WPF. La mayoría de las personas probablemente nunca la usarán. Sin embargo, aquellos que lo necesitan, como evaluadores de software y usuarios con discapacidades, realmente lo necesitan. Algo no tiene que ser ampliamente utilizado para ser importante.

Aplicación de Windows Presentation Foundation

WPF contiene una cantidad notable de tecnología. Aunque todo se relaciona con la interacción con personas, la tecnología se aplica hoy en día de tres maneras relacionadas: aplicaciones WPF independientes, XBAPs y documentos XPS. En esta sección se examina cada una de estas tres.

Aplicaciones WPF independientes

La manera más general de usar WPF es en una aplicación independiente. Las aplicaciones WPF independientes se ejecutan como cualquier otra aplicación de Windows; no requieren un explorador web. En consecuencia, las aplicaciones independientes pueden tener plena confianza, por lo que se pueden usar todas las funcionalidades de WPF. La plena confianza también significa que las aplicaciones WPF independientes pueden usar libremente otros servicios disponibles en la máquina, como Windows Communication Foundation (WCF).

Al igual que otras aplicaciones de Windows, se puede instalar una aplicación WPF independiente desde un disco local o desde un servidor de red. También se puede instalar mediante ClickOnce, una instalación en .NET Framework. ClickOnce proporciona una manera sencilla de que los usuarios de Internet Explorer descarguen e instalen aplicaciones de Windows, incluidas las aplicaciones WPF, y que esas aplicaciones se actualicen automáticamente cuando cambian.

Aplicaciones del explorador XAML: XBAPs

Aunque las aplicaciones WPF independientes ofrecen la mayor capacidad, no siempre son la opción adecuada. Muchas situaciones tienen más sentido con un cliente que se ejecuta en un explorador web en lugar de como una aplicación de Windows. Para permitir que estos clientes presenten interfaces de usuario modernas, WPF proporciona XBAP.

Como se muestra en la ilustración siguiente, un XBAP se ejecuta dentro de Internet Explorer. XBAPs puede actuar como cliente para aplicaciones web creadas mediante ASP.NET, JavaServer Pages (JSP) u otras tecnologías web. Para comunicarse con esta aplicación web, XBAP puede usar HTTP o SOAP. Cualquier plataforma de servidor que se use, un XBAP siempre se carga a través de ClickOnce. Sin embargo, no presenta diálogos ni avisos al usuario durante este proceso; un XBAP se carga igual que una página web. Por este motivo, los XBAP no aparecen en el menú Inicio ni en Agregar o quitar programas.

Ilustración 7. Un XBAP que se ejecuta dentro de Internet Explorer

Aunque no es estrictamente necesario, los XBAP suelen presentar una interfaz de navegación al usuario. Esto permite que la aplicación se comporte como un cliente web, que probablemente es lo que espera el usuario. En Internet Explorer 7, un XBAP usa los botones hacia delante y atrás del propio explorador, y las páginas XAML a las que accede un usuario aparecerán en la lista de historial del explorador. En Internet Explorer 6, el XBAP muestra sus propios botones hacia delante y atrás, junto con el mantenimiento de su propia lista de historial. El XBAP puede determinar en qué entorno se ejecuta y hacer lo correcto; el desarrollador no necesita crear versiones diferentes para cada explorador.

Dado que se carga desde la Web y se ejecuta dentro de un explorador, la seguridad de acceso al código de .NET Framework solo concede una confianza limitada a un XBAP. Por este motivo, hay una serie de cosas que una aplicación WPF independiente puede hacer que un XBAP no pueda hacerlo. Por ejemplo, un XBAP implementado desde la zona de Internet no puede realizar ninguna de las acciones siguientes:

• Cree ventanas independientes.
• Mostrar diálogos definidos por la aplicación.
• Muestra un cuadro de diálogo Guardar iniciado por el propio XBAP.
• Acceda al sistema de archivos más allá de un área de almacenamiento aislado limitada.
• Actuar como cliente de automatización de la interfaz de usuario.
• Use WCF. Las aplicaciones WCF deben tener plena confianza y, por tanto, los XBAP implementados desde Internet no pueden usarlo. En su lugar, pueden usar ASP.NET servicios web, comúnmente conocidos como ASMX, para comunicarse con la aplicación web desde la que se cargaron.
• Use cualquier código de interfaz de usuario creado con Windows Forms, Microsoft Foundation Classes (MFC) o llamadas directas de Win32. Aunque las aplicaciones WPF independientes pueden interoperar con todas estas tecnologías anteriores, como se describe más adelante, ninguna de ellas se permite en un entorno de confianza limitado de XBAP.
• Use código no administrado.

Como se mencionó anteriormente, es posible usar la misma base de código para una aplicación WPF independiente y un XBAP. Para permitir esto, un desarrollador podría usar la compilación condicional, encapsulando cualquier funcionalidad que no se permita en un XBAP dentro de ifdefs. La versión XBAP puede hacer la mayor parte de lo que puede hacer la aplicación independiente, incluida la visualización de documentos, mediante gráficos bidimensionales y tridimensionales, reproducción de vídeo y audio, etc. También puede aprovechar cualquier hardware gráfico disponible en la máquina en la que se ejecuta.

Junto con XBAPs, también es posible mostrar páginas XAML puras directamente en Internet Explorer. Esto puede ser útil para mostrar páginas estáticas en el explorador. Sin embargo, el control de eventos requiere código, lo que significa crear un XBAP.

XBAPs permite a los desarrolladores usar la mayoría de las funcionalidades de WPF en una aplicación de explorador. También permiten un modelo de programación común, usando principalmente el mismo código, para aplicaciones independientes y aplicaciones de explorador. En el caso de las aplicaciones web cuyos clientes tienen como destino plataformas windows más recientes, es probable que los XBAP sean una opción atractiva.

Documentos XPS

Documentos de formato fijo, que en el mundo wpf significa documentos XPS, tienen claramente un rol en las interfaces de usuario. Como se ha descrito anteriormente, WPF proporciona el control DocumentViewer para mostrar documentos XPS. Sin embargo, aunque ciertamente tiene sentido incluir este control en WPF, es menos obvio por qué XPS debe considerarse parte de WPF. Después de todo, la especificación XPS proporciona una manera muy detallada de definir documentos de formato fijo, y los propios documentos se pueden usar de diferentes maneras. Todo lo demás en WPF se centra únicamente en la creación de una interfaz de usuario. Dada su purview más amplia, ¿por qué incluir XPS bajo el paraguas de WPF?

Una gran razón es que los documentos XPS se definen mediante XAML. Solo se usa un pequeño subconjunto de XAML, incluido el elemento Canvas para el diseño, el elemento Glyphs para representar texto y el elemento Path para crear gráficos bidimensionales, pero cada documento XPS es realmente un documento XAML. Dado esto, ver XPS como parte de WPF es factible.

Sin embargo, una de las aplicaciones más importantes de XPS no trata sobre las interfaces de usuario en pantalla. A partir de Windows Vista, XPS se convierte en un formato de impresión nativo para Windows. XPS actúa como un lenguaje de descripción de página, por lo que las impresoras compatibles con XPS pueden representar documentos XPS directamente. Esto permite usar un solo formato de descripción (XAML) desde la pantalla a la impresora. También mejora el mecanismo de impresión basado en GDI existente en Windows, lo que proporciona una mejor compatibilidad con impresión para efectos gráficos complejos, como transparencia y degradados.

Junto con XAML, un documento XPS puede contener datos binarios como imágenes en varios formatos (incluidos JPEG, PNG, TIFF y WMPhoto), datos de fuente, información sobre la estructura del documento, etc. Si es necesario, los documentos XPS también se pueden firmar digitalmente mediante las definiciones de firma XML W3C y los certificados X.509. Lo que contenga, cada documento XPS se almacena en un formato definido por las convenciones de empaquetado abierto (OPC). OPC especifica cómo se relacionan las distintas partes de un documento XML (no solo un documento XPS o XAML), cómo se almacenan en un formato ZIP estándar, etc. Microsoft Office 2007 también usa OPC para sus formatos XML, lo que proporciona cierta commonalidad entre los dos tipos de documentos.

Los usuarios de una aplicación WPF pueden ver documentos XPS a través del control DocumentViewer de WPF, como se mencionó anteriormente. Microsoft también proporciona una aplicación de visor XPS, basada en el control DocumentViewer , como se muestra a continuación. Al igual que el control , esta aplicación permite a los usuarios desplazarse por la página de documentos, buscar texto, etc. Los documentos XPS no son específicos de Windows, por lo que Microsoft planea proporcionar visores XPS para otras plataformas, como Apple Macintosh.

Figura 8. Un visor XPS permite leer un documento XPS una página a la vez.

Para permitir que los desarrolladores trabajen con documentos XPS, WPF proporciona un conjunto de API para crear, cargar y manipularlos. Las aplicaciones WPF también pueden trabajar con documentos en el nivel de OPC, lo que permite el acceso generalizado a documentos XPS, documentos de Office 2007 y otros. Las aplicaciones creadas con Windows Workflow Foundation de Microsoft también pueden usar estas API para crear flujos de trabajo que usen documentos XPS.

Al permitir que las aplicaciones muestren y trabajen con documentos de formato fijo, WPF integra este componente de interfaces de usuario modernas en su enfoque coherente. Al usar este mismo formato para imprimir documentos, Windows Vista permite una mejor coincidencia entre lo que ven las personas en la pantalla y lo que ven en papel. Aunque este tipo de documento probablemente no es lo primero que esperan las personas de una tecnología de interfaz de usuario, el amplio uso de XPS ilustra la gama que una tecnología como WPF puede cubrir.

Herramientas para Windows Presentation Foundation

WPF proporciona una gran cantidad de funcionalidades para los desarrolladores, lo que es algo bueno. Sin embargo, independientemente de lo potente que sea, una tecnología puede ser mucho más útil por buenas herramientas. Para WPF, Microsoft proporciona una herramienta destinada específicamente a desarrolladores y otra dirigida a diseñadores. En esta sección se examinan brevemente ambas.

Para desarrolladores: Visual Studio

Visual Studio es la herramienta insignia de Microsoft para desarrolladores de software. Cuando WPF se publique inicialmente, Microsoft proporcionará extensiones para Visual Studio 2005 que permiten a los desarrolladores crear aplicaciones WPF. La próxima versión de Visual Studio, denominada "Orcas", agregará más, incluida una Designer visual para WPF (que tiene un nombre de código propio: "Sidra"). Con esta herramienta visual, los desarrolladores podrán crear interfaces de WPF gráficamente y, a continuación, hacer que el XAML subyacente se genere automáticamente. Aunque no se ha anunciado ninguna fecha oficial de lanzamiento, Orcas está programada para enviarse en algún momento en 2007.

Para diseñadores: Designer interactiva de expresiones

Como se ha descrito anteriormente, el objetivo principal de WPF es convertir a los diseñadores en ciudadanos de primera clase en la creación de interfaces de usuario. XAML hace posible esto, pero solo si se proporcionan herramientas que permiten a los diseñadores trabajar en este nuevo mundo. Hacia este fin, Microsoft ha creado expression interactive Designer.

Como sugiere la captura de pantalla siguiente, Expression Interactive Designer proporciona algunos aspectos de las herramientas de diseño tradicionales, lo que permite a su usuario trabajar de maneras conocidas. Sin embargo, el Designer se centra exclusivamente en la creación de interfaces para aplicaciones WPF. (De hecho, la interfaz de esta herramienta se crea mediante WPF). Observe, por ejemplo, la lista de controles WPF en la esquina superior derecha de la pantalla siguiente y la escala de tiempo gráfica en la parte inferior. Todos ellos corresponden a las funcionalidades de WPF descritas anteriormente en este documento, y todas están disponibles para que un diseñador de interfaz lo use. Las animaciones se pueden crear gráficamente, como las transformaciones, los efectos y mucho más. El resultado del trabajo del diseñador se expresa en un archivo XAML generado por la herramienta, que luego se puede importar en Visual Studio.

Figura 9. Expression Interactive Designer permite a los diseñadores crear interfaces WPF.[ fig 8]

Expression Interactive Designer es uno de los tres miembros de la familia Expression de Microsoft. Los demás son Expression Web Designer, una herramienta para crear interfaces web basadas en estándares y expression Graphic Designer, una herramienta para crear imágenes de mapa de bits o vectores. De las tres, solo Expression Interactive Designer se centra exclusivamente en la creación de interfaces de usuario para aplicaciones WPF. Un diseñador podría usar bien los demás para crear partes de una interfaz de usuario, quizás las imágenes GIF de la interfaz se crean con expression Graphic Designer, por ejemplo, pero estas herramientas no son específicas de WPF. Y aunque no se han anunciado fechas, todas las herramientas de expresiones están programadas para enviarse algún tiempo después del lanzamiento de WPF.

Windows Presentation Foundation y otras tecnologías de Microsoft

Al igual que la mayoría de las nuevas tecnologías de Microsoft, WPF afecta a otras partes del mundo de Windows. Sin embargo, antes de examinar estos efectos, es importante comprender que la instalación de WPF en un sistema no interrumpe ningún software que use Windows Forms, MFC o cualquier otra tecnología existente. Aunque las nuevas aplicaciones escritas para sistemas que admiten .NET Framework 3.0 probablemente compilarán sus interfaces con WPF, las aplicaciones que usan estas tecnologías anteriores seguirán ejecutándose sin cambios.

Windows Presentation Foundation y Windows Forms

Desde la versión inicial de .NET Framework, muchas aplicaciones se han creado mediante Windows Forms. Incluso con la llegada de WPF, algunas aplicaciones seguirán usando Windows Forms. Por ejemplo, cualquier cosa que se deba ejecutar en sistemas en los que WPF no esté disponible, como versiones anteriores de Windows, probablemente elija Windows Forms para su interfaz de usuario. Las nuevas aplicaciones también pueden elegir Windows Forms en WPF por otras razones, como el amplio conjunto de controles disponibles para Windows Forms.

Incluso las aplicaciones creadas con WPF pueden beneficiarse del uso de algunos aspectos de Windows Forms. Por ejemplo, Windows Forms hoy tiene un conjunto mayor de controles disponibles que WPF. El control DataGridView introducido con la versión 2.0 de .NET Framework no tiene ninguna analogía en WPF y terceros han creado controles Windows Forms para muchos otros usos. Permitir que las aplicaciones WPF usen estos controles existentes pueden tener sentido en algunos casos. Por el contrario, WPF ofrece muchas cosas que Windows Forms no, como gráficos 3D y animaciones. Permitir que una aplicación de Windows Forms existente incorpore partes de la funcionalidad de WPF también tiene sentido.

Ambas cosas son posibles. Una aplicación WPF puede hospedar controles de Windows Forms y una aplicación de Windows Forms puede hospedar controles WPF. Un usuario puede interactuar con diálogos de WPF y Windows Forms diálogos en la misma aplicación, normalmente sin tener en cuenta que hay ninguna diferencia.

Para hospedar Windows Forms controles, una aplicación WPF se basa en el control WindowsFormsHost de WPF. Como su nombre sugiere, este control es capaz de hospedar Windows Forms controles, lo que les permite usarse dentro de la aplicación WPF. También puede hospedar controles ActiveX, lo que proporciona a las aplicaciones WPF acceso a la biblioteca existente grande creada con esta tecnología anterior. De forma similar, una aplicación de Windows Forms usa ElementHost, un control Windows Forms capaz de hospedar controles, paneles y otros elementos de WPF. Las herramientas de cada tecnología también pueden trabajar con software escrito para el otro. Visual Designer de WPF se puede usar para colocar controles Windows Forms, mientras que el diseñador de Windows Forms se puede usar para colocar controles WPF.

El uso de WPF y Windows Forms juntos tiene algunas restricciones. La capa de un control WPF sobre un control de Windows Forms no funcionará, por ejemplo, el control de Windows Forms siempre estará encima. Los efectos de transparencia de WPF tampoco funcionarán bien con los controles de Windows Forms, ni con las transformaciones de WPF. Y dado que los controles WindowsFormsHost y ElementHost requieren plena confianza, una aplicación WPF que las usa no se puede ejecutar como XBAP. Sin embargo, un gran porcentaje de aplicaciones de Windows puede usar WPF y Windows Forms para crear su interfaz de usuario.

Windows Presentation Foundation y Win32/MFC

Antes del lanzamiento de .NET Framework en 2002, los desarrolladores de Windows suelen compilar interfaces de usuario mediante llamadas directas a las API de Win32 o MFC, que proporcionan contenedores de C++ en torno a esas API. En consecuencia, existe un montón de código actualmente con interfaces creadas en este estilo. ¿Qué ocurre con este código en un mundo de WPF?

La respuesta es similar a la situación con Windows Forms. Una vez más, los controles WPF se pueden hospedar en el código Win32/MFC existente y los controles Win32/MFC existentes se pueden hospedar en WPF. (De hecho, las instalaciones para la interoperación entre WPF y Windows Forms se basan realmente en los servicios de interoperabilidad win32/MFC). WPF proporciona la clase HwndHost para permitir el uso de controles Win32/MFC en WPF y la clase HwndSource para permitir que los controles WPF se usen en una aplicación Win32/MFC. Cada clase se asigna entre las dos tecnologías según sea necesario. HwndHost, por ejemplo, hace que el hWnd se use para hacer referencia a un control Win32/MFC como un control WPF. HwndSource hace lo contrario, lo que hace que un control WPF tenga un aspecto similar a un hWnd.

Al igual que con Windows Forms, hay algunas limitaciones en mezclar estos dos mundos. De hecho, dado que la interoperabilidad de Windows Forms se basa en HwndHost y HwndSource, todas las restricciones descritas anteriormente para los controles de Windows Forms, como las limitaciones de la capa y la transparencia, también se aplican aquí. Además, a diferencia de Windows Forms, las aplicaciones que combinan WPF con código Win32/MFC se enfrentan al desafío adicional de interoperar entre el entorno de código administrado de WPF y el mundo no administrado de Win32. Por este motivo y otros motivos, las aplicaciones WPF que usan código Win32/MFC no se pueden ejecutar como XBAP. Sin embargo, como antes, el punto clave es que la aplicación Windows puede usar WPF y Win32/MFC juntos. El uso de WPF no requiere tirar todo el código de interfaz de usuario existente de una aplicación.

Windows Presentation Foundation y Direct3D

Direct3D, parte de la familia de API de DirectX de Microsoft, es una base fundamental para los desarrolladores de Windows que crean gráficos tridimensionales. La llegada de WPF de ninguna manera obsoleta Direct3D. De hecho, como se ha descrito anteriormente, WPF se basa completamente en Direct3D para su representación. Sin embargo, dado que WPF también permite a los desarrolladores crear gráficos 3D, los desarrolladores que trabajan en 3D deben decidir entre los dos.

Sin embargo, la decisión no es especialmente difícil. Direct3D sigue siendo la mejor opción para el desarrollo 3D intensivo, como juegos y aplicaciones técnicas centradas en 3D, por ejemplo, visualización científica de alto nivel. Al menos en su primera versión, WPF no está diseñado para ser una plataforma para estos tipos de software.

WPF hace que los gráficos 3D estén disponibles para un público mucho más amplio y menos especializado, sin embargo. También permite usar gráficos 3D en la Web en un XBAP, integrarlos naturalmente con gráficos bidimensionales, documentos y otros aspectos de la interfaz de usuario de una aplicación, etc. También es posible que una aplicación WPF hospede código Direct3D a través de la clase HwndHost descrita anteriormente. WPF y Direct3D tienen roles distintos y ambos tienen un buen futuro como parte de la plataforma Windows.

Windows Presentation Foundation y AJAX/"Atlas"

Con AJAX, los desarrolladores pueden crear clientes de explorador que tengan mayor capacidad de respuesta a los usuarios. AJAX permite al usuario interactuar con una aplicación sin necesidad de una actualización de página (y, por tanto, un recorrido de ida y vuelta al servidor web) para cada solicitud. Para ello, AJAX se basa en la compatibilidad de un explorador con el objeto XMLHttpRequest , una idea que apareció por primera vez en Internet Explorer 5.0 a finales de la década de 1990. A mediados de la próxima década, el apoyo a XMLHttpRequest se había generalizado en los exploradores y nació el fenómeno AJAX.

Sin embargo, la creación de clientes AJAX no es especialmente sencilla. Para ayudar en el proceso, Microsoft ha creado un conjunto de tecnologías denominadas "Atlas". Atlas es un conjunto de bibliotecas, controles y mucho más para crear aplicaciones AJAX. Consta de una biblioteca de scripts de cliente que puede funcionar en varios exploradores (no solo Internet Explorer) y extensiones del lado servidor para ASP.NET. El objetivo es simplificar la creación de aplicaciones web con clientes de AJAX.

La amplia compatibilidad con el explorador para AJAX hace que sea muy atractivo para los desarrolladores. Sin embargo, aunque AJAX permite crear interfaces mucho más interactivas para los usuarios web, no agrega compatibilidad con una gama más amplia de tipos de contenido. Los gráficos, el vídeo, las animaciones y otros estilos de interacción más modernos no son compatibles solo con AJAX. En el caso de los clientes que admiten WPF, es probable que las aplicaciones que lo necesiten se escriban en su lugar como XBAP.

Windows Presentation Foundation y "WPF/E"

Con XBAPs, una aplicación web puede proporcionar a sus usuarios una gran fracción de las funcionalidades de WPF. Sin embargo, XBAPs requiere que WPF se instale en el equipo cliente, lo que limita su aplicabilidad. ¿Qué ocurre con las aplicaciones web que necesitan presentar interfaces modernas, pero también deben ser accesibles desde Macintosh y otros sistemas que no admiten WPF?

Una próxima tecnología, denominada "WPF/E", está pensada para solucionar este problema. WPF/E ( "E" significa "En todas partes"), proporcionará un subconjunto de funcionalidades de WPF en una gama de plataformas cliente, incluidos Macintosh, dispositivos más pequeños y otros, y en diversos exploradores web, como Internet Explorer, Firefox y Netscape. Este subconjunto incluye gráficos bidimensionales, imágenes, vídeo, animación y texto. Sin embargo, parte de lo que puede hacer un XBAP se omite de WPF/E, incluida la compatibilidad con gráficos tridimensionales, documentos y aceleración de hardware.

Para crear una aplicación WPF/E, un desarrollador puede usar JavaScript. WPF/E también incluirá un subconjunto multiplataforma de .NET Framework, lo que permite el desarrollo en C# y Visual Basic. WPF/E no forma parte de .NET Framework 3.0, por lo que no está programado que se publique hasta algún momento en 2007. Una vez que esté disponible, los creadores de aplicaciones web tendrán otra opción, una que proporciona una gama de funciones en una gama de plataformas, para compilar clientes.

Conclusión

Las interfaces de usuario son una parte fundamentalmente importante de la mayoría de las aplicaciones. Hacer que esas interfaces sean lo más eficaces posible pueden tener beneficios medibles para las personas y las organizaciones que dependen de ellas. El objetivo principal de WPF es ayudar a los desarrolladores a proporcionar estas ventajas, por lo que para cualquier persona que cree o use aplicaciones de Windows, WPF es una gran noticia.

Al proporcionar una plataforma unificada para interfaces de usuario modernas, ayudando a los diseñadores a participar en la creación de esas interfaces y permitiendo un modelo de programación común para aplicaciones independientes y de explorador, WPF tiene como objetivo mejorar significativamente la experiencia del usuario de Windows. Algunas de las tecnologías que suplantaban tenían una ejecución de veinte años como base para las interfaces de usuario de Windows. La intención de WPF es sentar la base para los próximos veinte años.

 

Acerca del autor

David Chappell es director de Chappell & Associates (www.davidchappell.com) en San Francisco, California. A través de su discurso, escritura y consultoría, ayuda a los profesionales tecnológicos de todo el mundo a comprender, usar y tomar mejores decisiones sobre el software empresarial.