ApplicationBar exists entirely outside of the normal
Silverlight class
hierarchy in a very lonely corner of Silverlight for Windows Phone.
Most of the visual
objects that I’ve discussed so far in this book are often referred to as
elements, primarily because they
derive from FrameworkElement
in this class hierarchy:
Object
DependencyObject (abstract)
UIElement (abstract)
FrameworkElement (abstract)
These derivatives of FrameworkElement
include TextBlock, Image, Border,
MediaElement, Shape (which is the parent class
to Rectangle and Ellipse), and Panel, which is the parent class to Grid, StackPanel, and Canvas.
For the remainder of this article I’m going to focus on some classes that derive from Control:
Object
DependencyObject (abstract)
UIElement (abstract)
FrameworkElement (abstract)
Control (abstract)
Most Control
derivatives are found in the System.Windows.Controls
namespace, but others hide out in System.Windows.Controls.Primitives.
To programmers with
experience in graphical environments the word control is much more familiar and element. And this
raises a question: If visual objects that might normally be called controls are more properly referred to as elements in
Silverlight, then what’s the difference between elements and the visual
objects that really are Silverlight controls?
One convenient distinction is
that elements are usually relegated to presentation while controls are for interaction.
In Silverlight, Control is the ancestor to classes such as Button, Slider, and TextBox, so this distinction certainly seems
plausible. You might also notice that Control
implements an IsEnabled property, as well as three properties
involved in keyboard navigation using the tab key: IsTabStop, TabIndex, and TabNavigation.
On the other hand, user-input
events for the keyboard, mouse, stylus, and touch are actually defined
by UIElement, so
elements such as TextBlock and Image can receive user input and—with the proper support from
markup or code—respond to that input.
Perhaps a more significant
difference is that controls are built from elements. You can think of
elements as visual
primitives. Controls are assemblages of
these elements and other controls. A Button, for example,
is not much more than a Border with some content inside, usually (but not
limited to) a TextBlock. A Slider is not much more
than a couple of Rectangle elements and some special RepeatButton controls.
The visuals of a Control
are always defined by a visual tree of FrameworkElement
derivatives. This visual tree can also contain objects that also derive from Control, but these objects are then defined by a visual tree
of other FrameworkElement and Control derivatives.
Although the visuals of a Control are always a tree of
FrameworkElement
derivatives, this tree is not fixed. You can replace this tree to
entirely redefine the visuals of the control. The Control class
defines a property named Template of
type ControlTemplate.
Redefining the visuals of a
control with a template is a powerful tool for control customization.
But it’s hard to see how one would redefine the visuals of a FrameworkElement derivative. Surely a TextBlock has a
different appearance depending on the Text,
FontFamily FontSize and Foreground
properties, but
there’s no sensible way to make a TextBlock visually different independent of these
properties. In contrast, think how the basic Button has changed its visual appearance in many
different versions of Windows over the years.
You can’t derive from FrameworkElement in Silverlight. (Well, you actually can, but you
can’t do anything useful in the derived class.) And except for Panel, most FrameworkElement
derivatives are sealed. Shape isn’t sealed, but you can’t derive from it, and all
the derived classes of Shape are
sealed.
But you can derive from Control
and you can derive from many Control
derivatives. One Control derivative
named UserControl exists solely for the
purpose of creating
custom classes. So not only can you customize the visuals of an
existing control using templates, you can create your own controls. But
no matter how you do it, the visuals of the control will always be
defined as a tree of elements and other controls.
If you look at the documentation
for Control,
you’ll see that the class adds a number of convenient properties to FrameworkElement.
These include several text-related properties usually associated with TextBlock: FontSize,
FontFamily, FontStyle, FontWeight, and FontStretch.
Control
also adds a few properties found in the Border
class: BorderBrush, BorderThickness,
Background, and Padding, and two other properties associated with
control content: HorizontalContentAlignment
and VerticalContentAlignment. The Control class
itself doesn’t use these properties. The properties are defined solely
for the convenience of classes that descend from Control.
Similarly, Control
defines a bunch of protected
virtual methods corresponding to user input events defined by UIElement. For
Windows Phone 7 programmers, certainly the most important of these
methods are those for multi-touch: OnManipulationStarted,
OnManipulationDelta, and OnManipulationCompleted.
