Assembly: System.Windows (in System.Windows.dll)
XMLNS for XAML: Not mapped to an xmlns.
The event is a bubbling event. This means that if multiple event handlers are registered for a sequence of objects connected by parent-child relationships in the object tree, the event is received by each object in that relationship. The event is raised by the object that directly receives the input condition that initiates the event, and then bubbles to each successive parent object. The bubbling metaphor indicates that the event starts at the object that directly receives the input condition, and works its way up the object tree. For a bubbling event, the sender available to the event handler identifies the object where the event is handled, not necessarily the object that actually received the input condition that initiated the event. To get the object that initiated the event, use the OriginalSource value of the event's RoutedEventArgs event data.
When you handle the or LostFocus events, there is no Handled property available in the event data class, and the event will continue to route upwards through the object tree and invoke all handlers. This might not always be desirable for your application's handling strategy for focus events, if you want to handle focus at various levels in your object tree. You might consider one of the following techniques:
Use a Boolean flag to record focusing state. Set your own "Handled" variable to true from the specific handler call that your design deems has appropriately handled the event. Check for this "Handled" variable in further handlers to determine whether another handler has already acted, and if one has, take no action. At the root of the object tree, handle the focus event at least for the purpose of setting "Handled" back to false to reset the state for the next focus event.
Place particular emphasis on checking or using the object values transmitted to the handler by sender and by OriginalSource in the event data. You might choose to act only if sender equals OriginalSource , or if sender is a particular named object in cases when the same focus event handler is attached to multiple objects, or similar logical operations.
Note however that knowing that focus is somewhere in an object's composited tree may be important for setting the proper visual state of the overall control. In general you should use caution when attempting to suppress further routing of focus events.
is not raised if Focus is called on the object but the object already had focus.
is raised asynchronously versus the actual focus shift, because of the design of the Windows Phone focus system. To get a synchronous focus value, use FocusManager.
Sometimes is raised twice for what appears to be one focus event from a UI perspective. This can happen if focus is not yet within the content area, but the user taps to a specific control within the content area. In this case the specific control often raises (and reports itself as OriginalSource). Initial focus into the overall content area also raises , which walks into the object tree until it finds a focusable object and reports it as that event's OriginalSource. This is can be a problem if you handle while relying on bubbling behavior deliberately. Check OriginalSource; this can often help you identify this case in your handlers.
GotFocus and OnGotFocus
Controls that inherit can provide handling for the event that acts as handler for all instances, by overriding the OnGotFocus method. As with direct handling of the event, there is no Handled property available, so OnGotFocus cannot be implemented in such a way that it suppresses the event through the Handled technique. However, OnGotFocus can be useful either for setting visual state, or for public or internal state properties. For more information, see OnGotFocus.