In questo antico post, descrivevo come gestire e creare event handler con il framework 1.1. Con il FW2.0 nulla è cambiato: tutti gli oggetti hanno un certo numero di eventi, a ciascuno dei quali possiamo associare un handler, ovvero un metodo privato che viene eseguito quando quell'evento viene sollevato dal CLR. Per esplorare gli eventi esposti da un certo oggetto posto su una Windows Forms, è sufficiente selezionare l'oggetto a design-time, aprire la Properties Windows e cliccare sull'icona del lampo.
Il tipo ed il numero di eventi dipende ovviamente dall'oggetto con cui abbiamo a che fare. Per creare un event handler, è sufficiente fare doppio-click sull'evento che ci interessa gestire. Per esempio, possiamo scrivere codice per l'evento FormClosing su una WF semplicemente facendo doppio-click sulla riga nella Properties Windows. Il designer di VS2005 ci porta direttamente nell'editor di codice:
private void FormEventHandler_FormClosing(object sender, FormClosingEventArgs e)
{
}
Ogni event handler è come al solito due parametri. Uno è il sender, che identifica l'oggetto che ha sollevato l'evento: è di tipo object, ovviamente. Il secondo parametro dipende dall'evento. In questo caso è di tipo FormClosingEventArgs, una classe che ci permette per esempio di annullarne la chiusura o capire chi stava chiudendo e perchè il form stava per essere chiuso.
L'esame 70-526 ci chiede due cose in particolare: use the Windows Forms designer to create event handler. Ed è quello di cui ho parlato qui sopra, ovvero saper esplorare nella Properties Windows l'evento che ci interessa e fare doppio-click. L'altra è use the Windows Forms designer to create default event handler. Questo può essere fatto molto semplicemente facendo doppio-click sull'oggetto della WF. Ogni controllo ha un default event handler, che banalmente può essere descritto come l'evento di più frequente utilizzo (ad esempio, il Click su un Button). Quando sviluppiamo nostri controlli, possiamo utilizzare l'attributo DefaultEventAttribute proprio a questo scopo.
Un'altra questione importante: connect multiple events to a single event handler. Detto in altri termini: avere un'unica routine .NET capace di rispondere a più eventi diversi. Per far questo, è ovviamente necessario che la firma della routine sia la stessa. Questa tecnica ci permette di avere un certo numero di Button sulla WF il cui event handler sull'evento Click sia lo stesso, risparmiando così codice e codice da scrivere e da debuggare. Il parametro sender di cui ho parlato prima serve proprio per questo, ovvero a discriminare quale oggetto ha sollevato l'evento. Questo può essere ottenuto anche da IDE, perchè la Properties Windows è sensibile: non solo possiamo creare nuovi event handler, ma possiamo eventualmente selezionare dalla ComboBox la routine già esistente nel codice e che si adatta a gestire l'evento correntemente selezionato.
Come avevo già detto l'anno scorso, gli eventi vengono sottoscritti al loro event handler con una semplice linea di codice, che finisce nel FormName.Designer.cs. Nel caso dell'evento FormClosing, avremo quindi:
this.FormClosing += new FormClosingEventHandler(this.FormEventHandler_FormClosing);
Questo codice è inserito nella InitializeComponent() della WF su cui stiamo lavorando. Possiamo ovviamente ottenere lo stesso risultato senza usare il designer di VS2005: se facciamo un cut & paste nell'evento Load della WF otteniamo esattemente lo stesso risultato. Questo è di fondamentale importanza quando vengono creati ed aggiunti nuovi controlli a run-time sulla WF, un po' come succede con Happy Sign, dove ogni volta che si aggiunge una firma vengono associati gli event handler necessari.
Per la questione use the code editor to override methods defined in the base class è tutto molto semplice. Dall'editor di VS2005, possiamo cominciare a scrivere un nuovo metodo usando la keyword override. L'Intellisense - che tanto stupido non è - mostra un elenco di tutti quei membri (properties, indexers e events) della classe base che possiamo ridefinire. Ciò implica diverse cose: il metodo della classe base può essere ridefinito se è stato definito virtual: per default, in C# i metodi non sono virtuali. Ciò significa che non possiamo ridefinire tutto ciò che vogliamo. Vi consiglio la lettura di questa pagina di MSDN che descrive bene tutte le implicazioni di virtual, new ed override. Se è vero che possiamo ridefinire il comportamento di un evento, possiamo comunque chiamare il metodo della classe base attraverso l'utilizzo della keyword base.
Gli ultimi due punti per questa parte dell'esame - davvero molto semplice, devo dire - riguardano manage mouse and keyboard events within Windows Forms applications. E' possibile avere una carrellata degli eventi disponibili guardando la Properties Window nella modalità Categorized. Il gruppo Key contiene 4 eventi per la tastiera (KeyDown, KeyPress, KeyUp e PreviewKeyDown), mentre il gruppo Mouse contiene 6 eventi per il mouse (MouseDown, MouseEnter, MouseHover, MouseLeave, MouseMove e MouseUp). Non sto a mettervi il link per ogni evento, vi lascio questo che elenca tutti gli eventi esposti dalla classe Control. A seconda dell'evento che decidiamo di usare, abbiamo diverse opzioni. Le elenco in breve.
L'evento MouseDown (così come MouseMove e MouseUp) fa uso della classe MouseEventArgs, che espone tra le altre cose la proprietà Button, che ci permette di capire quale bottone del mouse è stato cliccato. La stessa filosofia la si applica con la tastiera: a seconda dell'evento, possiamo capire quale tasto è stato premuto e se insieme a lui è stato premuto qualche tasto come CTRL, ALT o SHIFT (vedere la classe KeyEventArgs per maggiori informazioni). Questo può essere fatto in due modi: usando le proprietà read-only esposte da KeyEventArgs (Alt, Control e Shift) oppure leggendo il valore della proprietà Modifiers.