|
Introduzione:
Come i precedenti ed i successivi, questo articolo è una traduzione della serie dei Getting Started di Windows Presentation foundation che si trovano su MSDN. Indicherò i link agli articoli originali in inglese e i link correlati saranno tutti alla versione inglese, fatto salvo che, man mano che tradurrò gli articoli più interessanti aggancerò anche la versione in italiano. I link agli articoli saranno effettuati con i due segnalini standard:
 che porterà alla versione originale inglese. che porterà alla versione italiana quando questa sarà scritta.
Gli argomenti trattati sono i seguenti:
Prerequisiti
Per l’argomento trattato in questo articolo, si presume abbiate una conoscenza di base del Common Language Runtime(CLR) e della programmazione a oggetti (Object Oriented Programming), così come abbiate chiaro concetto di Albero degli Elementi e delle connessioni che intercorrono fra gli elementi del WPF. Allo scopo di seguire gli esempi relativi all’argomento, dovreste inoltre conoscere le basi del Linguaggio Estensibile di Markup per le Applicazioni XAML [eXtensible Appication Markup Language n.d.t.] e sapere come sviluppare una elementare applicazione WPF. Per maggiori informazioni, vedi Iniziare ad Utilizzare Windows Presentation Foundation e Panoramica di XAML .
Cos’è un’Evento Pilotato?
Un’evento pilotato è un evento che è supportato dalla classe RoutedEvent e dal sistema di eventi di Windows Presentation Foundation (WPF). Un’evento pilotato può invocare i gestori che si trovano sui diversi listeners [ascoltatori n.d.t.] dell’albero degli elementi di una applicazione. Questo articolo offre ulteriori dettagli riguardo al progetto, allo scopo ed al comportamento degli eventi pilotati, e descrive come e quando gestire un’evento pilotato.
Una tipica applicazione WPF contiene numerosi elementi. Sia l'applicazione creata usando codice o caricando XAML, gli elementi [che la compongono n.d.t.] esistono e sono rapportati gli uni agli altri come elementi di un albero.
Il modello di evento pilotato vi consente di usare l’albero degli elementi e di trasmettere un evento lungo un percorso dopo che esso è stato sollevato. L’itinerario [(route) dell'evento n.d.t.] può essere percorso in una di due direzioni. L’evento può invocare [invoke n.d.t.] i gestori che si trovano sui listeners alla radice dell’albero degli elementi, e quindi propagarsi verso i successivi elementi figlio [child elements n.d.t.] lungo i nodi [nodes n.d.t.] dell’albero in direzione del nodo dell’elemento ha generato l’evento. Oppure, l’evento può richiamare i listeners situati sull’elemento sorgente, e quindi propagarsi verso il successivo elemento genitore fino al raggiugimento della radice dell’albero degli elementi.
Codice per un Evento pilotato
Un’evento pilotato è un’evento del CLR supportato dalla classe RoutedEvent e registrato mediante il sistema di eventi del WPF. L’istanza del RoutedEvent ottenuta dalla registrazione è rappresentata da un campo public static readonly all’interno della classe che lo registra e quindi "prende possesso" dell’evento pilotato. Il supporto è implementato eseguendo l’overriding [sovrapposizione n.d.t.] delle implementazioni dei metodi add e remove dell’evento, le quali, di solito sono lasciate come un default implicito che utilizza l’appropriata sintassi language-specific [specifica del linguaggio n.d.t.] dell’evento per aggiungere o rimuovere i gestori dell’evento. Questo è concettualmente simile al modo in cui una proprietà subordinata viene supportata da un campo rappresentato da una DependencyProperty e registrata per mezzo del sistema di property del WPF.
L’esempio seguente mostra la dichiarazione dell'evento pilotato Tap, includendo la sua registrazione e generazione del campo identificativo e le implementazioni di add e di remove.
public static readonly RoutedEvent
TapEvent = EventManager.RegisterRoutedEvent("Tap",
RoutingStrategy.Bubble, typeof(RoutedEventHandler),
typeof(MyButtonSimple));
// Provide CLR accessors for the event
public event RoutedEventHandler Tap
{
add { AddHandler(TapEvent, value); }
remove { RemoveHandler(TapEvent, value); }
}
Gestori di eventi e codifica XAML
Per collegare un gestore ad un’evento utilizzando la codifica XAML, dichiarate il nome di evento come un’attributo sull’elemento esso è infatti un listener di eventi.
<Button Click="b1SetColor">buttonButton>
La sintassi di XAML per gli eventi è la stessa, indipendentemente dal fatto che l’evento collegato al gestore sia implementato come un’evento pilotato o meno. Per maggiori informazioni riguardo al collegamento di gestori di eventi in XAML, vedi Panoramica di XAML .
Perché utilizzare gli Eventi Pilotati?
Uno scenario facilmente comprensibile, in cui l’utilizzo di eventi pilotati è vantaggioso, è quello in cui raggruppate una serie di controlli che interagiscono tutti insieme. L’applicazione può essere costruita in modo che che i controlli condividano un’elemento genitore. L’elemento genitore è un listener comune per gli eventi pilotati, che utilizza lo stesso gestore di evento tutte le volte che uno dei controlli scatena un particolare evento. Ad esempio, considerate ciò che potreste fare in un un piccolo modulo di una più ampia applicazione:
Un’insieme di bottoni raggruppati
Per questo modulo, potrebbe non essere necessario scrivere gestori eventi separati per ciascun bottone e nemmeno utilizzare la keyword Handles di Microsoft Visual Basic.NET per gestire tutte e tre le istanze. Utilizzare gli eventi pilotati è vantaggioso perchè uno dei bottoni produrrà un’evento pilotato risalente [bubbling n.d.t.], e può predisporre un comune gestore di eventi sul genitore di tutti e tre i bottoni. L’interfaccia utente(UI) sopra illustrata potrebbe essere costruita in XAML con code-behind, nel modo seguente:
<Border Height="50" Width="300" BorderBrush="Gray" BorderThickness="1">
<StackPanel Background="LightGray" Orientation="Horizontal" Button.Click="CommonClickHandler">
<Button Name="YesButton" Width="Auto" >YesButton>
<Button Name="NoButton" Width="Auto" >NoButton>
<Button Name="CancelButton" Width="Auto" >CancelButton>
StackPanel>
Border>
private void CommonClickHandler(object sender, RoutedEventArgs e)
{
FrameworkElement feSource = e.Source as FrameworkElement;
switch (feSource.Name)
{
case "YesButton":
// do something here ...
break;
case "NoButton":
// do something ...
break;
case "CancelButton":
// do something ...
break;
}
e.Handled=true;
}
Poichè i listeners di eventi e le sorgenti di eventi non hanno la necessità di condividere un comune evento nella loro gerarchia, potete utilizzare l’intera somma degli eventi pilotati come una teorica [conceptual n.d.t.] "interfaccia" per mezzo della quale elementi diversi nell’applicazione possono scambiarsi informazioni relative agli eventi. Questo concetto di "interfaccia" per gli eventi pilotati è particolarmente appropriato per gli eventi di Input [da device n.d.r.].
Strategie di Routing
Gli eventi pilotati utilizzano una delle tre seguenti strategie di routing:
- Diretta: Solo allo stesso elemento di sorgente viene data la possibilità di richiamare i gestori in risposta [all'evento n.d.t.]. Ciò è analogo al "routing" che Windows Forms e altre librerie Microsoft .NET utilizzano per gli eventi.
- Tunnelling (Effetto discendente): Inizialmente sono richiamati i gestori di eventi che si trovano alle radici dell’albero degli elementi. L’evento quindi, si propaga attraverso i successivi elementi figlio, lungo il i nodi dell’albero, in direzione del nodo dell’elemento sorgente dell’evento (l’elemento che ha sollevato l’evento).
- Bubbling (Effetto risalente): I gestori di eventi di una sorgente di eventi, sono richiamati. L’evento quindi si propaga attraverso gli elementi genitore fino al raggiungimento della radice dell’albero degli elementi.
Il concetto di Handled
Tutti gli eventi pilotati condividono una classe comune per i dati dell'evento [quella passata come parametro e nell'event argument n.d.r.] RoutedEventArgs. La RoutedEventArgs definisce la property Handled, la quale fornisce un valore booleano. Lo scopo di Handled è di permettere ad ogni gestore di eventi lungo il percorso [dell'evento n.d.t.], di contrassegnare l’evento come gestito impostando il valore di Handled a true [vero n.d.t.]. I dati dell’evento, dopo essere stati elaborati dal gestore di un’elemento lungo il percorso, vengono riportati a ognuno dei listener che si trovano lungo il medesimo percorso. Il valore della property Handled possiede uno speciale significato che riguarda il modo in cui un evento viene trasmesso lungo il percorso. Se la property Handled nei dati di un’evento pilotato è true, allora i gestori che ascoltano quell’evento su altri elementi, non vengono più richiamati, per quell’istanza dell' evento. Ciò è vero sia per i gestori collegati via XAML, sia per i gestori aggiunti mediante la sintassi di gestori di evento del codice specifico del linguaggio [language-specific n.d.r.] come ad esempio += [C# n.d.r.] o Handles[VB n.d.r.]. Nei più comuni scenari di gestione eventi, classificare un’evento come gestito mediante l’impostazione di Handled a true, "fermerà" il routing sia nel percorso discendente[tunneling n.d.t.] che in quello risalente [bubbling n.d.t.].
Tuttavia,c’è un meccanismo per mezzo del quale i listeners possono ancora richiamare i gestori in risposta agli eventi pilotati quando Handled è posto a true nei dati dell’evento. Questo meccanismo può essere utilizzato solo mediante codice, oppure tramite EventSetter.
- Via codice: invece di utilizzare la sintassi specifica del linguaggio che si applica agli per eventi del CLR generici, usare il metodo di WPF AddHandler e specificare il valore di handledEventsToo uguale a true.
- In un EventSetter: impostate l’attributo HandledEventsToo uguale a true.
In aggiunta al comportamento che lo stato di Handled produce sugli eventi pilotati, il concetto di Handled ha anche implicazioni sul modo in cui potreste progettare la vostra applicazione e scrivere l’eventuale codice dei gestori evento. Potete immaginare Handled come un semplice protocollo esposto dagli eventi pilotati. Il modo in cui userete questo protocollo riguarda voi e le vostre necessità, ma la funzionalità proposta [dai progettisti n.d.r.] è la seguente:
- Se un’evento è classificato come gestito, non ha la necessità di essere gestito di nuovo.
- Se un’evento non è classificato come gestito, o gli altri listeners hanno scelto di non registrare un gestore, o i gestori che sono stati registrati scelgono di non manipolare i dati dell’evento impostando Handled a true. (Oppure, il listener in corso è il primo listener che ha la possibilità di gestire l’evento.) In questo caso, l’evento può essere gestito su quel listener, o lasciato non-gestito per propagarsi, verso il successivo listener.
Questa funzionalità [proposta n.d.t.] è rafforzata dal comportamento di routing precedentemente menzionato: è più complesso (sebbene possibile in alcuni casi) collegare i gestori agli eventi pilotati che saranno richiamati anche se un secondo gestore lungo il percorso ha impostato Handled come true.
Per maggiori informazioni riguardo Handled, la gestione degli eventi a livello di classe, e consigli riguardo a quando è appropriato classificare un’evento come Handled, vedi Impostare gli Eventi Pilotati come Gestiti e Gestione a livello di Classi .
Gestori a livello di Classe
Quando definite una classe, potete anche definire un gestore a livello di classe per un evento che è membro, dichiarato o ereditato, della vostra classe. Per un’istanza della classe, i gestori di classe sono invocati prima di qualsiasi gestore dei listener di istanza, quando l’evento raggiunge un elemento lungo il suo percorso.
Alcuni controlli di WPF hanno gestori di classe impliciti per alcuni eventi. Questo potrebbe far apparire l’evento come non sollevato, in realtà esso è gestito a livello di classe e può, potenzialmente, essere ulteriormente gestito dai vostri gestori d’istanza, usando determinate tecniche. Per maggiori informazioni, vedi Impostare gli Eventi Pilotati come Gestiti e Gestione a livello di Classe .
Collegare ed Implementare un Gestore di Eventi per un Evento Pilotato
Per collegare un gestore di eventi in XAML, aggiungete semplicemente il nome di evento ad un’elemento come un attributo e impostate il valore di attributo al nome del vostro gestore di evento, il quale implementa un’appropriato delegate, come nel seguente esempio.
<Button Click="b1SetColor">buttonButton>
b1SetColor contiene un codice che gestisce l’evento Click, e deve avere la stessa firma del delegato RoutedEventHandler, cioè il delegato del gestore di evento per l’evento Click, come nel seguente esempio.
Il primo parametro di un delegato di gestore di evento, specifica l’elemento al quale il gestore di evento è collegato; il secondo parametro specifica i dati dell’evento.
void b1SetColor(object sender, RoutedEventArgs args)
{
//logica di gestione dell'evento click
...
}
RoutedEventHandler è il delegato di base del gestore di evento pilotato. Per eventi pilotati più specifici che riguardano determinati controlli o scenari, i delegati dei gestori di evento pilotato diventano anch’essi più specifici. Ad esempio, in un comune scenario di data binding, potreste gestire l’evento SourceUpdated. Il vostro gestore potrebbe implementare il delegate EventHandler. Utilizzando un delegate più specifico, potete elaborare un DataTransferEventArgs nel gestore e leggere le proprietà rilevanti per la vostra gestione dal parametro contenente i dati dell'evento. In questo scenario, dovete conoscere specificamente la Property a cui i dati collegati sono stati modificati.
Per l’esempio completo di come collegare un gestore di evento ad un’elemento usando XAML, vedi Come Impostare le Proprietà di Sfondo del Bottone .
Collegare un gestore ad un’evento pilotato in una applicazione creata via codice è semplice. Gli eventi pilotati hanno, quasi sempre, implementazioni di background per aggiungere o rimuovere logica che permettono ai gestori di essere aggiunti tramite la sintassi specifica del linguaggio usato. I gestori di eventi pilotati possono anche essere collegati mediante il metodo di helper AddHandler. Il seguente è un’esempio di utilizzo del metodo helper:
void MakeButton()
{
Button b2 = new Button();
b2.AddHandler(Button.ClickEvent, new RoutedEventHandler(Onb2Click));
}
void Onb2Click(object sender, RoutedEventArgs e)
{
//logic to handle the Click event
}
Il prossimo esempio mostra la sintassi dell’operatore C# ( Microsoft Visual Basic .NET ha una sintassi dell’operatore lievemente diversa a causa della sua gestione di indirezione).
void MakeButton2()
{
Button b2 = new Button();
b2.Click += new RoutedEventHandler(Onb2Click2);
}
void Onb2Click2(object sender, RoutedEventArgs e)
{
//logic to handle the Click event
}
Per un’esempio di come aggiungere un gestore di evento via codice, vedi Come Aggiungere un Gestore di Evento Usando il Codice .
Usando Microsft Visual Basic .NET, potete anche utilizzare la keyword Handles per assegnare gestori, come parte delle dichiarazioni dei gestori stessi. Per maggiori informazioni, vedi La Gestione di Eventi in Visual Basic e in WPF .
Eventi Collegati
Il linguaggio XAML definisce anche un tipo speciale di evento chiamato evento collegato [Attached event n.d.t.]. Esso vi permette di collegare il gestore di un particolare evento ad un elemento figlio piuttosto che al genitore che realmente definisce l’evento, anche se né l’oggetto che potenzialmente solleva l’evento, né l’istanza destinazione della gestione definisca, o altrimenti "possieda" quell’evento nel proprio namespace.
In WPF gli eventi collegati sono comuni in alcune aree ove c'è una astrazione a livello di servizio, come ad esempio per gli eventi sollevati dalla classe statica Mouse. In WPF, gli eventi collegati sono supportati da un campo di tipo RoutedEvent, ma non espongono un evento CLR che possa essere usato per aggiungere e rimuovere gestori. Potete aggiungere gestori per gli eventi pilotati sia tramite il metodo accessorio Add*Handler della classe definita via codice, sia servendovi dell’utilizzo dell’attributo typename.eventname di XAML.
Nomi di Eventi Qualificati nella codifica XAML
Sono un'altro metodo di descrizione con sintassi simile al typename.eventname degli eventi collegati, ma non sono, a rigore, un uso degli eventi collegati. Si usa quando si collegano eventi di elementi figlio ad un genitore comune, per beneficiare del routing. Consideriamo ancora questo esempio:
<Border Height="50" Width="300" BorderBrush="Gray" BorderThickness="1">
<StackPanel Background="LightGray" Orientation="Horizontal" Button.Click="CommonClickHandler">
<Button Name="YesButton" Width="Auto" >YesButton>
<Button Name="NoButton" Width="Auto" >NoButton>
<Button Name="CancelButton" Width="Auto" >CancelButton>
StackPanel>
Border>
Qui, il listener dell’elemento genitore che è effettivamente collegato ad un gestore, è uno StackPanel. Tuttavia esso collega un gestore ad un evento che è stato dichiarato sulla classe Button (effettivamente su ButtonBase, ma disponibile su Button per ereditarietà). Button "possiede" l'evento, ma il sistema degli eventi pilotati consente al gestore per qualsiasi evento pilotato di essere collegato al listener d'istanza di ogni DependencyObject. Il namescope [scopo del nome n.d.t.] di default di questi nomi di evento definiti via attributo qualificato è normalmente il namespace di default del WPF, ma potete anche specificare namespaces/namescopes prefissati per eventi personalizzati. Per maggiori informazioni, vedi Mappatura di Namespaces e Namescopes in XAML .
Eventi di Input
Una applicazione degli eventi pilotati all’interno della piattaforma WPF riguarda gli eventi di input. In WPF, gli eventi discendenti [tunnelling events n.d.t.] sono convenzionalmente preceduti dalla parola Preview. Gli eventi di input spesso risultano essere in coppia, uno è l’evento risalente [bubbling event n.d.t.] e l’altro l’evento discendente [tunnelling event n.d.t.]. Per esempio, l’evento KeyDown e l’evento PreviewKeyDown hanno la stessa firma, il primo è l’evento di input risalente [bubbling event n.d.t.] ed il secondo è l’evento di input discendente [tunnelling event n.d.t.]. Occasionalmente gli eventi di input hanno solo la versione risalente, oppure solo la versione diretta. All’interno della documentazione, gli argomenti relativi all'evento avranno un cross-reference agli eventi analoghi con strategie di routing alternative, se tali eventi esistono, e le sezioni nelle pagine di riferimento chiariranno le strategie di routing per ciascun evento pilotato.
Gli eventi di input che risultano essere in coppia sono implementati in modo che una singola azione di input dell’utente, ad esempio la pressione del pulsante di un mouse solleverà entrambi gli eventi della coppia in sequenza. Per primo sarà sollevato l’evento discendente [tunneling n.d.r.] che seguirà il suo percorso, poi lo stesso accadrà per l’evento risalente [bubbling n.d.t.]. I due eventi condivideranno letteralmente la stessa istanza di dati dell'evento. I listeners assieme ai gestori degli eventi discendenti hanno la prima occasione di impostare l’evento come gestito [Handled n.d.t.]. Se un’elemento lungo il percorso di tunnelling ha marcato l’evento come gestito, i dati dell’evento già gestito sono inviati all’evento risalente, e normalmente i gestori collegati agli equivalenti eventi risalenti non saranno richiamati. In apparenza, sarà come se l’evento risalente gestito [Handled n.d.t.] non sia mai stato sollevato.
Per illustrare come funziona l'elaborazione di un evento di input, consideriamo il seguente esempio. Nella seguente illustrazione ad albero, elemento foglia [leaf element n.d.t.] #2 è la sorgente sia dell’evento PreviewMouseDown che dell’evento MouseDown.
Evento di Input Risalente e Discendente
L’ordine di elaborazione dell’evento è il seguente:
- PreviewMouseDown (tunnel) sull’elemento radice.
- PreviewMouseDown (tunnel) sull’elemento intermedio # 1.
- PreviewMouseDown (tunnel) sull’elemento sorgente # 2.
- MouseDown (bubble) sull’elemento sorgente # 2.
- MouseDown (bubble) sull’elemento intermedio # 1.
- MouseDown (bubble) sull’elemento radice.
Un delegate del gestore di un evento pilotato fornisce i referimenti ai due oggetti: l’oggetto che ha sollevato l’evento e l’oggetto in cui il gestore è stato richiamato. Quest’ultimo è l’oggetto riportato dal parametro sender [mittente n.d.t.]. Invece l’oggetto in cui l’evento è stato sollevato per primo è riportato dalla property Source [sorgente n.d.t.] nei dati dell’evento. Un evento pilotato può continuare ad essere sollevato e gestito dallo stesso oggetto, in quel caso sender e Source sono identici (questo è il caso delle Fasi [Steps n.d.t.] 3 e 4 nella lista di esempio di elaborazione dell’evento sopra riportato).
A causa dell’effetto discendente e risalente, gli elementi genitore ricevono gli eventi di input là dove la property Source è uno dei loro elementi figlio. Nel momento in cui sarà importante conoscere qual è l’elemento sorgente, lo potrete identificare mediante l’accesso alla property Source.
Di solito, una volta che l’evento di input è marcato Handled, i successivi gestori non sono richiamati. Generalmente, dovreste marcare gli eventi di input come gestiti non appena il primo gestore che fornisce la gestione di logica della vostra specifica applicazione è stato eseguito.
L’eccezione a questa regola generale riguardo alla condizione di Handled, è che i gestori di eventi di input che sono marcati per ignorare deliberatamente la condizione di Handled dei dati di evento, verranno comunque richiamati lungo entrambe i percorsi [vedi il concetto di Handled n.d.t.]. Per maggiori informazioni, vedi Eventi di Anteprima .
Il modelli dei dati di evento condivisi tra gli eventi discendenti e risalenti, e il sollevamento sequenziale prima degli eventi discendenti e poi di quelli risalenti, non è un concetto generalmente valido per tutti gli eventi pilotati. Quel comportamento è specificatamente implementato in base al modo in cui i dispositivi [devices n.d.t.] di input scelgono di sollevare e connettere le coppie di eventi di input. Implementare i vostri eventi di input personalizzati è uno scenario avanzato, ma quando ne avrete la necessità, potete scegliere di seguire questo modello anche per i vostri eventi di input.
Alcune classi scelgono di gestire a livello di classe alcuni eventi di input, generalmente con l’intenzione di ridefinire ciò che un particolare evento di input comandato dall’utente [user-driven n.d.t.] significa all’interno di quel controllo, e sollevare un nuovo evento. Per maggiori informazioni, vedi Impostare Eventi Pilotati come Gestiti, e Gestione di Classe .
Per maggiori informazioni sull’input e su come esso e gli eventi interagiscono nei tipici scenari di applicazione, vedi Panoramica dell'Input .
EventSetters [assegnatori di eventi n.d.t.] EventTriggers [scatenatori di eventi n.d.t.]
Negli stili o nei modelli, potete includere in XAML una parziale dichiarazione per la gestione degli eventi nel markup(codifica) utilizzando un EventSetter. Quando il modello o lo stile sono applicati, il gestore di referenziato viene aggiunto all’istanza a cui il modello è applicato. Potete dichiarare solo un EventSetter per ogni evento pilotato. Il seguente ne è un esempio. Osservate che il metodo di riferimento b1SetColor qui è ancora in un file di code-behind.
<StackPanel
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
x:Class="SDKSample.EventOvw2"
Name="dpanel2"
Initialized="PrimeHandledToo">
<StackPanel.Resources>
<Style TargetType="{x:Type Button}">
<EventSetter Event="Click" Handler="b1SetColor"/>
Style>
StackPanel.Resources>
<Button>Click meButton>
<Button Name="ThisButton" Click
="HandleThis">Raise event, handle it, use handled=true handler to get it anywaysButton>
StackPanel>
Il vantaggio qui ottenuto è che lo stile o il modello è in grado di contenere una grande quantità di altre informazioni che potrete applicare a qualsiasi Button della vostra applicazione ed essendo l’EventSetter parte di quello stile, promuove il riutilizzo del codice anche a livello di markup. Inoltre esso porta l'astrazione dei nomi dei metodi ad una forma più avanzata rispetto a quella di una normale applicazione di markup di pagina.
Un'altra sintassi specializzata che si sovrappone all’evento e alle aree teoriche di animazione di WPF è un EventTrigger. Come per l’EventSetter, solamente gli eventi pilotati potranno essere utilizzati per un EventTrigger. Normalmente un EventTrigger è dichiarato come parte di uno stile o di un modello, ma può anche essere dichiarato sugli elementi di livello di pagina [page-level n.d.t.] come parte della collezione Trigger. Un EventTrigger vi abilita a specificare uno Storyboard che verrà eseguito ogni volta che un evento pilotato raggiungerà, lungo il suo percorso, un elemento che ha dichiarato un EventTrigger per quel determinato evento. Il vantaggio di un EventTrigger rispetto alla semplice gestione dell’evento che provochi l'esecuzione di uno Storyboard, è quello di fornire un controllo migliore sullo Storyboard e sul suo comportamento a run-time. Per maggiori informazioni, vedi Come Usare gli EventTrigger per Controllare uno Storyboard Dopo il suo Avvio .
Ulteriori Informazioni riguardo gli Eventi Pilotati
Questa panoramica parla degli eventi pilotati si occupa soprattutto del punto di vista della descrizione dei concetti di base e fornisce un primo orientamento su come e quando agire sugli eventi pilotati già presenti nei vari elementi di base e controlli. Comunque, gli eventi pilotati sono un meccanismo che anche una qualsiasi classe derivata da DependencyObject può utilizzare e voi potete creare i vostri personali eventi pilotati sulla vostra classe personalizzata insieme a tutto il supporto necessario, come ad esempio classi dati di evento [EventArgs n.d.r.] specializzate e delegati. Per maggiori informazioni riguardo eventi personalizzati, vedi Come Creare Eventi Pilotati Personalizzati .
© 2007 Microsoft Corporation
Trademark information is available at http://www.microsoft.com/library/toolbar/3.0/trademarks/en-us.mspx
Traduzione a cura di Patrizia Cosolo, Revisione tecnica a cura di Sabrina Cosolo.
|