UIElement.PointerEntered Ereignis
Definition
Wichtig
Einige Informationen beziehen sich auf Vorabversionen, die vor dem Release ggf. grundlegend überarbeitet werden. Microsoft übernimmt hinsichtlich der hier bereitgestellten Informationen keine Gewährleistungen, seien sie ausdrücklich oder konkludent.
Tritt auf, wenn ein Zeiger in den Treffertestbereich dieses Elements eintritt.
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"/>
Ereignistyp
Hinweise
Das PointerEntered-Ereignis wird als Reaktion darauf ausgelöst, dass sich ein Zeiger in den Begrenzungsbereich des Elements bewegt. Touch-, Maus- und Stift-/Eingabestiftinteraktionen werden als Zeigereingaben in der UWP-App empfangen, verarbeitet und verwaltet. Jedes dieser Geräte und ihre Interaktionen können ein PointerEntered-Ereignis erzeugen. Weitere Informationen finden Sie unter Behandeln von Zeigereingaben und den anderen Anmerkungen in diesem Thema.
PointerEntered ist ein Routingereignis. Weitere Informationen zum Konzept für routingfähige Ereignisse finden Sie unter Übersicht über Ereignisse und routingfähige Ereignisse.
Verwenden Sie einen auf PointerEventHandler basierenden Handler, um dieses Ereignis zu behandeln.
Bei Toucheingabeaktionen und interaktionsspezifischen Ereignissen oder Manipulationsereignissen, die aus einer Toucheingabeaktion resultieren, muss ein Element bei Treffertests sichtbar sein, damit es der Ereignisquelle entsprechen und das der Aktion zugeordnete Ereignis auslösen kann. UIElement.Visibility muss sichtbar sein. Andere Eigenschaften abgeleiteter Typen wirken sich ebenfalls auf die Treffertestsicht aus. Weitere Informationen finden Sie unter Übersicht über Ereignisse und Routingereignisse.
PointerEntered unterstützt die Möglichkeit, Ereignishandler an die Route anzufügen, die aufgerufen wird, auch wenn die Ereignisdaten für das Ereignis als Behandelt gekennzeichnet sind. Weitere Informationen finden Sie unter AddHandler.
Bestimmte Windows-Runtime-Steuerelemente verfügen möglicherweise über eine klassenbasierte Behandlung für das PointerEntered-Eingabeereignis. Wenn ja, verfügt das Steuerelement wahrscheinlich über eine Überschreibung für die Methode OnPointerEntered. In der Regel wird das Ereignis nicht vom Klassenhandler behandelt, sodass das PointerEntered-Ereignis weiterhin von Ihrem Benutzercode für das Steuerelement in Ihrer Benutzeroberfläche behandelt werden kann. Weitere Informationen zur Funktionsweise der klassenbasierten Behandlung für Ereignisse finden Sie unter Übersicht über Ereignisse und Routingereignisse.
PointerEntered für Maus- und Stift-/Eingabestift
Ein Mauseingabegerät verfügt über einen Bildschirmcursor, der immer sichtbar ist, wenn sich die Maus bewegt, auch wenn gerade keine Maustaste gedrückt wird. Ein PointerEntered-Ereignis geht dem ersten PointerMoved-Ereignis voran, das vom -Element ausgelöst wird. Ein ähnliches Verhalten ist für die Eingabe eines Stiftgeräts verfügbar, bei dem die Eingabegeräte erkennen können, dass der Eingabestift mit dem Mauszeiger direkt über die Eingabegeräteoberfläche (IsInRange) zeigt, ihn aber nicht berührt. Maus- und Stiftgeräteeingaben lösen daher PointerEntered-Ereignisse in etwas anderen Fällen aus als Touchereignisse. Weitere Informationen finden Sie unter Mausinteraktionen.
PointerEntered für Toucheingaben
Ein Berührungspunkt kann nur erkannt werden, wenn ein Finger die Oberfläche berührt. Wenn eine Touchaktion zu einem PointerPressed-Ereignis führt, wird diesem Ereignis sofort ein PointerEntered-Ereignis vorangestellt, wobei alle Ereignisdaten dieselben Informationen für die beiden Ereignisse sind (gleiche Zeiger-ID, gleiche Position usw.). Mit anderen Worten, der Zeiger wird so betrachtet, dass er das Element in dem Moment eingibt und die Position angibt, an der das Element von einem Touchpunkt berührt wird.
Alternativ generiert ein Touchpoint PointerEntered, wenn ein Zeiger während der Bewegung in konstantem Kontakt mit der Oberfläche bleibt und die Treffertestgrenzen eines Elements eingibt. Für diese Art von Touchaktionen ist es auch möglich, dass die Aktion als Manipulation oder als Geste und nicht als Zeigerereignis verarbeitet werden kann. Weitere Informationen finden Sie unter Behandeln von Zeigereingaben.
Routingereignisverhalten für PointerEntered
PointerEntered ist ein Routingereignis. Weitere Informationen zum Konzept für routingfähige Ereignisse finden Sie unter Übersicht über Ereignisse und routingfähige Ereignisse. Sie können mehrere PointerEntered-Ereignisse für Elemente in einer XAML-Benutzeroberfläche definieren, einschließlich für Elemente, die sich in einer beziehung zwischen übergeordneten und untergeordneten Elementen befinden. In einer typischen Ui-Komposition befinden sich die untergeordneten Elemente innerhalb der Grenzen eines übergeordneten Elements, sodass das PointerEntered-Ereignis zuerst für das übergeordnete Element auftritt, wenn der Zeiger in das übergeordnete Element verschoben wird, und dann für das untergeordnete Element, wenn sich der Zeiger dorthin bewegt. Das PointerEntered-Ereignis wird normalerweise nicht an das übergeordnete Element weitergeleitet, wenn es vom untergeordneten Element ausgelöst wird, da sich der Zeiger konzeptionell bereits innerhalb der übergeordneten Grenzen befindet und es für das Eingabesystem verwirrend wäre, das PointerEntered-Ereignisereignis auch an das übergeordnete Element weiterzuleiten. In der Regel möchten Sie nicht, dass PointerEntered-Ereignisse trotzdem weitergeleitet werden, Sie möchten sie nur vom Absender verarbeiten. Sie können das Ereignisrouting explizit verhindern, indem Sie Handled in Ihrem Handler auf true festlegen.
In seltenen Fällen ist es möglich, eine PointerEntered-Ereignisblase für das übergeordnete Element anzuzeigen. Wenn Sie beispielsweise einen RenderTransform-Wert verwendet haben, um ein untergeordnetes Element außerhalb der Grenzen des übergeordneten Elements zu offseten, wird das Ereignis beim Eingeben des untergeordneten Elements in das übergeordnete Element eingeblasen und gibt die Ereignisinformationen an, die davon berichtet werden, wie das untergeordnete Element das Ereignis ausgelöst hat.
Zeigererfassung
Wenn ein anderes Element den Zeiger erfasst hat, wird PointerEntered nicht ausgelöst, auch wenn der erfasste Zeiger die Grenzen eines Elements eingibt. Wenn die Zeigererfassung jedoch freigegeben wird, während sich der Zeiger über das Element befindet, wird PointerEntered ausgelöst, selbst wenn der Zeiger in diesem Fall nicht mehr verfügbar war. Der Wert von GetCurrentPoint aus Ereignisdaten kann ein Punkt in der Mitte eines Elements und nicht ein Punkt an seinen Rändern sein, da sich der Zeiger bereits über das Element befand, als die Erfassung freigegeben wurde. Weitere Informationen zur Zeigererfassung finden Sie unter CapturePointer - oder Mausinteraktionen.
ZeigerVisualstatus für Steuerelemente anzeigen
Steuerelemente mit Steuerelementvorlagen können visuelle Zustände anwenden, die nur aktiv sind, wenn sich ein Zeiger über die Grenzen des Steuerelements befindet. Sie müssen pointerEntered oder PointerExited nicht immer verarbeiten, um dieses Verhalten abzurufen oder zu ändern. Möglicherweise müssen Sie das Steuerelement neu erstellen. Wenn Sie von einem vorhandenen Steuerelement ableiten, das bereits über die Eingabebehandlung auf niedriger Ebene verfügt, die visuelle Zustände aufruft, sollten Sie einen visuellen Zustand mit dem Namen "PointerOver" in der VisualStateGroup "CommonStates" bereitstellen, und die integrierte Steuerelementlogik lädt diesen visuellen Zustand, wenn sich ein Zeiger über das Steuerelement befindet. Für Steuerelemente, die aufgerufen oder ausgewählt werden können, z. B. Button oder ListViewItem, ist häufig ein visueller Zustand für zeigerüber vorhanden. Wenn Sie von einer Basisklasse wie Control ableiten, die nicht über eine integrierte Eingabeereignisbehandlung verfügt, die visuelle Zustände aufruft, müssen Sie möglicherweise OnPointerEntered und OnPointerExited überschreiben, um dieses Verhalten zu erhalten. Weitere Informationen finden Sie unter Storyboardanimationen für visuelle Zustände.
Windows 8-Verhaltensweise
Für Windows 8 wird das PointerEntered-Ereignis im Allgemeinen nicht ausgelöst, wenn sich der Bildschirmcursor (oder der Eingabestift oder der Touchpoint) nicht tatsächlich bewegt hat. Beispielsweise wird PointerEntered nicht ausgelöst, wenn die Maus und ihr Bildschirmcursor nicht stehen bleiben und ein Objekt mit einem PointerEntered-Handler seine Position übersetzt oder anderweitig so angepasst wird, dass es sich unter dem Bildschirmcursor bewegt. Oder PointerEntered wird nicht ausgelöst, wenn ein Element wie ein Popup- oder Flyout verschwindet und sich der Zeiger jetzt auf ein neues Element befindet (der Zeiger wurde jedoch noch nicht verschoben). Im Zusammenhang damit ist das PointerExited-Verhalten . Wenn ein Popup beispielsweise programmgesteuert geschlossen wird, wird PointerExited nicht ausgelöst, wenn sich der Zeiger nicht als Ursache für das Schließen bewegt hat. Sie erhalten weiterhin ein PointerEntered-Ereignis, wenn sich der Zeiger über das neu offenbarte Element bewegt. Ob dies geschieht, liegt jedoch beim Benutzer, und es geschieht zum Zeitpunkt der Bewegung, nicht im Moment der Kündigung. Kurz gesagt, der Versuch, das letzte Element zu verwenden, das PointerEntered für die Bestimmung des Zeigerzustands auf der App-Benutzeroberfläche ausgelöst hat, ist in Windows 8 nicht umfassend, und es gibt viele Szenarien, in denen PointerEntered und PointerExited nicht paaren . Dies wirkt sich auch auf die visuellen Zustände für Steuerelemente aus, die PointerEntered und PointerExited als Trigger verwenden.
Ab Windows 8.1 wird PointerExited für jeden Fall ausgelöst, in dem der Zeiger einmal ein PointerEntered-Ereignis ausgelöst hatte. Eine Änderung des Ui-Zustands erfolgt jedoch, wenn sich der Zeiger nicht mehr innerhalb dieses Elements befindet. Dies schließt Fälle ein, in denen das gesamte Element verschwindet. Und wenn sich der Zeiger jetzt auf ein anderes Element befindet, weil ein vorheriges Element verschwunden ist, löst dieses Element PointerEntered aus, auch wenn sich der Zeiger nie bewegt. Elemente, die ihre Sichtbarkeit programmgesteuert auf Reduziert festlegen, ist eine Möglichkeit, wie Elemente von der Benutzeroberfläche verschwinden können, und das Windows 8.1 Verhalten übernimmt dies und löst PointerExited für das Collapsed-Element und PointerEntered für das neu offenbarte Element aus.
Wenn Sie Ihren App-Code von Windows 8 zu Windows 8.1 migrieren, sollten Sie diese Verhaltensänderung berücksichtigen, da dies dazu führt, dass PointerExited und PointerEntered ausgelöst werden, wenn sie zuvor nicht ausgelöst hätten.
Apps, die für Windows 8 kompiliert wurden, aber unter Windows 8.1 ausgeführt werden, weisen weiterhin das Windows 8-Verhalten auf.