UIElement provides a starting point for Silverlight layout characteristics; FrameworkElement adds more layout capabilities.
Much of the input behavior for objects in a Silverlight UI is defined in the UIElement class. This includes the events for keyboard, mouse and stylus input, and focus events. Some of these events are routed events. A routed event enables a built-in event handling notification system, so that a parent object can handle input events from child objects in the object tree if the event remains unhandled. This input event behavior is useful for input area grouping, and control compositing.
Although UIElement defines the events for focus reporting (GotFocus, LostFocus), UIElement does not define an API for programmatically setting the focus. However, this capability is defined by the Control class and is thus present for many Silverlight classes.
It is not common to derive from either UIElement or FrameworkElement directly. More commonly used base classes for derived custom classes are:
Hit Testing for a UIElement
There are various APIs exposed on UIElement that can affect hit testing. Hit testing is the concept by which the Silverlight plug-in and its input subsystem process the input stimulus (such as mouse clicks) coming from the browser host, and then determine which UIElement in the layout and in the visual tree should be noted as the source of the Silverlight input event. Visibility state affects all input handling by that object. A UIElement that is not visible does not participate in hit testing and does not receive input events, even if the mouse is over the bounds where the object would be in the layout if were visible. Also, you can explicitly set the property IsHitTestVisible to false to disable hit testing even if a UIElement is not visibly transparent. Finally, although UIElement does not define it, the Background property exposed by various classes deriving from UIElement can also influence hit test behavior because a null Background also makes the object invisible to hit testing.