UIElement.PointerExited Evento

  • Riferimento

Definizione

Spazio dei nomi:
Windows.UI.Xaml
Modifica

Si verifica quando un puntatore lascia l'area di hit test di questo elemento.

public:
 virtual event PointerEventHandler ^ PointerExited;
// Register
event_token PointerExited(PointerEventHandler const& handler) const;

// Revoke with event_token
void PointerExited(event_token const* cookie) const;

// Revoke with event_revoker
UIElement::PointerExited_revoker PointerExited(auto_revoke_t, PointerEventHandler const& handler) const;
public event PointerEventHandler PointerExited;
function onPointerExited(eventArgs) { /* Your code */ }
uIElement.addEventListener("pointerexited", onPointerExited);
uIElement.removeEventListener("pointerexited", onPointerExited);
- or -
uIElement.onpointerexited = onPointerExited;
Public Custom Event PointerExited As PointerEventHandler 
<uiElement PointerExited="eventhandler"/>

Tipo evento

PointerEventHandler

Commenti

L'evento PointerExited viene generato in risposta a un puntatore che era inizialmente nell'area di delimitazione dell'elemento lasciando tale area di limite. Le interazioni tocco, mouse e penna/stilo vengono ricevute, elaborate e gestite come input puntatore nell'app UWP. Uno di questi dispositivi e le relative interazioni possono produrre un evento PointerExited. Per altre informazioni, vedere Gestire l'input del puntatore e le altre osservazioni in questo argomento.

Usare un gestore basato su PointerEventHandler per gestire questo evento.

Per le azioni tocco e per gli eventi di modifica o specifici dell'interazione che sono la conseguenza di un'azione tocco, un elemento deve essere visibile tramite hit testing per poter essere l'origine dell'evento e attivare l'evento associato all'azione. UIElement.Visibility deve essere visibile. Altre proprietà dei tipi derivati influiscono anche sulla visibilità di hit test. Per altre informazioni, vedi Panoramica degli eventi e degli eventi indirizzati.

PointerExited supporta la possibilità di collegare gestori eventi alla route che verrà richiamata anche se i dati dell'evento per l'evento sono contrassegnati come Handled. Vedere AddHandler.

I controlli di Windows Runtime specifici possono avere la gestione basata sulla classe per l'evento di input PointerExited. In tal caso, il controllo ha probabilmente un override per il metodo OnPointerExited. In genere l'evento non viene contrassegnato come gestito dal gestore della classe, quindi l'evento PointerExited può comunque essere gestito dal codice utente per il controllo nell'interfaccia utente. Per altre informazioni sulla gestione basata sulla classe per gli eventi, vedere Panoramica degli eventi e degli eventi indirizzati.

Se un altro elemento ha acquisito il puntatore, PointerExited non verrà generato anche se il puntatore acquisito lascia i limiti di un elemento. Per altre informazioni sull'acquisizione del puntatore, vedere AcquisizionePointer o Interazioni del mouse.

PuntatoreExited per l'input del mouse e penna/stilo

Un dispositivo di input del mouse ha un cursore sullo schermo visibile ogni volta che il mouse si sposta, anche se non viene premuto alcun pulsante del mouse al momento. Il comportamento simile è disponibile per l'input del dispositivo penna, in cui i dispositivi di input possono rilevare che lo stilo sta passando il puntatore del mouse sulla superficie del dispositivo di input (IsInRange) ma non toccandolo. L'input del dispositivo mouse e penna genera quindi eventi pointerExited in casi leggermente diversi rispetto agli eventi di tocco. Per altre info, vedi Interazioni tramite mouse. Un evento PointerExited viene generato dopo l'ultimo evento PointerMoved per l'elemento generato.

PuntatoreExited per l'input tocco

Un punto di tocco è rilevabile solo se un dito tocca la superficie. Ogni volta che un'azione tocco genera un evento PointerReleased , tale evento viene immediatamente seguito da un evento PointerExited, con tutti i dati dell'evento che corrispondono alle stesse informazioni per i due eventi (lo stesso ID puntatore, la stessa posizione e così via). In altre parole, il puntatore viene considerato come immettere l'elemento al momento e posizionare che l'elemento viene toccato da un punto di tocco.

In alternativa, un punto di tocco genererà PointerExited se tale puntatore rimane in contatto costante con la superficie mentre si sposta, è stato sopra l'elemento inizialmente e quindi chiude i limiti di hit testing di un elemento. Per questi tipi di azioni di tocco è anche possibile che l'azione possa essere elaborata come manipolazione o come gesto, anziché un evento puntatore. Per altre informazioni, vedere Gestire l'input del puntatore.

Comportamento dell'evento instradato per PointerExited

PointerExited è un evento indirizzato. Per altre informazioni sul concetto di evento indirizzato, vedere Panoramica degli eventi e degli eventi indirizzati. È possibile definire più eventi PointerExited per gli elementi in un'interfaccia utente XAML, inclusi per gli elementi presenti in una relazione padre-figlio. In una composizione tipica dell'interfaccia utente, gli elementi figlio si trovano all'interno dei limiti di un elemento padre, quindi l'evento PointerExited si verificherà prima per il figlio quando il puntatore si sposta fuori dal figlio e quindi per l'elemento padre quando il puntatore si sposta completamente fuori da tale padre. L'evento PointerExited non viene in genere bollato all'elemento padre quando l'elemento figlio lo attiva, perché sarebbe confusione per il sistema di input per instradare l'occorrenza dell'evento PointerExited anche all'elemento padre. In genere non si vuole che gli eventi PointerExited instradano comunque, si vuole elaborarli solo dal mittente. È possibile impedire in modo esplicito il routing degli eventi impostando Handled su true nel gestore.

In rari casi è possibile visualizzare una bolla di evento PointerExited all'elemento padre. Ad esempio, se è stato usato un RenderingTransform per compensare un elemento figlio al di fuori dei limiti del relativo padre, le bolle di evento all'elemento padre quando l'elemento figlio viene chiuso e fornisce le informazioni sull'evento come segnalato dall'elemento figlio generato dall'evento.

Stati visivi PointerOver per i controlli

I controlli con modelli di controllo possono applicare gli stati visivi attivi solo quando un puntatore supera i limiti del controllo. Non è sempre necessario gestire PointerEntered o PointerExited per ottenere o modificare questo comportamento. Potrebbe essere necessario rielaborare il controllo. Se si deriva da un controllo esistente che dispone già della gestione di input di basso livello che richiama gli stati visivi, è necessario fornire uno stato visivo denominato "PointerOver" in "CommonStates" VisualStateGroup e la logica di controllo predefinita caricherà lo stato visivo ogni volta che un puntatore è sul controllo. Lo stato visivo per il puntatore è spesso presente nei controlli che possono essere richiamati o selezionati, ad esempio Button o ListViewItem. Se si deriva da una classe di base come Control che non ha una gestione degli eventi di input predefinita che richiama gli stati visivi, potrebbe essere necessario eseguire l'override di OnPointerEntered e OnPointerExited per ottenere questo comportamento. Usare OnPointerExited per chiamare GoToState per caricare uno stato diverso dallo stato "PointerOver", ad esempio "Normal". Per altre info, vedi Animazioni con storyboard per stati di visualizzazione.

Comportamento di Windows 8

Per Windows 8, in genere l'evento PointerEntered non verrà attivato se il cursore sullo schermo (o lo stilo o il punto di tocco) non è stato effettivamente spostato. Ad esempio, PointerEntered non viene attivato se il mouse e il relativo cursore sullo schermo rimane stazioniario e un oggetto con un gestore PointerEntered ha la sua posizione tradotta o altrimenti modificata per spostarsi sotto il cursore sullo schermo. In alternativa , PointerEntered non viene attivato se un elemento come un popup o un riquadro a comparsa scompare e il puntatore è ora su un nuovo elemento (ma il puntatore non è ancora stato spostato). Correlato a questo è il comportamento pointerExited. Ad esempio, se un popup viene ignorato a livello di codice, non verrà attivato PointerExited se il puntatore non è stato spostato come causa di ignorarlo. Si otterrebbe comunque un evento PointerEntered se il puntatore si sposta mentre si sposta sull'elemento appena rivelato, ma questo è fino all'utente che si verifica, e si verifica al momento del movimento, non il momento di chiusura. In breve, provare a usare l'ultimo elemento che ha attivato PointerEntered per la determinazione dello stato del puntatore nell'interfaccia utente dell'app non è completo in Windows 8 e ci sono molti scenari in cui PointerEntered e PointerExited non si associano. Ciò influisce sugli stati visivi per i controlli che usano PointerEntered e PointerExited come trigger.

A partire da Windows 8.1, PointerExited viene attivato per qualsiasi caso in cui il puntatore avesse attivato un evento PointerEntered, ma alcune modifiche dello stato dell'interfaccia utente si verificano in cui il puntatore non è più all'interno di tale elemento. Ciò include casi in cui l'intero elemento scompare. E se il puntatore è ora su un elemento diverso perché un elemento precedente è scomparso, tale elemento genera PointerEntered, anche se il puntatore non si sposta mai. Gli elementi che impostano visibilità su Compresso a livello di codice sono un modo in cui gli elementi potrebbero scomparire dall'interfaccia utente e gli account di comportamento Windows 8.1 per questo e verranno attivati PointerExited per l'elemento Compresso e PointerEntered per l'elemento appena rivelato.

Se esegui la migrazione del codice dell'app da Windows 8 a Windows 8.1 potresti voler tenere conto di questa modifica del comportamento, perché comporta l'esecuzione di PointerExited e PointerEntered in casi in cui non sarebbero stati attivati prima.

Le app create per Windows 8 che vengono eseguite in Windows 8.1 continuano a usare il comportamento di Windows 8.

Si applica a

Vedi anche