Comandos en WPF

Aunque hace tiempo que comencé a aplicar los comandos de WPF en Precove, cada vez le veo más color. Al principio usaba el comportamiento básico ofrecido por WPF: los comandos son una abstracción intermedia entre un botón (elemento visual) y su manejador (código). En una ventana defines un botón asociado al comando (en lugar de capturar su evento Click), y en esa misma ventana estableces un CommandBinding que dice qué hacer cuando se ejecute el comando (con un manejador cuyo código está en la misma ventana). También puedes decirle cuándo se puede ejecutar el comando, con CanExecute, lo que automáticamente deshabilita los botones asociados con él. Por supuesto, esta es una de las ventajas, puede haber distintos botones, menús... asociados con un comando; incluso se pueden ejecutar por código, necesario por ejemplo al hacer doble clic en un elemento de una tabla.
Ahora lo he ampliado, al descubrir que el código que ejecuta un comando suele ser el mismo independientemente del contexto. Realmente tenemos dos casos: el típico ejemplo del botón Copiar, o más concretamente el botón Nuevo, que según la ventana o control que tenga el foco se comportarán de forma distinta; y el de un botón como Dar Presupuesto, que siempre muestra el asistente como una nueva ventana. Para este segundo caso, he incluido en Nibi.Presenta una clase abstracta SmartRoutedUICommand, en la que al heredar podemos definir un código estándar para los métodos CanExecute y Execute. Y para que este código se ejecute sin necesidad de añadir un trivial CommandBinding, se ofrece una clase CommandBinder que ofrece una propiedad Command que además de asignar el comando a un botón, crea el CommandBinding con los métodos del comando. Obviamente, sólo se puede usar con comandos SmartRoutedUICommand, que son los que ofrecen un código estándar.
Otra ampliación adicional ha sido la utilización de RoutedUICommand, y su ampliación a ImageRoutedUICommand añadiendo una descripción y una imagen (ImageSource para WPF, realmente es una ruta para cargar la imagen sólo cuando el motor gráfico necesite mostrarla). SmartRoutedUICommand hereda de ImageRoutedUICommand, con lo que ofrece esta información adicional para automatizar su visualización en la barra de botones, como botón suelto, como menú... Para esta visualización, se define un estilo con la clave ToolBar.ButtonStyleKey para que se aplique a todos los botones que se muestren en una barra de herramientas, y que utilice los datos del Command asociado al botón. Así lo botones sólo deben definir esa propiedad, Command, y de ahí se sacan sus propiedades como Imagen, Título y Descripción (para el ToolTip). Este estilo estará por defecto en la aplicación, pero si en un tema se redefine, deberá utilizarse el mismo sistema para obtener y establecer las propiedades a partir del comando.
Por último, comentar una pega que me he encontrado con el grid de Xceed. Aunque ellos en su página web informan de que son compatibles con los comandos de WPF, y que incluso ofrecen nuevos comandos como Editar celda que uno puede asociar a sus botones y el grid responde a su ejecución, yo le encuentro una pega mucho más sencilla: la documentación de WPF afirma que los comandos son actualizados en cada cambio en la interfaz. Pues bien, mientras nos movemos por el grid no se actualiza nada. En cambio, si me meto en un textbox que he puesto junto a él, nada más entrar el foco se actualizan los comandos (se ejecutan sus CanExecute). Puede ser culpa de que el grid se encuentra dentro de un control de usuario y el botón fuera, pero el hecho y verdad es que he tenido que repetir el CommandBinding (este no es un Smart...) dentro y fuera de ese control de usuario para que afecte en los dos sitios.

Sincronización completa con Binding de WPF

Para empezar, aclarar que los binding de WPF están mucho mejor que los de Windows.Forms, no sé si ya lo había dicho antes. Ni punto de comparación. Pero son mejorables en muchos aspectos, y sobre todo en el que voy a contar ahora de una forma muy fácil.
Estamos usando converters (que implementan IValueConverter) para dar formato a los datos que se muestran a través de los binding, y también para procesar de vuelta el valor introducido por el usuario y llevarlo al negocio. En concreto tenemos un FormatoConverter que permite un parámetro con la cadena de formato, y que usamos para dar formato de moneda, de número, de fecha... así como para parsear el valor de cualquiera de estos tipos escrito por el usuario.
El valor ofrecido por el conversor se asigna al objeto de negocio, y si hay algún error, se notifica al usuario mediante la propiedad ValidatesOnDataErrors del Binding (nuestro negocio implementa IDataError para esto). Hasta aquí muy bien.
Si durante el parseo detectamos un error, por ejemplo que se escriba texto cuando esperamos un número, mi intención era lanzar un error que sea detectado como los de negocio, con lo que se muestre de la misma forma al usuario. Esto no es posible puesto que ConvertBack (el método donde se parsea en IValueConverter) no ofrece una vía para notificar este tipo de errores, y la documentación dice claramente que cualquier excepción disparada en su cuerpo no será controlado y saltará como error en tiempo de ejecución. Por esto decía que era muy fácil de solucionar por parte de Microsoft: basta con esperar este error, y mostrarlo tal como se hace con los errores producidos al asignar el binding.
Al no contar con este simple mecanismo, lo único que podemos hacer (y que hace todo el mundo) es devolver Binding.DoNothing o DependencyProperty.UnsetValue, los cuales anulan la escritura en el objeto de negocio pero no notifican error... con lo cual el efecto es muy malo: queda un valor escrito en el control, que al usuario no le aparece que sea incorrecto, y en negocio queda el valor antiguo que posiblemente sea correcto, con lo que si preguntamos dice que puede guardarse... ¡pero no se guarda lo que el usuario está viendo! De ahí que yo haya renunciado al DoNothing cuando no se reconoce la cadena introducida, y en cambio devuelvo null (que posiblemente será un valor incorrecto para el negocio).
Para quedarme con esta solución, solo necesito que cumpla con un requisito que ya he comentado de pasada: los valores de negocio y de los controles mostrados al usuario deben estar siempre sincronizados. Aunque parece algo obvio, ya he comentado que no sucede si usamos DoNothing, y tampoco si devolvemos null, porque en el control queda el valor incorrecto. Así que necesitamos refrescar el control con el valor del negocio (para mostrar al usuario que su valor no se ha admitido, lo cual es mucho peor que dar un mensaje de error o destacar en rojo el control, pero es la solución más sencilla dentro del marco del Binding de WPF). Este refresco también es necesario en otro caso distinto: cuando el negocio corrige el valor escrito, como al escribir un NIF (se quitan puntos y guiones e incluso puede que se añada la letra) o al escribir una matrícula (se quitan guiones), o si se corrigen mayúsculas... La cuestión es que esto no sucede, de forma que al realizar esta corrección queda el valor corregido en negocio y el original escrito por el usuario en el control, y hay que forzar un refresco del binding para actualizar el dato mostrado. Vamos a especificar de forma global un manejador LostFocus que haga esta actualización al abandonar un control (igual que lo estamos haciendo en el GotFocus para seleccionar todo el texto), localizando todos los binding del control y usando su método UpdateTarget.
Y ahí lo dejo, sin conclusión ni nada. Hala.

[Cambio 12:18] Bueno, venga, añadiré algo... En primer lugar matizar y cambiar lo que he comentado del null en lugar de DoNothing: esto está bien para algunos casos, pero sólo se aplica cuando usamos nuestro converter, por lo que el resto de binding actúan como por defecto, con el DoNothing. Como esto es un poco inconsistente (si pones texto en un control que es numérico, al salir en un caso se cambia por un cero, y en otro se queda el número que había antes), vamos a optar por el comportamiento implementado por WPF: usar el DoNothing. Esto hace que nunca se marque error al escribir texto (salvo si con el valor anterior ya había un error, que se mantiene).
Y una conclusión: al final no he solucionado el primer problema, sólo el segundo de mantener sincronizado el control con el negocio al abandonar el control; aunque esta solución ayuda un poco al primer problema, al quitar valores que no se han podido parsear. Pero queda pendiente un mecanismo que avise del error cuando escribamos algo que no pueda convertirse al tipo de la propiedad de negocio. Esperemos a Microsoft.