Question

Is there a way to set the size of a UIElement (without casting to FrameworkElement), perhaps similar to how using RenderSize on a UIElement mirrors getting size information via ActualWidth & ActualHeight on a FrameworkElement)?

In effect, I guess you could say I want to set the RenderSize of a UIElement.

I'm thinking along the lines of an approach that would somehow enable me to force a measure / arrange pass with the desired size, but can't seem to find an appropriate point of attack.

Was it helpful?

Solution 2

The closest thing to a way of doing this is to call Arrange(finalRect) on the UIElement. If the element's ArrangeCore override (and/or subsequent OnRender) implementation "stretches" to / makes use of the whole area given (by finalRect), its size will be set accordingly. But only if.

Personally, I decided to amputate WPF at its UI neck and build my own layout system and a complete set of UI controls that descend directly from UIElement. That way, I sidestep the whole problem, since the granddaddy in my hierarchy, the firstborn son of UIElement, has all the members necessary for layout built in from the getgo - including properties for Width and Height (and is basically therefore a sizable UIElement).

The rest of my code then just deals with grandpa, i.e. my version of "FrameworkElement" (which is way more efficient - since it sheds all the context / dependency / styling functionality etc that I don't need anyway. WPF pays a price for being so generic).

A FrameworkElementWrapper control is included in that family, should there be a need to include any conventional FrameworkElements in the layout.

OTHER TIPS

This might seem like an easy, or obvious answer, but no, you can't set the Width or Height of a UIElement simply because it does not have those properties. The UIElement class is merely a base class for WPF core level implementations that provides some basic functionality. From the UIElement Class on MSDN:

A UIElement has the following capabilities that are specifically defined by the UIElement class:

• Can render as a child element (UIElement derives from Visual, a high level graphics class)
• Contains logic that is used to size and position possible child elements of a UIElement (when interpreted by a layout system)
• Can respond to user input (including control of where input is getting sent to via their handling of event routing, or routing of commands)
• Can raise routed events that travel a route through the logical element tree
• Supports some aspects of the animation system

Now when looking at the FrameworkElement Class page on MSDN, we see this:

FrameworkElement extends UIElement and adds the following capabilities:

• Layout system definition: FrameworkElement provides specific WPF framework-level implementations for certain methods that were defined as virtual members in UIElement. Most notably, FrameworkElement seals certain WPF core-level layout overrides, and instead provides a WPF framework-level equivalent that derived classes should override instead. For example, FrameworkElement seals ArrangeCore but provides ArrangeOverride. These changes reflect the fact that at the WPF framework-level there is a full layout system in place that can render any FrameworkElement derived class. At the WPF core level, certain members that will structure a general WPF based layout solution are in place, but the actual engine of the layout system is not defined.

The bold text that I highlighted should further explain why you cannot set the Width or Height of a UIElement.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top