El Blog de Fox » WPF

Reseña: WPF Unleashed

admin — Mon, 10 May 2010 13:33:22 +0000

¿Te cuesta entender los artículos de WPF del blog? ¿Crees que necesitas aprender lo básico de WPF primero?

Para eso está “Windows Presentation Foundation Unleashed” de Sams.

Windows Presentation Foundation Unleashed (WPF-U a partir de ahora) ha sido aclamado como el mejor libro de WPF que había en el mercado. Ya han pasado 4 años del lanzamiento (2006) pero sigue siendo igual de util a dia de hoy.

Nada mas abrir el libro, te enamoras de el, pues está a todo color, lleno de imagenes con colores vivos, el código tal y como lo verás en Visual Studio y lleno de recuadros con información. Precioso sin duda.

Ya hablando del libro en si, está muy bien como la gente aclama aunque yo le veo algunos fallitos.

Tiene un comienzo muy muy duro, los 3 primeros temas volverán loco a cualquiera que se quiera meter con WPF, ya que te cuenta TODO lo que ofrece WPF y claro, empiezas a leer sobre Dependency properties, Commands, Routed events, Markup extensions y claro lo más lógico es decir algo en plan: ¿Pero que carajo es todo esto? Si apenas hemos visto 3 líneas de XAML…

La verdad, esta primera parte es un trago complicado, pero ya luego empieza a explicar las cosas paso a paso y empieza lo bueno.

Tiene una buena parte explicando los controles que WPF nos ofrece, como cambiarles el tamaño, aplicarles transformaciones tales como rotaciones… Sigue explicandos como estructurar una aplicación visualmente usando los Layouts que WPF nos pone a nuestra disposición. Incluso nos dice como hacer ventanas tipo Vista o Win 7, con sus bordes de cristal y tal.

Despues de la introducción a WPF ya se mete a temas más avanzados como los Data Bindings, estilos, temas…

Luego continua hablandonos de graficos en 2D y 3D, animaciones, meter audio y video en nuestras aplicaciones…

Termina hablandonos un poco de como funciona la interoperabilidad con Win32, Windows Forms y ActiveX además de darnos una pequeña explicación de qué es un control de usuario y como crear controles personalizados (de una forma muy muy básica).

En resumen, es un libro bueno, toca casi todo lo que WPF ofrece, aunque algunos temas pecan de ser simplones y otros quizás menos interesantes los explica a fondo…

El problema que yo le veo al libro, es que se escribió cuando WPF era bastante nuevo, y a dia de hoy algunas de las cosas que el libro explica pues ya no se hacen de esa forma o incluso he visto un par de cosas que ya no eran ni válidas.

Aún así sigue siendo una de las mejores opciones para aprender WPF, hay alternativas, pero dan sueño.

Cosas positivas:

Buenísisisima presentación
Te muestra casi todo lo que WPF ofrece
Muchos de los temas están muy bien explicados
La parte de interoperabilidad está bastante bien

Cosas negativas:

Algunas cosas que explica ya no son validas
Tiene algún fallito que otro
La introducción da miedo de verdad
Algun tema es bastante simplón y hasta sobraría

Yo le doy un 8 a este libro.

Como nota final, yo para los que se quieren iniciar en WPF, aparte de leer mi blog a diario, les recomiendo primero leer el libro WPF in 24 Hours y luego leer WPF-U.

Una pena que ambos estén solo en inglés, pero es lo que tiene la informática y concretamente WPF que no tiene tanto impacto (por ahora) en el mundo hispano.

Hasta otra.

Truco: Forzando nuestras apps con el estilo de Vista / 7

admin — Fri, 26 Mar 2010 12:16:03 +0000

¿Habéis creado alguna vez una aplicación en vuestro Windows Vista / 7 y al probarlo en un Windows XP habéis visto que no se ve igual?

Si hacéis alguna aplicación en la que os ponéis a cambiar un poco el apartado visual, comprobaréis que en XP no se ve igual ni por asomo.

Por ejemplo, imaginad que tenéis una ventana y esta ventana tiene un Border y lo quereis poner azul. Creais un estilo para que los bordes sean azules.

Además de eso, la ventana tiene un TabControl con sus pestañas ahi majas.

Nada, ejecutáis la aplicación, sale la ventana y de puta madre, los Border salen en azul y el resto sigue bien, ya que el estilo es solo para dicho control.

Ahora se lo pasais a algun colega que tiene XP y os dice… macho, vaya pedazo de birria de programa que has hecho… Y tu… No está tan mal…

Le decís que os pase una screenshot y sorpresa, ves recuadros azules por todos lados, las pestañas del TabControl tienen 1-2 recuadros azules ahi por la cara (Es porque dichas pestañas estan compuesta por un Border entre otras cosas).

No solo eso, los colores pueden aparecer en otra tonalidad, si usais sombras ya podeis despediros de ellas…

En resumen, cualquier floritura extra que le pongáis, en XP no se va a ver igual ni por asomo.

Pero hay una solución….

¡Forzar a la aplicación a usar el estilo de Vista / 7 aunque sea en XP!

¿Cómo? En dos simples pasos:

Añadimos una referencia a nuestra aplicación:

PresentationFramework.Aero

Vamos, es el .dll para usar el aspecto gráfico de Vista / 7. Este .dll viene por defecto, no hace falta bajar nada.

Ahora en nuestro App.xaml, tenemos que añadir un diccionario de recursos nuevo. Si no os acordáis o no lo sabeis, la forma de meter diccionarios en el App.xaml es fusionando todos los diccionarios que queramos de ésta forma:

En este caso, tenemos que meter un diccionario que existe dentro de PresentationFramework.Aero:

o si usamos WPF 4:

Con esto forzaremos a nuestra aplicación a usar el tema Aero (podemos cambiarlo por otro si queremos) aunque nuestro SO no esté usando dicho tema actualmente.

Asunto solucionado.

Hasta otra

MVVM Light: Localización

admin — Thu, 25 Mar 2010 14:26:17 +0000

Hola,

Aquí está el último artículo de esta serie sobre MVVM Light

Realmente la localización no forma parte de MVVM Light en sí, es algo que ya existía de antes y que sirve para todo tipo de aplicaciones.

Pero vamos a aprovechar esta serie para meter aquí el artículo y así podamos hacer aplicaciones con buena arquitectura y localizados.

Pero antes que nada….

¿Qué es la localización?

Básicamente es el proceso de adaptar un software a un idioma concreto, por ejemplo, traduciendo sus textos y esto es precisamente lo que vamos a aprender aquí.

¿Cómo se hace eso? Pues el texto está escrito en el xaml y en los .cs…

Es muy fácil como veremos a continuación:

Para empezar, abrimos el proyecto del artículo de comandos, que como recordaréis lo dejamos en inglés a conciencia.

Ejecutamos el proyecto, rellenamos los campos y el resultado es como este:

Todo perfectamente en inglés.

¿Cual es el primer paso a la hora de localizar una aplicación?

Colocar todas las cadenas en un recurso aparte y nunca escribirlas directamente en el código.

Para ello creamos un nueva carpeta en nuestro proyecto llamada Resources, dentro creamos un nuevo item del tipo Resources File (O ficheros de recursos como me imagino que será en castellano).

A este fichero le vamos a poner de nombre Strings.resx. Si lo abrimos, vemos que tenemos 3 columnas en las que rellenar datos. En la primera va el identificador de la cadena, en la segunda irá la cadena en sí y en la tercera podemos poner un comentario que ayude a aquella persona que le toque traducir a saber en qué contexto estaba esa palabra (opcional).

Por ejemplo, imaginad que tenemos la siguiente cadena: “Choose Color” y la tenemos que meter en el fichero Strings.resx, pues básicamente sería algo del tipo:

ChooseColor – Choose Color – Color Picker window

O sea: identificador – cadena – comentario

Bueno, ya que sabemos como rellenar el fichero, voy a colocar la lista de todas las cadenas que estamos usando en la aplicación:

InsertName – Insert your name:
InsertAge – Insert your age:
Accept – Accept
Count – Count
Reset – Reset
Greeting – Hello, my name is {0} and Im {1} years old.
CountMessage – Greeting has {0} characters.

Como véis, hemos colocado aquí todas las cadenas tanto de los .xaml como de los .cs

NOTA: Solo se han de colocar aquellas cadenas que van a ser mostradas por pantalla (pues son las que nos interesan), aquellas cadenas como las de los RaisePropertyChanged pues no hay que meterlas ahí.

MUY IMPORTANTE: En la ventana de Strings.resx donde metéis todos los datos, arriba hay un combobox que pone: Modificador de acceso, tenéis que cambiarlo de internal a public. Además vais a tener que ir al fichero Strings.Designer.cs y ahi modificar el constructor cambiandole el modificador de acceso de internal a public. Además, tendrás que hacer estas 2 cosas cada vez que se guarde el fichero (por ejemplo al meter una nueva entrada). Esto es MUY importante y nada más que por esto merece la pena leer el tutorial.

Bien, este fichero contiene el idioma por defecto de la aplicación, esto quiere decir que si abrimos el programa en un windows ruso y no lo tenemos localizado al ruso, usará el lenguaje por defecto, en este caso, inglés.

Ahora bien, necesitamos quitar todas las cadenas de nuestro programa y sustituirlas por las que están en este fichero. ¿Cómo?

Para empezar necesitamos poder acceder a dicho recurso de forma global en todos los .xaml, y ya sabemos que para eso todo lo que definamos en App.xaml será global para todo fichero .xaml

Así que vamos a App.xaml y colocamos:

Un nuevo namespace:

xmlns:res="clr-namespace:EjemploMVVML.Resources"

Y ahora creamos una instancia del recurso:

Ésta linea la colocamos junto a la instancia del ViewModelLocator

Bien, ya que tenemos acceso a Strings en cualquier .xaml, vamos a empezar a sustituir las viejas cadenas de esta forma:

{Binding Source={StaticResource LocStrings}, Path=Identificador}

Por ejemplo, el primer label, el de insertar la edad:

Simplemente hemos sustituido la cadena escrita a mano por la que tenemos en Strings.resx

Ahora tienes que hacerlo con las demás cadenas que están en el .xaml (por simplificar el tamaño del tutorial no voy a pegar aqui el código, pero vamos, es algo mecánico.

Y bueno suponiendo que tenemos el .xaml listo con todo modificado, vamos a explicar como hacer esto mismo pero en C# para las cadenas de nuestras clases:

string cadena = Resources.Strings.Identificador;

¿Nada complicado verdad?

Así que nuestras dos propiedades del MainViewModel quedarían así:

Greeting = string.Format(Resources.Strings.Greeting,
	APerson.Name, APerson.Age);

CountMessage = string.Format(Resources.Strings.CountMessage, characters);

Ala, ya tenemos todo listo.

Normalmente cuando creamos una aplicación que soportará localización, metemos directamente todas las cadenas al Strings.resx para ahorrarnos trabajo

Bueno, ya tenemos todo listo. Así que lo que queda es añadir un nuevo fichero de recursos por cada lenguaje que vayamos a meter, cada fichero tendrá un nombre del tipo:

Strings.xx-yy.resx

Por ejemplo:

Strings.es-es.resx
Strings.en-us.resx
Strings.de-de.resx

Para nuestro ejemplo, creamos un fichero de recursos llamado Strings.es-es.resx junto a Strings.resx.

Este fichero es igual al anterior y se usa igual que el anterior. En este caso, la primera columna llevará los identificadores (los mismos que antes) y en la segunda la cadena pero ya en el idioma que estamos localizando:

InsertName – Introduce tu nombre:
InsertAge – Introduce tu edad:
Accept – Aceptar
Count – Contar
Reset – Reiniciar
Greeting – Hola, mi nombre es {0} y tengo {1} años.
CountMessage – El saludo tiene {0} caracteres.

Nada más, ahora si abrimos nuestro programa…

Nos sale totalmente en castellano, puesto que tenemos nuestro sistema operativo en castellano.

Así que sólo quedaría añadir un fichero por cada idioma que queramos soportar y nada más.

Os adjunto el proyecto (.NET 4):

EjemploMVVML.zip

Con esto doy por concluida la serie de artículos sobre Iniciación a MVVM Light.

Como ejercicio final os recomendaría echarle un ojo por encima a mi aplicación Apunta Notas ya que está escrita usando todo lo que aquí hemos aprendido y quizá os pueda solucionar muchas de las dudas que tengáis, aunque podéis preguntar en cualquier artículo las dudas que os hayan quedado.

Apunta Notas

Hasta la próxima.

MVVM Light: Messenger

admin — Wed, 24 Mar 2010 22:32:28 +0000

Y aquí estamos con la tercera parte de este artículo sobre MVVM Light.

En esta ocasión hablaremos sobre Messenger y no, no es el que usas para chatear con tus colegas, aunque la idea es parecida.

Antes de explicar en qué consiste lo de Messenger vamos a presentar ~~al concursante~~ el ejemplo.

El ejemplo es parecido al del anterior artículo, pero le hemos añadido una vuelta de tuerca más para mostraros otros conceptos nuevos.

El ejemplo se mantiene simple para no liaros con cosas que no tienen que ver con lo que vamos a explicar hoy.

Creamos una nueva aplicación MVVM Light para WPF, y añadimos la siguiente clase al modelo:

using System.ComponentModel;

namespace EjemploMessenger.Model
{
    public class Persona : INotifyPropertyChanged
    {
        private string _nombre;
        private int _edad;

        public Persona()
        {

        }

        public string Nombre
        {
            get { return _nombre; }
            set
            {
                _nombre = value;
                RaisePropertyChanged("Nombre");
            }
        }

        public int Edad
        {
            get { return _edad; }
            set
            {
                _edad = value;
                RaisePropertyChanged("Edad");
            }
        }

        #region INotifyPropertyChanged Members

        public event PropertyChangedEventHandler PropertyChanged;

        private void RaisePropertyChanged(string propertyName)
        {
            if (PropertyChanged != null)
            {
                PropertyChanged(
                    this,
                    new PropertyChangedEventArgs(propertyName)
                    );
            }
        }

        #endregion
    }
}

Hemos cogido prestada la misma clase que hemos usado en el anterior ejemplo, aunque ya están puesto las variables en castellano pues aunque sea buena practica hacerlo en inglés, este blog está en castellano y muchos no saben inglés.

La ventana quedaría así:

Ahora necesitamos crear otra ventana con su ViewModel. Creamos un ViewModel llamado EdadViewModel (Para ello al darle a añadir, nos saldrá la opcion de crear un nuevo MvvmViewModel directamente, así que seleccionamos esta opción). Luego creamos una ventana dándole a la opción MvvmView. A esta ventana le damos el nombre de EdadWindow.xaml y le añadimos el siguiente código:

Cada vez que añadamos un nuevo ViewModel a nuestro proyecto, deberemos añadir la referencia al ViewModelLocator, para ello abrimos la clase ViewModelLocator.cs y le damos a añadir nuevo snippet de código (o lo escribes a mano si quieres) y añades un ViewModelLocator property, luego lo modificamos para que quede así:

private static EdadViewModel _edad;

/// 
/// Gets the ViewModelPropertyName property.
/// 
public static EdadViewModel EdadStatic
{
	get
	{
		if (_edad == null)
		{
			CreateEdad();
		}

		return _edad;
	}
}

/// 
/// Gets the ViewModelPropertyName property.
/// 
[System.Diagnostics.CodeAnalysis.SuppressMessage("Microsoft.Performance",
	"CA1822:MarkMembersAsStatic",
	Justification = "This non-static member is needed for data binding purposes.")]
public EdadViewModel Edad
{
	get
	{
		return EdadStatic;
	}
}

/// 
/// Provides a deterministic way to delete the ViewModelPropertyName property.
/// 
public static void ClearEdad()
{
	_edad.Cleanup();
	_edad = null;
}

/// 
/// Provides a deterministic way to create the ViewModelPropertyName property.
/// 
public static void CreateEdad()
{
	if (_edad == null)
	{
		_edad = new EdadViewModel();
	}
}

Básicamente por cada ViewModel en el proyecto, necesitamos una referencia de éste en el ViewModelLocator, cada referencia consta de una instancia estática del ViewModel, una propiedad estática y otra normal de ésta, y un método para hacer una limpieza (como recordaréis, al crear un ViewModel, éste nos dá la posibilidad de hacer una limpieza una vez que deje de ser útil.).

Bueno, ya tenemos creado la primera parte del esqueleto de la aplicación, ahora sólo nos queda añadir código a cada ViewModel.

Antes de eso, quiero explicar el proposito de este ejemplo.

El ejemplo en sí es el mismo que el anterior, con tu nombre y edad forma un saludo. En este caso, no puedes introducir la edad directamente en la casilla, sino que tienes que introducirla en otra ventana aparte.

Antes de nada vamos a instanciar la clase Persona y vamos a crear la propiedad Saludo:

private Persona _unaPersona;
private string _saludo;

public Persona UnaPersona
{
	get { return _unaPersona; }
	set
	{
		_unaPersona = value;
		RaisePropertyChanged("UnaPersona");
	}
}

public string Saludo
{
	get { return _saludo; }
	set
	{
		_saludo = value;
		RaisePropertyChanged("Saludo");
	}
}

public MainViewModel()
{
	_unaPersona = new Persona();
}

Ahora, empezamos con el botón que nos permitirá usar la otra ventana. Para ello creemos un ~~evento~~ comando que haga precisamente eso:

public RelayCommand RecogerEdadCommand { get; private set;}

RecogerEdadCommand = new RelayCommand(RecogerEdad);

private void RecogerEdad()
{
	var edad = new EdadWindow();
	edad.ShowDialog();
}

Y bindeamos el botón al comando:

Con esto ya se abre la ventana, ¿Nada nuevo verdad? Simplemente instanciamos la ventana y la mostramos como un dialogo modal.

Vamos a escribir el código necesario en el EdadViewModel para recoger lo que escribamos y calcular nuestra edad, además crearemos el comando del botón y lo bindearemos, escribiré todo el código para simplificar, total, no es nada nuevo:

EdadViewModel

using System;
using GalaSoft.MvvmLight;
using GalaSoft.MvvmLight.Command;

namespace EjemploMessenger.ViewModel
{
    public class EdadViewModel : ViewModelBase
    {
        public int Dia { get; set; }
        public int Mes { get; set; }
        public int Año { get; set; }

        public RelayCommand CalcularEdadCommand { get; private set; }

        public EdadViewModel()
        {
            CalcularEdadCommand = new RelayCommand(CalcularEdad);
        }

        private void CalcularEdad()
        {
            var añoActual = DateTime.Now.Year;
            var mesActual = DateTime.Now.Month;

            var edad = añoActual - Año;

            if (Mes > mesActual)
                edad += 1;
        }
    }
}

Nada que deba sorprendernos.

EdadWindow.xaml

Aqui el código de la ventana, no he puesto ninguna validación (¿Material para otro artículo? , asi que vamos a suponer que introducimos los datos correctos). Además de eso, tenemos los bindings puestos y … ¿El botón tiene un comando y un evento a la vez? Sí. Puedes tener ambas cosas a la vez.

En este caso, necesito crear un evento en el botón para que haga algo relacionado con la ventana en sí y no con datos (O sea, trabajo para el code-behind en este caso). Lo lógico es que cerremos la ventana a la hora de hacer click, pero claro, no podemos hacer eso desde el ViewModel, así que necesitamos hacerlo en el code-behind. Así que el comando calcula la edad y el evento cierra la ventana.

private void OnAceptar(object sender, RoutedEventArgs e)
{
	Close();
}

Guay del paraguay, pero la edad está en EdadViewModel y la necesitamos en la instancia de Persona que está en MainViewModel. ¿Cómo la pasamos alli? ¿Cómo podemos hacer que MainViewModel obtenga la edad?

La solución más típica era la de crear un método en el code-behind de la ventana el cual nos devuelve lo que esa ventana a generado o directamente acceder a las propiedades.

Esta solución se ha usado mucho siempre, pero tiene un gran problema y es precisamente el que MVVM intenta resolver; el acople entre clases.

Si el método que abre la ventana necesita también saber como acceder a los datos que ésta genera, ya esas dos clases dependerían mucho la una de la otra.

Como solución a esto (y a otros muchos casos de este estilo) nació la clase Messenger. Ésta clase sirve para enviar mensajes de un lado a otro en una aplicación, de forma totalmente desacoplada.

La idea es que un objeto se registra para recibir mensajes de cierto tipo pero no sabe quien lo envia, simplemente espera dichos mensajes y nada más. Con esto conseguimos el buscado desacople.

Como se suele decir: Más vale un ejemplo que mil palabras ( ¿O eran imágenes? ):

¿Qué necesita recibir el MainViewModel para funcionar?, ¿La edad, no? ¿Qué tipo de variable es la edad? Un int.

Así que vamos a registrar mensajes que vengan con un int como parámetro. ¿Cómo se registra una clase para recibir mensajes?

Se usa el método estático Register de la clase Messenger:

void Register(object recipiente, Action action);

El primer parámetro es el objeto el cual se está registrando al mensaje, y el segundo es el método que se ejecutará cuando se reciba un mensaje

Vamos a registrar nuestro mensaje en el MainViewModel para que éste quede a la escucha de dichos mensajes, para ello escribimos en el constructor:

Messenger.Default.Register(this, edad => UnaPersona.Edad = edad);

Decimos que queremos escuchar todos los mensajes que traigan un int y que cuando recibamos uno, asignará el int que traiga consigo a la propiedad Edad de UnaPersona.

¿Fácil verdad?

Ahora falta que alguien los envié, y en este caso sería EdadViewModel. Para enviar mensajes se usa el siguiente método estático de la clase Messenger:

void Send(T message);

Simplemente el tipo de mensaje a enviar y el mensaje en sí.

Así que dentro del método CalcularEdad después del if ponemos:

Messenger.Default.Send(edad);

No debe sorprenderos, es bastante sencillo, enviamos edad a través de un mensaje.

Eso sí, este mensaje le llegara a TODOS los que estén escuchando mensajes que vengan con un int. En este caso da igual, pero si tenemos otras clases esperando mensajes también, pues puede liar. Así que tenemos acceso a otro tipo de método:

void Send(TMessage message);

Con ese método podemos especificar a quien queremos enviarle este mensaje, así que vamos a modificar nuestro ejemplo:

Messenger.Default.Send(edad);

Mejor

La clase Messenger es mucho más que eso, es capaz de intercambiar varios tipos de mensajes, normalmente para cosas más especificas. Vamos a mostrar otro tipo más de mensaje.

Antes de hacerlo, conviene pensar que quizá el ejemplo que ya he dado quizá no sea la mejor solución al 100%. La ventana de la Edad puede ser una ventana genérica usada por muchas partes de tu software, y si el mensaje que envía ya va dirigido a alguien en concreto, nos jodería el invento. Sin embargo, la clase que usa esa supuesta ventana genérica suele usar esa y no intercambiar con 20 más, quiero decir, debería quizá la clase que está usando dicha ventana ser la que especifique claramente a quien va a usar y dicha ventana ser genérica para que cualquiera pueda usarla y cualquiera pueda recibir sus mensajes.

¿Cómo hacemos eso?

A bote pronto podemos usar otro tipo de mensaje, NotificationMessageAction

Éste tipo de mensaje envía una notificacion y además espera que la clase que lo reciba le conteste.

Probemos:

En EdadViewModel registramos el mensaje, en este caso es un poco más complejo:

private NotificationMessageAction _message;

en el constructor:

Messenger.Default.Register>(
		this,
		m => _message = m);

y dentro de CalcularEdad:

_message.Execute(edad);

El mensaje del tipo NotificationMessageAction nos ofrece una forma de contestar a dicho mensaje, o sea, ejecutar el callback. Para ello necesitamos usar el método Execute de dicho mensaje, necesitamos hacer una copia del mensaje para poder acceder a dicho mensaje desde cualquier sitio de la clase.

Una vez tengamos el mensaje registrado y copiado, simplemente tenemos que ejecutar el método Execute para devolver el mensaje, en este caso, la edad.

Ahora bien, en la clase MainViewModel necesitamos enviar dicho mensaje y manejar el callback:

var edad = new EdadWindow();
Messenger.Default.Send(new NotificationMessageAction("Dame la edad", laEdad => UnaPersona.Edad = laEdad));
edad.ShowDialog();

Como veis, enviamos un nuevo mensaje del tipo NotificationMessageAction. Entre otras sobrecargas del método, tenemos una que recibe como primer parámetro el mensaje que queramos enviar (en este caso, la clase que recibe el mensaje no va a usar dicho mensaje, asi que le pasamos cualquier cosa) y como segundo parámetro recibe un delegado del tipo Action, usamos una lambda para que nos almacene la respuesta UnaPersona.Edad.

Así que la idea es: Enviamos mensaje > el recipiente lo recibe y almacena > cuando tiene la respuesta la envia > el que envió el mensaje recibe respuesta y hace algo con ella.

Bueno, con este tipo de mensaje conseguimos que EdadWindow pueda ser usada por otras muchas clases ya que ésta no sabe en ningun momento quien la usa, simplemente envia la edad como respuesta y bueno le da igual quien lo reciba o que haga con ello jeje.

Y bueno, se nos olvidaba que el programa tiene que enviar un saludo… Ya tenemos el nombre y podemos conseguir la edad, así que vamos a registrar el comando para el saludo, el cual es exactamente igual que el comando del articulo anterior:

public RelayCommand AceptarCommand { get; private set; }
[/csharp

[csharp]
AceptarCommand = new RelayCommand(Aceptar);

private void Aceptar()
{
	Saludo = string.Format("Hola, mi nombre es {0} y tengo {1} años.",
		UnaPersona.Nombre, UnaPersona.Edad);
}

Para terminar, os dejo la lista de mensajes que teneis y una descripción de ellos:

MessageBase: Es el mensaje simple, puede llevar informacion opcional del que envía el mensaje.
GenericMessage: Un mensaje simple que lleva una propiedad del tipo T.
NotificationMessage: Usado para enviar una notificación (un string) hacia un recipiente. Por ejemplo podemos guardar una lista de notificaciones en una clase y enviarlas a un recipiente.
NotificationMessage: El mismo mensaje que el anterior pero enviado además una propiedad del tipo T.
NotificationMessageAction: Permite enviar un mensaje a un recipiente y le permite a dicho recipiente contestar al mensaje.
NotificationMessageAction: Lo mismo que el anterior pero enviando además una propiedad del tipo T.
DialogMessage: Usado para pedirle a un recipiente (normalmente a una vista) que muestre un dialogo y notificar el resultado al que envió dicho mensaje. El recipiente puede mostrar cómo mostrar dicho dialogo, por ejemplo usando un MessageBox o un popup personalizado.

PropertyChangedMessage: Usado notificar a todo el mundo que una propiedad a cambiado (en la clase que envia dicho mensaje). Es lo mismo que usar el evento PropertyChanged solo que esto lo hace de una más simple.

Bueno, y dicho esto dejo por finalizado este artículo, adjunto el proyecto también:

EjemploMessenger.zip

Hasta la próxima

MVVM Light: Comandos

admin — Sun, 21 Mar 2010 18:44:16 +0000

Aquí vamos con la segunda parte del tutorial.

Para este tutorial vamos a crear un ejemplito muy muy simple pero que nos ayudará a entender los conceptos básicos que es lo que realmente buscamos.

Para empezar vamos a ir a la página de MVVM Light y bajarnos la última versión (la versión 3 a dia de hoy)

Página de MVVM Light

Que no os asuste la instalación, simplemente teneis que bajar los binarios y los templates para la versión de visual studio que estéis usando. Como extra también podéis bajar los snippets lo cual recomiendo.

Cuando bajeis los 3 ficheros, lo descomprimís y solo es copiarlo donde corresponde, nada dificil (Si teneis problemas dejadme un comentario).

Una vez tienes MVVM Light instalado vamos a crear una nueva aplicación MVVM Light para WPF (Para Silverlight o Windows Phone 7 sería lo mismo realmente).

El template de MVVM Light es bastante bastante completito, nos vienen los directorios que tenemos que usar (con la excepción de Views aunque no sé por qué) y además nos crea ya una ventana con su ViewModel asociado. Además de un diccionario de estilos (MainSkin.xaml) en el cual podemos meter nuestros estilos de la ventana.

Por último, nos crea un ViewModelLocator el cual instancia en el App.xaml. ¿Para qué sirve esto?

ViewModelLocator es el encargado de instanciar y mantener una referencia de cada ViewModel que existe en nuestra aplicación. Lo cual nos da ciertas ventajas, entre ellas poder asignar el DataContext de cada View en el xaml y no mediante código, lo cual nos permitirá diseñar nuestra aplicación en tiempo de diseño sin hacer ninguna floritura extra.

Ya en la próxima parte os explicaré como añadir más ViewModels al ViewModelLocator así que por ahora vamos a ignorarlo y seguir adelante.

Empezamos borrando el MainSkin.xaml puesto que no lo vamos a usar en este simple ejemplo.

Creamos en el modelo una clase llamada “Person” y le pones este código:

using System.ComponentModel;

namespace EjemploMVVML.Model
{
    public class Person : INotifyPropertyChanged
    {
        private string _name;
        private int _age;

        public Person()
        {

        }

        public string Name
        {
            get { return _name; }
            set
            {
                _name = value;
                RaisePropertyChanged("Name");
            }
        }

        public int Age
        {
            get { return _age; }
            set
            {
                _age = value;
                RaisePropertyChanged("Age");
            }
        }

        #region INotifyPropertyChanged Members

        public event PropertyChangedEventHandler PropertyChanged;

        private void RaisePropertyChanged(string propertyName)
        {
            if (PropertyChanged != null)
            {
                PropertyChanged(
                    this,
                    new PropertyChangedEventArgs(propertyName)
                    );
            }
        }

        #endregion
    }
}

Como veis está en inglés puesto que luego vamos a usar este ejemplo en el artículo de localización, además es una MUY buena practica escribir todo el código en inglés (variables, comentarios, clases, todo).

Esta clase implementa INotifyPropertyChanged puesto que el modelo necesita notificar sus cambios de cara al DataBinding.

Normalmente yo suelo crear una clase llamada Notifier la cual implementa esta interfaz y luego heredo el modelo hereda de esta clase (siempre que no necesitemos heredar del modelo de otra clase y tengamos que implementar esta interfaz a mano como en el ejemplo).

Vamonos con la interfaz, os dejo el código, algo en plan rápido y guarrete ya que este artículo no tiene nada que ver con interfaces

Lo importante de aquí, es ver como se ha definido el DataContext en la ventana. Hemos cogido la referencia del ViewModel que nos interesa (el MainViewModel) desde el ViewModelLocator. ¿Chulo verdad?

Ahora vamonos al MainViewModel, uhm, ya tiene código por defecto… (Le he quitado algun comentario para simplificar el ejemplo):

using GalaSoft.MvvmLight;

namespace EjemploMVVML.ViewModel
{
    public class MainViewModel : ViewModelBase
    {
        public string Welcome
        {
            get
            {
                return "Welcome to MVVM Light";
            }
        }

        public MainViewModel()
        {
            if (IsInDesignMode)
            {
                // Code runs in Blend --> create design time data.
            }
            else
            {
                // Code runs "for real"
            }
        }

        ////public override void Cleanup()
        ////{
        ////    // Clean up if needed

        ////    base.Cleanup();
        ////}
    }
}

Cada ViewModel heredará de ViewModelBase el cual nos provee de ciertos helpers que nos facilitarán la vida. Por ejemplo dicho ViewModelBase implementa ya el INotifyPropertyChanged y además nos provee de un método en el cual podemos hacer limpieza en caso de que sea necesaria (Una especie de destructor).

Además tenemos una propiedad bastante util, IsInDesignMode y ya el constructor viene listo para usarlo. Simplemente podemos colocar código dentro de IsInDesignMode para hacer uso del “Design-time DataContext” (Revisar el artículo si quereis saber qué es esto) y luego el código real dentro del else.

Como ya sabemos usar el Design-time DataContext y no tiene nada que ver con MVVM Light, vamos a borrar eso y escribir directamente el código real.

Vamos a borrar el método Cleanup y borrar la propiedad “Welcome” y dejar solo el costructor vacío.

Para empezar vamos a crear una instancia de la clase Person.

Normalmente el instanciar una clase que va a ser expuesta a la vista necesita 3 pasos:

Crear la instancia:

private Person _aPerson;

Instanciarla en el constructor:

_aPerson = new Person();

y crearle su propiedad con notificación de cambios:

public Person APerson
{
    get { return _aPerson; }
    set
    {
        _aPerson = value;
        RaisePropertyChanged("APerson");
    }
}

Ya tenemos lista la instancia de Person para ser bindeada por la vista.

Vamos a bindear las 2 cajas (las de nombre y edad) a sus respectivas propiedades de la instancia de Person:

Nada nuevo aquí, solo hacemos los binding como estamos acostumbrados a hacer.

También vamos a necesitar bindear el tercer TextBox el cual contendrá un pequeño saludo.

Para ello creamos una propiedad en el ViewModel:

private string _greeting = string.Empty;

public string Greeting
{
    get { return _greeting; }
    set
    {
        _greeting = value;
        RaisePropertyChanged("Greeting");
    }
}

y bindeamos la tercera caja:

Ahora, si ejecutamos la aplicación…

Vemos que no hace nada, los botones no responden (¡Sorpresa!)

¿Cómo podemos solucionar esto?

Ah claro, creamos un evento por cada botón y asunto solucionado.

Pero… Habíamos dicho que todo el trabajo referente a datos se hacía en el ViewModel y no en el Code-Behind de la vista… Bueno, delegamos la acción al ViewModel desde el Code-Behind y ya está.

Vale, funciona, pero… ¿No es un poco guarrete esto que proponemos? Sí, sin duda.

WPF y Silverlight ofrecen algo más especializado para estas cosas que los propios eventos, ese algo se llama “Commands” o “Comandos” en castellano.

¿Qué ofrecen estos _Commands_ como ventaja frente a los eventos? Muchas. Las iremos viendo a lo largo del resto del artículo.

Para empezar, los comandos no se definen en el Code-Behind, sino directamente en el DataContext, que en nuestro caso es en el MainViewModel. Con esto, nuestro código será mucho más limpio puesto que no tenemos que delegar el trabajo desde el Code-Behind y asi dejamos a éste para lo que realmente está, para hacer todo lo referente a la vista y no a los datos.

Así que vamos al lío.

¿Cómo se crea un comando?

Originalmente quizá crear un comando no era tan facil como crear un evento, pero gracias a la comunidad tenemos unas clases que harán que crear comandos sea incluso más facil que crear eventos.

MVVM Light incluye una de esas clases, RelayCommand

Usar un RelayCommand es lo más facil del mundo, empezamos por crear el comando en sí como una propiedad autocompletada del MainViewModel:

public RelayCommand AcceptCommand { get; private set; }

Los comandos por convención incluyen la palabra Command al final.

Ahora creamos el comando en el Constructor:

AcceptCommand = new RelayCommand(Accept);

El constructor del RelayCommand recibe un delegado (Comunmente llamado el parametro Execute pues será el que ejecute código) del tipo Action el cual espera un método que no acepte parámetros y tampoco devuelva nada, así que le hemos pasado el método “Accept” al RelayCommand, así que vamos a crear dicho método (sin parametro y devolviendo void):

private void Accept()
{
	Greeting = string.Format("Hello, my name is {0} and Im {1} years old.",
		APerson.Name, APerson.Age);
}

Ya solo nos queda bindear el botón Accept al comando:

Tan fácil como esperabas

Ejecutamos la aplicación y… Funciona!

Vamos a crear ahora el comando para el botón reset, seguro que ya sabréis hacerlo por vosotros mismos…

public RelayCommand ResetCommand { get; private set; }

ResetCommand = new RelayCommand(Reset);

private void Reset()
{
	APerson = new Person();
	Greeting = string.Empty;
}

Creo que no harán falta las explicaciones aquí, ¿Verdad?

Ahora probemos una cosa… Abrimos la aplicación y le damos a Accept…

Uh, esto ya no mola tanto… ¡Ah! Ya lo tengo, pongo el botón como disabled y cuando rellene los dos textbox lo pongo enabled… Uhm, la idea es buena, pero… ¿Cómo lo implemento? Podría crear unos eventos que comprobaran que los textbox tienen información y luego desbloquear el botón o algo. Nah, muy dificil, mejor compruebo a la hora de hacer click de que haya info, en caso de no haberla que suelte un MessageBox diciendo que has de rellenar las cajas o mejor, no hago nada, se supone que si no escribes algo no va a valer.

Bueeeno, vamos a hacerlo bien, que lo importante en una aplicación con interfaces es la experiencia de usuario (UX).

Los comandos tienen la capacidad de saber cuando pueden ser ejecutados y cuando no. La forma que tienen de avisar de que no pueden ser ejecutados es simplemente bloqueando el control (¡Justo lo que queremos!).

Para ello, RelayCommand acepta otro delegado (éste comunmente llamado CanExecute), en este caso del tipo Func el cual no acepta ningun valor y a la vez devuelve un bool, el cual si es true el comando se puede ejecutar y si es false, pues lo contrario.

Antes que nada, necesitamos una forma de comprobar si los atributos de la clase están “rellenos” o no, para ello vamos a implementar una pequeña propiedad en la clase Person:

public bool IsValid
{
	get
	{
		return _name != string.Empty && _age > 0;
	}
}

Vamos a modificar nuestro AcceptCommand

En el constructor lo cambiamos por:

AcceptCommand = new RelayCommand(Accept, CanAccept);

La convención también suele decir que los métodos para comprobar si un comando se puede ejecutar o no van prefijados por Can.

Ahora escribámos el método:

private bool CanAccept()
{
	return APerson.IsValid;
}

Si ejecutamos el código, vemos que el botón Accept está bloqueado:

Para desbloquearlo deberemos rellenar los 2 textboxes primero.

NOTA: Por defecto el binding se hace cuando el campo pierde el foco, así que hasta que no le quitemos el foco a la ultima caja que rellenemos, no se activará el control. Esto puede ser modificado cambiando el modo del binding a PropertyChanged.

Una de las cosas buenas de los RelayCommands es que aceptan un delegado, y en este caso el CanAccept es simplemente una linea…

Así que vamos a borrar el método CanAccept entero y vamos a modificar la inicialización del RelayCommand para que reciba una lambda:

AcceptCommand = new RelayCommand(Accept, () => APerson.IsValid);

Te quitas 4 líneas de encima.

Vamos a meterle una nueva feature a la aplicación, una que nos diga el número de caracteres que tiene el saludo.

Vamos a la vista y debajo del bóton reset insertamos:

Nada extraño, bueno, código feo de Blend, pero no nos preocupa eso para el tutorial (pero si para nuestras aplicaciones reales ehh )

¿Cómo vamos a contar los carácteres del mensaje? En el mundo real simplemente bindeariamos la nueva caja a “Greeting.Length” y asunto solucionado, pero como esto no es el mundo real y sí un artículo de aprendizaje, vamos a usar otro método el cual nos será util para otras muchas cosas en dicho mundo real

Los comandos nos permiten la posibilidad de enviar un parámetro con ellos, así que vamos a aprovechar eso para enviar el numero de caracteres directamente sacado del textbox del Greeting.

Para ello empezamos dandole un nombre a dicho TextBox:

Ahora nos vamos con la creación del comando:

public RelayCommand CountCommand { get; private set; }

Como veis, ahora usamos una versión genérica del RelayCommand que acepta un parámetro pero…. ¿Por qué int? y no un int normal?

Atención a esto, ya que probablemente esto solo sea suficiente para leer el artículo.

El RelayCommand va a intentar comparar el parámetro con null, un tipo primitivo no puede almacenar null, así que comparar un int contra null dará una preciosa excepción la mar de maja.

Entonces existen versiones nullables de los tipos primitivos, para usar esos tipos hay que colocar la interrogación detrás del tipo, int?, double?, bool?, etc.

Con decir que yo pasé horas investigando esto e incluso terminé reescribiendo parte de la clase para que no reventara… Oye, ya no hacía falta pasarle ningún nullable, pero vamos, ya que se como va, os lo explico bien

Pasemos a lo siguiente, inicializar el comando:

CountCommand = new RelayCommand(Count, noused => Greeting != string.Empty);

¿Qué es eso de noused? El parámetro que pasamos con el comando lo recibirá tanto el “Execute” como el “CanExecute” y en este caso, el “CanExecute” no necesita para nada ese parámetro, aun asi, tiene que recibirlo, asi que le pongo de nombre “noused” para dar a entender que no lo necesitamos. Aparte de eso, comprobamos que ya se haya creado el mensaje del greeting para activar el botón.

Antes de implementar el método Count necesitamos una propiedad donde alojar el mensaje con el numero de caracteres, tal y como hicimos con la propiedad Greeting:

private string _countMessage = string.Empty;

public string CountMessage
{
	get { return _countMessage; }
	set
	{
		_countMessage = value;
		RaisePropertyChanged("CountMessage");
	}
}

y ahora la bindeamos a la caja:

Ahora vamos a crear el método “Count”:

private void Count(int? characters)
{
	CountMessage = string.Format("Greeting has {0} characters.", characters);
}

Lo unico que queda es bindear el comando al botón:

¿No es difícil verdad? Hacemos uso de CommandParameter para enviar un parámetro, en este caso el numero de carácteres del textbox “Greet”.

Todavía queda algo más. No todos los controles implementan comandos y normalmente estos comandos son ejecutados cuando haces click en el control. No siempre va a ser eso lo que necesitas y muchas veces directamente no vas a tener opción a ningun tipo de comando. Así que en vez de tirar de eventos, podemos usar una librería que trae MVVM Light, EventToCommand, con esta librería podemos “transformar” cualquier evento a un comando.

Para evitar hacer más complejo el ejemplo, vamos a suponer que los botones no tienen comandos y queremos transformar su evento “Click” en un comando.

Para ello tenemos que importar estos namespaces en nuestra ventana:

xmlns:i="clr-namespace:System.Windows.Interactivity;assembly=System.Windows.Interactivity"
xmlns:cmd="clr-namespace:GalaSoft.MvvmLight.Command;assembly=GalaSoft.MvvmLight.Extras.WPF4"

NOTA: Si estais usando Visual Studio 2008 con WPF3.5 has de cambiar uno de los namespaces:

xmlns:cmd="clr-namespace:GalaSoft.MvvmLight.Command;assembly=GalaSoft.MvvmLight.Extras"

Bueno, ahora nos vamos a un botón cualquiera (por ejemplo reset) y lo dejamos así:

No es tan complejo, ¿no? Hemos seleccionado el tipo de evento que estará bindeado al comando y luego hemos dicho cual es el comando No hemos tenido que modificar el ViewModel siquiera.

Esto suele venir bien por ejemplo para ejecutar un comando cada vez que seleccionas un elemento en un ListBox, ya que SelectionChanged no puede ser bindeado a un comando por defecto.

Y bueno, hasta aquí la explicación de comandos, más largo de lo que esperaba, y espero que no se olvide nada.

Os dejo un zip con el código fuente (Visual Studio 2010) para los que no queráis hacerlo mientras lo leeis (¡Mal! )

Código fuente

Espero vuestros comentarios (que va a ser que no habrán) y nos vemos en la próxima parte.

MVVM Light: ¿Qué es?

admin — Sat, 20 Mar 2010 18:30:59 +0000

Empezamos con la primera parte de la serie de artículos de MVVM Light, en concreto con la gran pregunta:

¿Qué es exactamente MVVM o MVVM Light?

Vamos a empezar explicando qué es MVVM:

MVVM es un patrón de diseño que entra dentro de los llamados patrones mv* como podrían ser:

Ambos son patrones muy usados a la hora de crear la arquitectura de la aplicación. De MVP ya hemos hablado en otro artículo y bueno, MVVM es una alternativa mejor a la hora de desarrollar aplicaciones tanto WPF, Silverlight y Windows Phone 7.

Antes de entrar en explicaciones concretas, os dejo un diagrama que os ayudará a entender las cosas:

Como podéis ver aquí, existen tres componentes en este patrón: Model-View-ViewModel, osea, MVVM.

En el Modelo irá toda la lógica de negocio de nuestra aplicación, como podría ser la clase Libro, Persona, Factura… Este tipo de clases tambien son llamadas POCO’s (Plain Old C# Objects), o sea, clases básicas sin ninguna funcionalidad de WPF ni Silverlight.

El ViewModel como su nombre indica, es el modelo de la vista, o dicho de otra forma, es donde irá todo el trabajo que la vista necesita hacer. Si tomamos como ejemplo mi ApuntaNotas, el ViewModel se encargaría de añadir nuevas notas cuando el usuario hace click en el botón, borrar notas, renombrarlas, cambiarles la categoría… En resumen, el ViewModel hace todo el trabajo de la vista que tiene que ver con datos.

La Vista como cabe de esperar será la que contendrá el XAML de nuestra aplicación WPF, Silverlight o Windows Phone 7. Nada raro aquí.

Eso si, todo el mundo se pregunta… ¿Y el Code-Behind de la vista? ¿Vale para algo?

Por supuesto que sí, es un tema controvertido quizá, el code-behind en aplicaciones WinForms por ejemplo ha sido siempre usado para hacer todo el trabajo de la vista. Luego dijeron que eso estaba mal y decidieron delegar todo ese trabajo a un controlador y dejaron el code-behind inutil sin ningún uso.

En MVVM el code-behind es bastante usado, ¿Para qué exactamente? El code-behind lo usaremos para hacer todo el trabajo que tiene que ver con la vista en sí. ¿Recuerdas que dije que el ViewModel haría todo el trabajo de la vista relacionado con datos? Pues ahora el code-behind hace el trabajo restante, o sea, lo que tiene que ver exclusivamente con la vista.

Por ejemplo… Imaginad que si seleccionamos un elemento de un ListBox queremos que cierto TextBox coja el foco; esto es cosa de la vista en sí, no tiene que ver con datos ni nada así que el mejor lugar para hacerlo es el code-behind.

Explicandolo de otra forma que quizá os quede más clara:

Tenemos una aplicación para mostrar una serie de resultados que extraemos de una base de datos.

Para ello tenemos un ViewModel que extrae esos datos del modelo, y prepara esos datos para que una vista pueda usarlos. El ViewModel en sí no sabe nada acerca de las vistas, éste simplemente tiene un conjunto de propiedades para que una vista pueda hacer DataBinding a ellas (como podeis ver en el diagrama de antes). A este ViewModel podemos asignarle cualquier numero de vistas que queramos y dichas vistas representará esos datos como quiera.

Entonces imaginemos que una de esas vistas representará esos datos usando graficas y esas graficas contendrán cosas como animaciones, por ejemplo dandole a un botón la grafica hace una animación chula para mostrar los datos. ¿Quien ha de hacer ese trabajo? Está claro que el ViewModel no, puesto que el ViewModel no sabe nada acerca de las Vistas que lo están usando y si tuviera que implementar cosas por cada vista que lo use, perdería ya el desacople, ¿no? Así que es el code-behind el que hace estas cosas puesto que son cosas que solo atañen a la vista y nadie más.

Hasta aquí es básicamente MVVM, queda algo importante que contar, los comandos, pero eso lo dejaré para la próxima parte donde ya pondré un ejemplillo para que todo esto quede bien claro

Introducción a MVVM Light: Índice

admin — Sat, 20 Mar 2010 18:25:36 +0000

Voy a escribir un artículo de introducción al patrón MVVM y en concreto usando MVVM Light.

Voy a dividir este artículo en varias partes para no agobiar al lector con un artículo muy largo.

Nos vemos en la primera parte

TwitFox 1.0

admin — Sun, 20 Dec 2009 13:52:01 +0000

Hola!

He creado un cliente de Twitter, es un cliente sencillito que he hecho con el proposito de aprender y de divertirme un poco.

Os dejo una screen:

Mi primera intención era la de crear un artículo explicando paso por paso como crear un cliente Twitter, pero la verdad es que aunque simple el cliente, ha terminado con más código del que pensaba.

Aun así os daré algunos detalles para que cuando mirés el código pues sepais más o menos qué hace cada cosa.

No he usado ninguna librería concreta para desarrollar esta primera versión del cliente de Twitter. Simplemente he usado el REST API el cual es bastante limitado.

La clase TwitterClient es la que nos permitirá descargar nuestros Tweets y cambiar nuestro estado. No hace nada más. Cuando cambie la librería, añadiré más opciones a la interfaz de dicha clase sin modificar las opciones que ya hay.

Podeis observar que la clase lo que hace es descargar un XML con los tweets y parsearlos.

Por otro lado, podéis ver que la estructura del proyecto es MVP aunque le he añadido tambien la clase DelegateCommand para usar comandos siempre que sea posible.

Lo más complejo del proyecto es la UI, en la cual he usado Data Templates, Fake DataContext (Dos cosas que habéis aprendido aquí), además de un botón custom con una pequeña animación.

El código de la UI quizá sea un poco guarrete, pero es la primera aplicación que hago usando Blend 3 como aplicación de diseño principal.

Nada más, os dejo aquí el enlace a la aplicación:

TwitFox

Un saludo!

[WPF] Datos en tiempo de diseño (Design-time DataContext)

admin — Wed, 09 Dec 2009 15:13:22 +0000

¡Hola!

Para seguir este artículo necesitaréis de Microsoft Expression Blend 3 o Visual Studio 2010 Beta 2. Además necesitaréis una copia del proyecto del artículo “Data Templates“.

Antes de explicaros qué significa exactamente eso de Datos en tiempo de diseño quiero que veais el problema en vuestras carnes y así buscarle una solución idónea.

Yo usaré Blend 3 así que las imágenes y las instrucciones serán usando este soft, pero se pueden aplicar con Visual Studio 2010 sin ningún problema.

Imaginad esta situación:

Queréis modificar el Data Template que habíamos creado del ejemplo citado. No sé, el borde ese verde que tiene cada item no os gusta y queréis ir probando colores hasta encontrar uno que os guste más. Ningún problema, abres el proyecto con el Blend 3 y….

Vaya tela, nos sale una bonita ventana en blanco… ¿Por qué no sale el contenido? No nos sale porque ni Blend ni Visual studio ni nadie sabe qué ha de representar ahí, o mejor dicho, nosotros estamos ‘bindeando’ ese contenido a una propiedad del DataContext, o sea del ViewModel. Blend no sabe nada sobre ese DataContext que hemos establecido en código, así que el no sabe que ha de mostrar ahi ni nada. Si bien sabe como dibujar el Data Template, no sabe qué ‘Data’ tiene que reprentar ahi.

Entonces con Blend 3 llegó una nueva cosita llamada Datos en tiempo de diseño, o lo que es lo mismo, ofrecerle unos datos ‘de mentira’ a Blend 3 a fin de que los use para dibujar los Data Template en la ventana.

¿Qué quiero decir con eso de ofrecerle unos datos de mentira? Fácil, el ItemsControl está asociado a una lista llamada ListaPersonas, pero dicha lista ‘viene’ del DataContext y como ya os he dicho, el editor visual no puede mostrar nada que venga de ahi, por eso nos aparece la ventana en blanco, porque ignora el DataContext.

Aquí es donde entra el Datos en tiempo de diseño (Design-time Data). es digamos un DataContext especial sólo para diseñar, así podemos mostrar datos ‘Fake’ y ver como quedaría sin ejecutar la aplicación ni nada. Por ejemplo:

Imaginad que estais haciendo una aplicación de Twitter. Cuando la aplicación se conecta a la red, descarga tus tweets, y crea una instancia de la clase Tweet por cada tweet que recoja. ¿Cómo diseñarías la ventana principal del programa? ¿Creas un no sé, ItemsControl y creas un DataTemplate para los Tweet? Es una idea, pero es un coñazo, tienes que crear un template, abrir el programa, conectarte a tu Twitter, que descargue tus Tweets y ver que… oh mierda, ese borde no moooola nada. Cierras la aplicación, modifica el borde y otra vez a probarlo. Si tienes que hacer eso 50 veces para dejar el estilo a tu gusto, mueres.

¿Qué hacer entonces? Creas una clase llamada… FakeTweets por ejemplo que herede de la clase que usa tu ventana de DataContext, ahí instancias la lista del datacontext, creas unos cuantos tweets de mentira y usas la técnica que explicaré a continuación

Este ejemplo es algo muy común, porque donde dices Twitter, dices aplicación de msn y su ventana de contactos, etc.

Vamos a nuestra aplicación que ya está abierta en Blend, y añadimos lo siguiente dentro del Tag de la ventana…

xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
xmlns:local="clr-namespace:DataTemplates"
mc:Ignorable="d"

Con lo que quedaría así:

Voy a detallar para qué sirve cada uno:

xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
xmlns:local="clr-namespace:DataTemplates"

Los 3 son namespace como podeis ver, cada uno con una idea en mente.

El primero es el que añade todo el tema de Datos en tiempo de diseño.
El tercero es para importar el namespace de nuestra aplicación (luego veremos por qué)
El segundo va en conjunto con:

mc:Ignorable="d"

El namespace ‘mc’ que hemos importando antes nos sirve para usar el Ignorable. ¿Para qué sirve esto? Sirve para excluir todo lo que sea del namespace indicado a la hora de compilar. ¿Por qué ignoramos el namespace ‘d’? Porque lo que nos ofrece son cosas que nos facilitan la vida a la hora de diseñar la aplicación, pero que a la hora de ejecutarla ya no nos sirve. Así que la aplicación compilada no contendrá nada de lo que coloquemos de cara a ayudarnos a diseñar.

¿Y ahora qué? Ahora tenemos que cargar en el XAML la clase con los datos ‘fake’ (como por ejemplo la clase con tweets de mentira), en nuestro caso nos basta con cargar el Presenter ya que trae datos de ejemplos que nos servirá para el caso.

Para esto podemos usar por ejemplo un ObjectDataProvider:

Como ves, he cargado el Presenter (usando el namespace local que cargué antes) y le he dado el nombre de FakeVM.

Ya solo nos quedaría cargar dicho objeto dentro del Data Context en tiempo de diseño, el cual está en el namcespace ‘d’.

En nuestro ejemplo, se lo asignaremos al ItemsControl como era de esperar:

NOTA: El método que he descrito aquí, inclusive los namespaces de blend, sirve tanto para Blend 3 como para Visual Studio 2010 (Beta 2 en adelante)

ahora, si vamos al modo diseño…

Ya se ve!! Pero dirás… ¿Y ahora qué? ¿Puedo modificar el template en modo diseño y en ver los resultados en tiempo real? Claro que sí!

En Blend 3, abajo a la izquierda nos aparecerá el arbol de objetos de nuestra aplicación:

Screenshot

Ahi hacemos click derecho en ItemsControl y luego Edit Aditional Templates -> Edit Generated Items (ItemTemplate) -> Edit Current. Al hacer esto vemos como se señala el primer objeto del ItemsControl (ya que realmente editando uno, cambian todos).

Ya solo nos queda hacer los cambios pertinentes, por ejemplo cambiando el borde de cada objeto por uno con gradiente Negro <-> Blanco. Comprobareis con alegría que mientras moveis el cursor en la paleta de colores, el resultado se va viendo en tiempo real, y no necesitaréis ejecutar la aplicación con cada cambio.

Así que en resumen, teneis una manera de poder diseñar los Data Templates de forma visual usando datos ‘fake’ y que no afectará para nada a la aplicación compilada.

Espero vuestros comentarios

Nueva versión de Apunta Notas 2

admin — Thu, 17 Sep 2009 21:27:35 +0000

Hola!

Siento no escribir tanto como me gustaría, pero estuve de exámenes hace poco, y ahora he empezado a trabajar.

Bueno, antes de dichos exámenes escribí una nueva versión del Apunta Notas y la anucio por aquí para que la probeis.

Dicha versión tiene:

Ahora al borrar una categoría te da la opción de borrar todas las notas asociadas a ella.
Si decides no borrar dichas notas, se enviarán a una categoría oculta llamada “Papelera”.
Ahora al pulsar intro se añadirá la nota automaticamente (antes no me funcionaba por un pequeño bug que no veía)
Los rectangulos de los colores también son botones para seleccionar el color
Algun bug solucionado

Quizá se me olvide algo, pero ahora no caigo, realmente metí muchas mejoras a lo largo de 2 dias de trabajo con el.

Los enlaces están donde siempre

A ver si este fin de semana puedo hacer algo más interesante.