El Bloqueador (parte 1 de 2)

¿Cómo puede mi control, en XAML, referenciar una cantidad n de otros controles? Pues tiene su ciencia.

Saludos de año nuevo… no estuve en vacaciones, apenas voy a salir, pero sucedió que en la empresa donde laboro se requirió desarrollar una aplicación en poco más de un mes. Poco tiempo, y fue esta la razón por la que me alejé un tiempo del Blog. Nada que decir, los usuarios de la aplicación encargados de pasarnos los requerimientos también tuvieron poco tiempo. A pesar de la premura el desarrollo salió bien y estuve encargado de seleccionar la tecnología para la capa de usuario y adivinen qué escogí… Windows Presentation Foundation.

Que no suene a traición por favor. Me hubiese encantado trabajarla en Silverlight, pero debido a la premura y a varios detalles específicos que se requerían opté por WPF ya que, y en esto hay que ser realista, si nos parece que con Silverlight no hay limitaciones entonces con WPF el límite es el cielo.

Durante el desarrollo de esta aplicación me encontré con varios retos interesantes y mientras los encaraba me pregunté ¿Cómo se hará esto con Silverlight?, ¿Si se podrá?. Yo mismo me respondí con un tímido “seguramente si”. Para estar seguro decidí tomar estos retos, hacer mi mejor esfuerzo y convertirlos en soluciones Silverlight que veremos en este Blog.

Uno de estos retos se relaciona con mi entrada “Un espacio en mi control para tu control”. Para la aplicación en cuestión lo ideal hubiese sido utilizar el patrón MVVM, pero por la falta de tiempo solo se adoptaron algunas partes aisladas del mismo. Entre ellas la posibilidad de deshabilitar/habilitar (propiedad IsEnabled) un grupo determinado de controles dependiendo de la propiedad IsChecked de un control tipo CheckBox.

La primero que se que me vino a la cabeza, y lo más obvio, consistía en utilizar un Trigger que hiciese dicho trabajo. Sin embargo esto implicaba que mi XAML iba a crecer, y bastante, ya que en ocasiones se debían deshabilitar hasta 20 controles dejando otros tantos por fuera de dicho bloqueo. Luego pensé en un Behavior para agregárselo al checkbox, pero no supe como pasarle la lista de los controles a bloquear. Finalmente, y ya que no se me ocurrió nada más, decidí crear un control que pudiese colocar directamente en XAML y alimentarle la lista de los controles de modo que tuviese algo más elegante y manejable, como esto:

<local:BloqueoControles ControlChequeo=”{Binding ElementName=checkBox1}”>
  <local:ControlIndividual Elemento=”{Binding ElementName=button1}” />
  <local:ControlIndividual Elemento=”{Binding ElementName=textBox2}” />
  <local:ControlIndividual Elemento=”{Binding ElementName=textBox3}” />
</local:BloqueoControles>

Haciendo la “traducción” desde WPF a Silverlight me di cuenta casi al instante que muy poco de dicho código me iba a servir. De hecho casi nada. En ese momento me hice nuevamente la pregunta: ¿Nadie notó que en mi artículo “un espacio en mi control para tu control” el control que se recibe no puede tener nombre? Traigo esto a colación porque esa es precisamente la columna vertebral de la solución: Poder hacer referencia a otros controles dentro de los controles hijos de mi control, ¿Cómo les pareció el trabalenguas?

En WPF mi solución/clase hereda de FrameworkElement ya que incluye el método “AddLogicalChild” que, al agregar los hijos al Logical Tree, les permite a estos “ver” otros controles por medio del Binding. Sin esta operación el Binding simplemente no encuentra nada pues los controles no hacen parte de dicho árbol. Ponerlos en XAML no es suficiente. Y adivinen… el FrameworkElement de Silverlight no tiene tal cosa como “AddLogicalChild”. Entonces ¿Cómo recibir una lista en XAML que pueda hacer referencia a un número n de controles?.

Ante esta preguntica decidí heredar de otra clase: “Panel”. No era lo que quería hacer ya que por definición un Panel sirve para organizar otros controles y en mi caso mi Bloqueador no debía tener ninguna representación visual y luego no necesita organizar nada. Sería como romper “un poco” con el objetivo del Panel. Sin embargo, y después de un muy sentido “no se me ocurre nada más”, decidí que el Panel era la solución pues hace lo que necesito: agrega sus controles hijos (propiedad Children) al Logical Tree de modo que puedan tener acceso a los demás controles de la interfase. El asunto aquel de no tener una representación visual podemos manejarlo por código.

Al final debo admitir que salvo por el hecho de heredar de Panel la solución se sigue viendo elegante y un poco más breve en términos de código.

En la siguiente entrega nos adentraremos en esta simple pero muy útil técnica.

Anuncios

Acerca de SilverIdeas

Instructor y entusiasta en el uso de Silverlight y otras tecnologías XAML.
Esta entrada fue publicada en Silverlight, WPF, XAML. Guarda el enlace permanente.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s