UIElement.PointerEntered Evento

  • Riferimento

Definizione

Spazio dei nomi:
Microsoft.UI.Xaml
Modifica

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

PointerEventHandler

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. Uno di questi dispositivi e le relative interazioni possono produrre un PointerEntered evento. Per altre informazioni, vedere Gestire l'input del puntatore e anche le altre osservazioni in questo argomento.

PointerEntered è un evento instradato. 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 PointerEntered evento precederà il primo PointerMoved evento 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 PointerEntered eventi 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 PointerEntered evento, 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 instradato. Per altre informazioni sul concetto di evento indirizzato, vedere Panoramica degli eventi e degli eventi indirizzati. È possibile definire più PointerEntered eventi per gli elementi in un'interfaccia utente XAML, tra cui 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 figlio 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 confuso anche per il sistema di input per instradare l'occorrenza PointerEntered dell'evento anche all'elemento padre. In genere non si vuole PointerEntered instradare gli eventi, è 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 PointerEntered bolla di evento 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à generato anche se il puntatore acquisito entra nei limiti di un elemento. Tuttavia, se l'acquisizione del puntatore viene rilasciata mentre il puntatore si trova sull'elemento, verrà generato, PointerEntered 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.

Si applica a

Vedi anche