PDF de programación - El enrutador que los enrute... Eventos en XAML

firma solidaria

Guillermo “Guille” Som

El enrutador que los enrute…

Eventos en XAML

Con la llegada de XAML y las aplicaciones para Windows Presentation Foundation (WPF)
han cambiado ciertos conceptos en la programación para el entorno .NET, y los even-
tos no son una excepción a este cambio. De hecho, ahora debemos cambiar un poco el
chip para dejar paso a los eventos enrutados (routed events), y en este artículo veremos
qué son, cómo funcionan y lo más importante: cómo utilizarlos.

HHoossppiittaall DDoottNNeett

Guillermo Som ha cedido los derechos de autor de este
artículo al proyecto Hospital DotNet. Este proyecto es una
iniciativa del portal DOTNETSOLIDARIO que pretende
recaudar fondos para la creación de un hospital en una de
las zonas más desfavorecidas del tercer mundo.

Usted puede colaborar con este proyecto.Visite la Web

en www.dotnetsolidario.com para conocer los detalles.

<< Empecemos viendo

la descripción
de eventos enrutados (routed events). Se-
gún la documentación del SDK de
Windows, un evento enrutado es una
instancia de un evento que se propaga
por un árbol de elementos relaciona-
dos en lugar de apuntar a un solo ele-
mento. Según esa misma documenta-
ción, hay tres tipos de enrutamiento:
bubbling (de burbuja), tunneling (de tú-
nel) y directo. Con el enrutamiento bub-
bling, el evento se propaga (“sube”) des-
de el elemento que lo produce hasta la
parte superior del árbol de elementos.
Por otra parte, en el caso del enruta-
miento tunneling esa propagación “ba-
ja” desde la parte superior del árbol has-
ta el elemento que produce el evento.

Guillermo “Guille” Som
Es Microsoft MVP de Visual Basic des-
de 1997. Es redactor de
ddoottNNeettMMaannííaa, mentor de Solid Qua-
lity Iberoamericana, tutor de cam-
pusMVP, miembro de Ineta Speakers
Bureau Latin America, y autor de los
libros “Manual Imprescindible de Visual
Basic .NET” y “Visual Basic 2005”.
http://www.elguille.info

a
í
n
a
M
t
e
N
t
o
d
<
<

12

Por último, el enrutamiento directo no
propaga el evento en ninguna dirección
y se comporta como los eventos “nor-
males” a los que estamos acostum-
brados.

Para comprender mejor estas nue-
vas definiciones, debemos tener en
cuenta cómo funcionan o se compor-
tan los elementos de una aplicación
WPF, que como sabemos, en este tipo
de aplicaciones están definidos en
XAML. Por regla general, los elemen-
tos de una aplicación XAML suelen es-
tar contenidos en otros elementos; de
hecho, al igual que ocurre con las apli-
caciones normales de Windows, siem-
pre hay algún contenedor que “contie-
ne” los controles, aunque sea el propio
formulario, en el caso de las aplicacio-
nes de Windows, o cualquiera de los
contenedores de las aplicaciones de
WPF.

La diferencia de las aplicaciones ba-
sadas en Windows Forms con las apli-
caciones para WPF, es que, por ejem-
plo, un botón no solo es un botón, ya
que tal como se crean las aplicaciones
con XAML ese botón puede contener
otros elementos, por ejemplo un blo-
que de texto o una imagen, y a diferen-
cia de las aplicaciones “normales”, esos
elementos que contiene se pueden tra-
tar de forma independiente. Pero en el
caso de ese botón compuesto, no ten-
dría mucho sentido tratar cada uno de
los eventos de los elementos que lo

componen de forma independiente, si-
no que nos resultaría más práctico tra-
tarlos como un todo. En este caso los
eventos enrutados nos pueden ser de
mucha utilidad, en particular los de ti-
po tunneling, los que se producen pri-
mero en la parte superior del árbol de
elementos, en nuestro caso, el propio
botón. Veamos otros conceptos relacio-
nados con estos eventos enrutados y có-
mo detectarlos antes de que lleguen al
elemento que realmente lo produce.

Los tipos de enrutamiento de
los eventos XAML

En WPF cada evento se puede de-
tectar de dos formas diferentes, según
lo queramos interceptar antes de llegar
al elemento que realmente lo produce
(tunneling), en cuyo caso el nombre del
evento va precedido de Preview, lo que
nos da una idea de cuál es la intención
de dicho evento: tener la posibilidad de
interceptarlo antes de que realmente se
produzca. Por otro lado tenemos los
eventos bubbling, a los que no se añade
ningún prefijo. Como regla general, to-
dos los eventos de los elementos de
WPF van en pareja, y por cada evento
suele haber uno previo y uno normal.
Por ejemplo, la pulsación de las teclas
suele detectarse con el evento KeyDown,
evento de tipo bubbling (lo detectaría-
mos en el control que lo produce) y el
correspondiente de tipo tunneling es
PreviewKeyDown (para detectarlo antes
de que llegue al control). Aclarar que
este tipo de eventos emparejados tam-
bién están disponibles en la versión 2.0
de .NET Framework, aunque eviden-
temente sin la misma potencia “enru-
tadora” que en .NET Framework 3.0.
Hay ciertos eventos que no van en pa-
rejas, aunque sí que suelen estar relacio-
nados con otros eventos; por ejemplo, el
evento Click de un botón sería del tipo
bubbling, aunque no tiene emparejado el
equivalente al enrutamiento tunneling (no
existe un evento PreviewClick). En prin-
cipio, podría parecer que ese evento es de
tipo directo, ya que solo se produce en el
control que lo define y, aparentemente,
no tiene equivalente previo. Aunque en
el caso de los eventos relacionados con el

<<

dnm.firma.solidaria

ratón, siempre hay formas de buscar los
equivalentes previos; por ejemplo, el even-
to Click va precedido de varios eventos,
entre ellos los que detectan la pulsación
del botón izquierdo del ratón: MouseLeft-
ButtonDown y PreviewMouseLeftButton-
Down, aunque en este caso en particular
del evento Click, el propio control que
detecta la pulsación marca el evento co-
mo manipulado (Handled), impidiendo
que se propague por el árbol de contene-
dores. Pero tal como XAML nos permi-
te definir los eventos enrutados, también
podemos indicar que se intercepte el
evento Click de un botón en el contene-
dor (o padre) de ese botón; además, de
forma independiente al evento intercep-
tado por el propio botón.

Enrutamiento bubbling

La mejor forma de entender estos
conceptos es viéndolos con un ejemplo.
Para mantener las cosas simples, el có-
digo XAML de ejemplo está muy simpli-
ficado (pero 100% operativo) y consiste
en una ventana (Window) que contiene un
StackPanel que a su vez contiene dos bo-
tones y dos etiquetas; en el StackPanel de-
finimos un evento que interceptará la pul-
sación en cualquiera de los botones que
contenga, además, de forma independien-

te, cada botón define su propio evento
Click. Para saber cuál es el orden en el que
se producen los eventos tengo definida
una función que simplemente incremen-
ta una variable y devuelve el valor de la
misma. En los fuentes 1 y 2 tenemos tan-
to la definición del código XAML como
el correspondiente al uso desde C# para
interceptar esos eventos.

El evento Click es de tipo bubbling,
por tanto, primero se produce en el ele-
mento que provoca el evento y después
se propaga al resto de elementos que es-
tán en el mismo árbol, es decir, al conte-
nedor del control y al contenedor del con-
tenedor, etc.; en nuestro caso al StackPa-
nel y, si así lo hubiéramos previsto, al ob-
jeto Window. Por tanto, tal como está el
código del fuente 2, primero se mostra-
rá el mensaje en la etiqueta labelInfo2 y
después en labelInfo.

En el elemento StackPanel indica-
mos que queremos interceptar el even-
to Click de los botones que contenga
este control y en el código del método
que intercepta ese evento mostramos el
nombre del control que lo produce. En
ese código usamos la propiedad Origi-
nalSource del objeto recibido en el se-
gundo parámetro, aunque en este caso
particular también nos hubiera valido
usar el valor devuelto por la propiedad

<Window x:Class=”dnm.eventosXAML01_cs.Window1” ... >

<StackPanel Name=”stackPanel1” Button.Click=”stackPanel_ButtonClick”>

<Button Name=”btnUno” Content=”Uno” Click=”btnUno_Click” />
<Button Name=”btnDos” Content=”Dos” Click=”btnDos_Click” />
<Label Name=”labelInfo” Content=”Info” />
<Label Name=”labelInfo2” Content=”Info2” Background=”LightBlue” />

</StackPanel>

</Window>

Fuente 1. Código XAML del primer ejemplo

private void stackPanel_ButtonClick(object sender, RoutedEventArgs e)
{

Button btn = (Button)e.OriginalSource;
labelInfo.Content = “Has pulsado en “ + btn.Name + “ “ + total();

}
private void btnUno_Click(object sender, RoutedEventArgs e)
{

labelInfo2.Content = “Botón Uno “ + total();

}
private void btnDos_Click(object sender, RoutedEventArgs e)
{

labelInfo2.Content = “Botón Dos “ + total();

}

Fuente 2. Código de C# del primer ejemplo

a
í
n
a
M
t
e
N
t
o
d
<
<

13

<<

dnm.firma.solidaria

<Window x:Class=”dnm.eventosXAML01b_cs.Window1” ...

Button.Click=”Window1_ButtonClick” >

Enrutamiento tunneling

Fuente 3. Modificando el fuente 1 podemos interceptar en el objeto
Window el evento Click de los botones

private void Window1_ButtonClick(object sender, RoutedEventArgs e)
{

Button btn = (Button)e.OriginalSource;
labelInfo.Content += “\n(Window)Has pulsado en “ + btn.Name + “ “ + total();
labelInfo.Content += ‘\n’ + ((FrameworkElement)e.Source).ToString();

}
private void stackPanel_ButtonClick(object sender, RoutedEventArgs e)
{

Button btn = (Button)e.OriginalSource;
labelInfo.Content = “(StackPanel)Has pulsado en “ + btn.Name + “ “ + total();
labelInfo.Content += ‘\n’ + ((FrameworkElement)e.Source).ToString();

}
// Al indicar e.Handled = true el evento no se propagará.
private void btnUno_Click(object sender, RoutedEventArgs e)
{

labelInfo2.Content = “Botón Uno “ + total();
labelInfo.Content = “”;
e.Handled = true;

}

Fuente 4. Cambios al fuente 2 para usarlo con el fuente 3

<Window x:Class=”dnm.eventosXAML02_cs.Window1” ... >

<StackPanel Name=”stackPanel1” PreviewMouseMove=”stackPanel_MouseMove”>

<Button Name=”btnUno” Content=”Uno” MouseMove=”btnUno_MouseMove” />
<Button Name=”btnDos” Content=”Dos” MouseMove=”btnDos_MouseMove” />
<Label Name=”labelInfo” Content=”Info” />
<Label Name=”labelInfo2” Conte