Question: DependencyProperty => RegisterReadOnly method missing ???

[VijayanRamachandran]

Hi,

I am currently doing some prototypes migrating custom controls available in our end from WPF to WinUI.

During prototype I noticed that, in our end there are some WPF custom controls using DependencyProperty ( from System.Windows ) and the equivalent type DependencyProperty is available in WinUI ( from Microsoft.UI.Xaml ).

WPF DependencyProperty contains both Register and RegisterReadOnly method whereas WinUI DependencyProperty doesnot contain RegisterReadOnly method.

These implementations will be available soon in near WinUI Preview release ?

I am using right now
VS => Version 16.7.0 Preview 5.0
.Net SDK => dotnet-sdk-5.0.100-preview.4.20268.1-win-x64 / dotnet-sdk-5.0.100-preview.4.20268.1-win-x86

Code Snippet

private static readonly DependencyPropertyKey IsXyzPropertyKey =
DependencyProperty.RegisterReadOnly("IsXyz", typeof(bool), typeof(CustomControlExample), new PropertyMetadata(false));

public static readonly DependencyProperty IsXyzProperty = IsMultipleCalendarPropertyKey.DependencyProperty;

public bool IsMultipleCalendar
{
get {
return (bool)GetValue(IsXyzProperty);
}

protected set { 
                 SetValue(IsXyzPropertyKey, value); 
	  } 

}

Thanks.

[robloo]

I ran across the same issue a while ago and ended up asking in the Microsoft Docs repo at the time:

MicrosoftDocs/windows-dev-docs#1878

Read-only dependency properties are especially important to implement collections. However, in UWP Collection-Type Dependency Properties are not supported. In fact, in UWP SelectedItems isn't even a DP which is really bad architecture. All of this needs to be tackled at once IMO to bring the DP system in-line with WPF.

Like you I ran across this issue with custom controls.

In WPF this is supported:

https://docs.microsoft.com/en-us/dotnet/framework/wpf/advanced/collection-type-dependency-properties

In UWP, the closest I've managed to get is below. That avoids sharing the same List reference with all instances. However, it is only safe through the property accessor (which you can make get only). Through binding, it would be possible to set a new list entirely it seems which is why WPF had read-only dependency properties. If you are dealing with an ObservableCollection there are even more complexities this causes because you have to detect the new collection and then hookup event handlers. So, I'm still not sure the 'best' way to do this in UWP. Some clear documentation from Microsoft would be a big help.

        /// <summary>
        /// Identifies the <see cref="SelectedItems"/> dependency property.
        /// </summary>
        public static readonly DependencyProperty SelectedItemsProperty =
            DependencyProperty.Register(nameof(SelectionBox2.SelectedItems),
                                        typeof(IList<SelectionItem>),
                                        typeof(SelectionBox2),
                                        PropertyMetadata.Create(new CreateDefaultValueCallback(() =>
                                            {
                                                return new List<SelectionItem>();
                                            })));

[MikeHillberg]

There's no near-term plan to add RegisterReadOnly. Agreed it's a useful feature, and should be used for some existing properties like TwoPaneView.Mode and MenuBar.Items.

[robloo]

There's no near-term plan to add RegisterReadOnly. Agreed it's a useful feature, and should be used for some existing properties like TwoPaneView.Mode and MenuBar.Items.

Thanks for the feedback. In my experience, if there is no near-term plan then there is no plan to do it and it likely won't happen. Honestly, doing it during WinUI 3.0 is really the best shot as well since it's a breaking change to do it properly and add to existing controls.

[robloo]

@ranjeshj @StephenLPeters @ryandemopoulos

I'll state this here but it could apply to many different issues. @VijayanRamachandran and all the issues he's filed recently is a good illustration of the problems many of us went through a while ago during the initial migration from WPF to UWP. This is now happening again as devs and companies are looking at going to WinUI. Missing features like this left a really bad taste for devs and it's one of the reasons UWP was never successful. Honestly, the goal needs to be to close ALL missing functionality with WPF in areas such as these where the feature hasn't been reimplemented another way.

Edit: I should add that devs were able to stomach a bit more change with UWP since it embraced totally different form factors, mobile devices and required higher performance. Since WinUI is positioned strongly (more strongly it appears) at desktop, it will be harder to sell with clear feature gaps. What's the value in porting to WinUI vs keeping now open sourced WPF with .net Core and using one of the many styling packages to upgrade to Fluent designs? As you see, WinUI makes more sense for us UWP developers right now; however, UWP hasn't had updates in ages and is seemingly dying out. You might be unknowingly creating some strategic problems here so I'm just pointing them out.

[chrisglein]

Seeing a bulk of UWP vs. WPF issues. For example #3074, #3073, #3040, and this. For all of these, these are totally valid requests. But we are coming at this from the perspective of moving UWP XAML out of of Windows into a separate thing. Changes to the UWP API have to be handled as such: changes. These changes have cost, so we need to be intentional about what we do when, so I'm sorry to ask that these asks all go through the proposal process but that's the way we handle asks and can weigh cost/benefit. I appreciate your situation and the effort you've put in so far to identify gaps in the platform.

[robloo]

Created feature-request here: #3139