ToolTip property

The BindTheButton program also includes a ToolTip object that is set to the ToolTip property of the Button. The text appears when the mouse cursor pauses over the button. The ToolTip property is defined by FrameworkElement, so you can attach a tooltip to other elements as well as controls. Like ButtonBase and Windows, ToolTip derives from ContentControl, so you can use formatted text in the ToolTip, and even pictures if you really want to mess with the heads of your users.

If you'd like to see a ToolTip with an image, go back to the ImageTheButton program and insert the following four lines at the end of the constructor:

Button btn = new Button();
btn.Content = "Don't Click Me!";
ToolTip tip = new ToolTip();
tip.Content = img;
btn.ToolTip = tip;

FrameworkElement vs. FrameworkContentElement

FrameworkElement (FE) derives from UIElement.  FrameworkContentElement (FCE) derives from ContentElement.  Since the framework is not built on a language that supports multiple inheritance (and thank god for that!), the divergence was necessary.  There are parts of ContentElement that you wouldn’t want in every FE and there are parts of UIElement that you wouldn’t want in every FCE.

FCE basically exists to support the text formatting engine (which can be found in the MS.Internal.Text namespace).  There are a few non-text classes that derive from FCE, but they do this just to be lightweight.

The goal was to make the programming experience for dealing with an FE and FCE as similar as possible.  If anything, I think this makes the framework *more* elegant.

You can think of an FCE as having everything an FE has except support for layout/rendering.  Of course, this is no small feature and you certainly would not want that kind of overhead in every text element.  Imagine the perf if you tried to render every textual stroke using WPF’s layout engine… text is far too complex.

True, it’s weird to see the exact same properties, methods, interfaces, events, etc, defined on two completely different base classes.  But I guess my general response is a big shrug.  As long as Microsoft is willing to maintain the code, I don’t have a problem with it.  (And in truth, much of the code shared between the classes is codegen’d anyway during the build process, so its really not that hard for them to maintain… clever chaps!)

Sidenote:  IFE vs. LIFE:  A mnemonic we used to use is “LIFE begins at UIElement”.  That is to say, every UIElement supports Layout, Input, Focus, and Events.  ContentElement gives you everything but the ‘L’.  As such, the intersection of functionality between an FE and FCE is the IFE portion.

I recommend creating a helper class if you want to treat the IFE portion of framework objects in a polymorphic manner.  It’s easy enough to implement…  in fact, you can steal most of the implementation from the internal FrameworkObject class  in fact, you can steal most of the implementation from the internal FrameworkObject class.  

Content Source: Dr. WPF

Shapes in WPF (code)

Take a look at the namespace System.Windows.Shapes, which contains an abstract class named Shape and six other classes that derive from it. These classes also derive from UIElement by way of FrameworkElement:

Object
--DispatcherObject (abstract)
------DependencyObject
----------Visual (abstract)
--------------UIElement
--------------------FrameworkElement
--------------------------Shape (abstract)
--------------------------------Ellipse
--------------------------------Line
--------------------------------Path
--------------------------------Polygon
--------------------------------Polyline
--------------------------------Rectangle

While Image is the standard way to display raster images, these Shape classes implement simple two-dimensional vector graphics. Eg. lets take ellipse:

Ellipse elips = new Ellipse();
elips.Fill = Brushes.AliceBlue;
elips.StrokeThickness = 24;     // 1/4 inch
elips.Stroke =  new LinearGradientBrush(Colors.CadetBlue, Colors.Chocolate,
                                      new Point (1, 0), new Point(0, 1));

Neither the Shape class nor the Ellipse class defines any properties to set a size of the ellipse, but the Ellipse class inherits Width and Height properties from FrameworkElement, and these do just fine:

elips.Width = 300;
elips.Height = 300;

The concept of Content

The Window class has more than 100 public properties, and some of themsuch as the Title property that identifies the windoware quite important. But by far the most important property of Window is the Content property. 

You set the Content property of the window to the object you want in the window's client area.

You can set the Content property to a string, you can set it to a bitmap, you can set it to a drawing, and you can set it to a button, or a scrollbar, or any one of 50-odd controls supported by the Windows Presentation Foundation. 

You can set the Content property to just about anything. But there's only one little problem:

You can only set the Content property to one object.

This restriction is apt to be a bit frustrating in the early stages of working with content. Eventually, of course, you'll see how to set the Content property to an object that can play host to multiple other objects. For now, working with a single content object will keep us busy enough.


We've seen that window content can be plain text. But the purpose of the Content property is not to display simple unformatted text. No, no, no, no, no. What the Content property really wants is something more graphical in nature, and that's an instance of any class that derives from UIElement.
UIElement is an extremely important class in the Windows Presentation Foundation. This is the class that implements keyboard, mouse, and stylus handling. The UIElement class also contains an important method named OnRender. The OnRender method is invoked to obtain the graphical representation of an object.
As far as the Content property goes, the world is divided into two groups of objects: Those that derive from UIElement and those that do not. In the latter group, the object is displayed with ToString; in the former group, it's displayed with OnRender. Classes that derive from UIElement (and their instantiated objects) are often referred to collectively as elements.
The only class that inherits directly from UIElement is FrameworkElement, and all the elements you'll encounter in the Windows Presentation Foundation derive from FrameworkElement. In theory, UIElement provides the necessary structure of user interface events and screen rendering that can support various programming frameworks. The Windows Presentation Foundation is one such framework and consists of all the classes that derive from FrameworkElement. In a practical sense, you probably won't make much of a distinction between the properties, methods, and events defined by UIElement and those defined by FrameworkElement.
 
One popular class that inherits from FrameworkElement is Image. Here's the class hierarchy:
Object
--DispatcherObject (abstract)
------DependencyObject
----------Visual (abstract)
------------------UIElement
----------------------FrameworkElement
----------------------------Image
The Image class lets you easily include an image in a document or an application.