When writing rendering code for a custom element that derives from FrameworkElement, you can use the ActualWidth and ActualHeight properties to know how to render the element. These properties indicate the desired final size of the element, after all layout calculations have been done.

If a custom control derives from UIElement, it won’t have access to the ActualWidth and ActualHeight properties, but can instead use RenderSize.Width and RenderSize.Height. (You can also use these properties from within an element that derives from FrameworkElement, since FrameworkElement inhertis from UIElement).

By default, a custom element deriving from FrameworkElementhas no desired size. Most elements should override MeasureOverride as a way of indicating what their desired size should be. This would typically be based on the control’s content, but also might be some minimum size.

Below, we have a custom element that indicates that it has a minimum size of 20 x 20.

If you create a custom control that derives from FrameworkElement, the control won’t by default have any particular desired size. You can see this by setting alignment properties on a simple custom control without also setting explicit Width and Height.

You can see in the designer that the first instance of MyFrameworkElement is not visible, because it has no size.

A custom control will typically define its desired size based on its content. In the example above, the custom control hasn’t specified any desired size, size the control has a size of (0,0) and disappears.

You can create custom user interface elements that derive from FrameworkElement. Below is a simple example that renders itself as a graphical “X”. We override the OnRender method (inherited from UIElement) and use the DrawingContext object to create visual content.

If we host the Grid as a top-level element in a Window, our element is sized to fit the Grid, which sizes to fit the Window. Because we render the element using ActualWidth and ActualHeight, it changes size as we resize the window.

If you want to implement a custom element in WPF, either to display something in a user interface or to get input from a user, you’ll typically derive your custom element from one of the following classes: UIElement, FrameworkElement, or Control.

The inheritance chain for these three classes is:

When creating a custom control, you’ll want to choose as a base class whichever one of these classes has only the features that you want. The core functionality for these three classes is:

All elements that inherit (directly or indirectly) from FrameworkElement will fire both Initialized and Loaded events when the control is being loaded. For example, both an Initialized and Loaded event will for each control in your application when the application is starting up.

The Initialized events for all controls fire starting with the elements at the bottom of the logical tree. When handling the Initialize event for a particular element, you can assume that any elements below the element in question have already been initialized.

The Loaded event, on the other hand, fires from the top of the logical tree and then continues down the tree. The Loaded events begin firing only after the layout system has figured out the position and size of every element in the tree. So in a handler for a Loaded event, you can assume that all elements in the logical tree are fully configured.