A Tour of the Class Hierarchy
WPF's classes have a very deep inheritance hierarchy, so it can be hard to get your head wrapped around the significance of various classes and their relationships. The inside cover of this book contains a map of these classes to help you put them in perspective as you encounter new ones. It is incomplete due to space constraints, but the major classes are covered.
A handful of classes are fundamental to the inner-workings of WPF, and deserve a quick explanation before we get any further in the book. Some of these have been mentioned in passing already. Figure 3.9 shows these important classes and their relationships without all the extra clutter from the inside cover.
Figure 3.9 The core classes in the WPF Presentation Framework.
These ten classes have the following significance:
- Object—The base class for all .NET classes.
- DispatcherObject—The base class for any object that wishes to be accessed only on the thread that created it. Most WPF classes derive from DispatcherObject, and are therefore inherently thread-unsafe. The Dispatcher part of the name refers to WPF's version of a Win32-like message loop, discussed further in Chapter 7, "Structuring and Deploying an Application."
- DependencyObject—The base class for any object that can support dependency properties. DependencyObject defines the GetValue and SetValue methods that are central to the operation of dependency properties.
- Freezable—The base class for objects that can be "frozen" into a read-only state for performance reasons. Freezables, once frozen, can even be safely shared among multiple threads, unlike all other DispatcherObjects. Frozen objects can never be unfrozen, but you can clone them to create unfrozen copies.
- Visual—The base class for all objects that have their own visual representation. Visuals are discussed in depth in Chapter 11.
- UIElement—The base class for all visual objects with support for routed events, command binding, layout, and focus.
- ContentElement—A base class similar to UIElement, but for pieces of content that don't have rendering behavior on their own. Instead, ContentElements are hosted in a Visual-derived class to be rendered on the screen.
- FrameworkElement—The base class that adds support for styles, data binding, resources, and a few common mechanisms for Windows-based controls such as tooltips and context menus.
- FrameworkContentElement—The analog to FrameworkElement for content. Chapter 14 examines the FrameworkContentElements in WPF.
- Control—The base class for familiar controls such as Button, ListBox, and StatusBar. Control adds many properties to its FrameworkElement base class, such as Foreground, Background, and FontSize. Controls also support templates that enable you to completely replace their visual tree, discussed in Chapter 10. The next chapter examines WPF's Controls in depth.
Throughout the book, the simple term element is used to refer to an object that derives from UIElement or FrameworkElement, and sometimes ContentElement or FrameworkContentElement. The distinction between UIElement versus FrameworkElement or ContentElement versus FrameworkContentElement is not important because WPF doesn't ship any other public subclasses of UIElement and ContentElement.