UIElement.PointerEntered Evento
Definizione
Importante
Alcune informazioni sono relative alla release non definitiva del prodotto, che potrebbe subire modifiche significative prima della release definitiva. Microsoft non riconosce alcuna garanzia, espressa o implicita, in merito alle informazioni qui fornite.
Si verifica quando un puntatore entra nell'area di hit test di questo elemento.
public:
virtual event PointerEventHandler ^ PointerEntered;// Register
event_token PointerEntered(PointerEventHandler const& handler) const;
// Revoke with event_token
void PointerEntered(event_token const* cookie) const;
// Revoke with event_revoker
UIElement::PointerEntered_revoker PointerEntered(auto_revoke_t, PointerEventHandler const& handler) const;public event PointerEventHandler PointerEntered;function onPointerEntered(eventArgs) { /* Your code */ }
uIElement.addEventListener("pointerentered", onPointerEntered);
uIElement.removeEventListener("pointerentered", onPointerEntered);
- or -
uIElement.onpointerentered = onPointerEntered;Public Custom Event PointerEntered As PointerEventHandler <uiElement PointerEntered="eventhandler"/>
Tipo evento
Commenti
L'evento PointerEntered viene generato in risposta a un puntatore che si sposta nell'area di delimitazione dell'elemento. 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 PointerEntered. Per altre informazioni, vedere Gestire l'input del puntatore e anche le altre osservazioni in questo argomento.
PointerEntered è un evento indirizzato. Per altre informazioni sul concetto di evento indirizzato, vedere Panoramica degli eventi e degli eventi indirizzati.
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.
PointerEntered 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 specifici Windows Runtime possono avere la gestione basata sulla classe per l'evento di input PointerEntered. In tal caso, il controllo ha probabilmente un override per il metodo OnPointerEntered. In genere l'evento non viene contrassegnato come gestito dal gestore della classe, pertanto l'evento PointerEntered 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.
Puntatore Immesso per l'input di penna 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. Un evento PointerEntered precederà il primo evento PointerMoved generato dall'elemento . 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 PointerEntered in casi leggermente diversi rispetto agli eventi di tocco. Per altre info, vedi Interazioni tramite mouse.
Puntatore Immesso 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 PointerPressed , tale evento viene immediatamente preceduto da un evento PointerEntered, 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à PointerEntered se un puntatore rimane in contatto costante con la superficie mentre si sposta e immette 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 PointerEntered
PointerEntered è un evento indirizzato. Per altre informazioni sul concetto di evento indirizzato, vedere Panoramica degli eventi e degli eventi indirizzati. È possibile definire più eventi PointerEntered per gli elementi in un'interfaccia utente XAML, inclusi per gli elementi che si trovano 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 PointerEntered si verificherà prima per l'elemento padre quando il puntatore si sposta nell'elemento padre e quindi per il puntatore quando il puntatore si sposta lì. L'evento PointerEntered non viene in genere bollato all'elemento padre quando l'elemento figlio lo attiva, perché il puntatore è già all'interno dei limiti padre e sarebbe confusione per il sistema di input per instradare l'occorrenza dell'evento PointerEntered anche all'elemento padre. In genere non si vuole che gli eventi PointerEntered vengano instradati comunque, è necessario 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 PointerEntered 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 immesso e fornisce le informazioni sull'evento come segnalato dall'elemento figlio generato l'evento.
Acquisizione puntatore
Se un altro elemento ha acquisito il puntatore, PointerEntered non verrà attivato anche se il puntatore acquisito immette i limiti di un elemento. Tuttavia, se l'acquisizione del puntatore viene rilasciata mentre il puntatore si trova sull'elemento, PointerEntered verrà generato, anche se il puntatore potrebbe essere rimasto stazioni in questo caso. Il valore di GetCurrentPoint dai dati dell'evento potrebbe essere un punto al centro di un elemento anziché un punto lungo i bordi perché il puntatore era già sopra l'elemento quando è stata rilasciata l'acquisizione. Per altre informazioni sull'acquisizione del puntatore, vedere AcquisizionePointer o Interazioni del mouse.
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. 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 si esegue la migrazione del codice dell'app da Windows 8 a Windows 8.1 potrebbe essere necessario 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.