Proposal: UIElement/FrameworkElement should expose protected method to add/initialize VisualTree #5530
Labels
feature proposal
New feature proposal
needs-winui-3
Indicates that feature can only be done in WinUI 3.0 or beyond. (needs winui 3)
product-winui3
WinUI 3 issues
team-Controls
Issue for the Controls team
wct
Proposal: UIElement/FrameworkElement should expose protected method to add/initialize VisualTree
Follow-up from discussion on docs repo here: MicrosoftDocs/winrt-api#646
Summary
Currently, especially in C#, it's not possible to inherit directly from
FrameworkElement
for a low-level component. Even in WinUI 2 with C++ here, while they look like they're inheriting fromFrameworkElement
, they're really usingPanel
(seeDeriveFromPanelHelper_base
) as an intermediary even if only a single child is expected.The ability to initialize a Child or Children property into the Visual Tree that's being created on a subclass of
FrameworkElement
is not exposed even as a protected member within the framework. This means that while you can write code that inherits directly fromFrameworkElement
, there's no way to get it to render as it can't be added to the VisualTree itself.Rationale
In the Windows Community Toolkit, we wanted to add a low-level component akin to
Viewbox
for constraining to a specific aspect ratio. It made sense to make it a single-child control fromFrameworkElement
, but we can't do that directly as we can't add theChild
property we create to the Visual Tree. See CommunityToolkit/WindowsCommunityToolkit#4104.Instead we need to inherit from
Panel
if we want something simple, but then that allows for multiple children to be added (which is odd for this scenario) OR we need to inherit fromContentPresenter
which does more than we need it to do with templating support.Scope
API Proposal
Example of what a proposed API could look like with a
protected
AddChild
andRemoveChild
method forUIElement
:Open Questions
FrameworkElement
would have a single child as a root for folks to subclass from. Otherwise if they accept multiple-children, it feels like they'd be aPanel
based implementation at that point? I don't know the implementation details ofPanel
so not sure where it makes sense to optimize for the single vs. multi-children support in the stack.ParallaxView
exposeChild
as a Dependency Property, but others likeBorder
do not. Is there a reason? Is it required to be a DP to support removing/adding dynamically to the content of the control?ChildTransitions
property on manyFrameworkElement
subclasses, there'd probably at least need to be documentation on how to add that into this scenario as well.Decorator
subclass as a mirror toPanel
but that took a single child. Does it make sense to provide that as a new base forBorder
/Viewbox
like it was in WPF and keep more of the abstraction, but provide a lighter-weight model to build off-of.Viewbox
beViewBox
??? 😋The text was updated successfully, but these errors were encountered: