dotnet / wpf

WPF is a .NET Core UI framework for building Windows desktop applications.
MIT License
7.03k stars 1.16k forks source link

The AttachProperty which is bound did not work when the lib's xaml prefix is different from app's xaml prefix #9316

Open vsfeedback opened 2 months ago

vsfeedback commented 2 months ago

This issue has been moved from a ticket on Developer Community.


[severity:It bothers me. A fix would be nice]

aa


Original Comments

Feedback Bot on 11/6/2023, 08:02 AM:

(private comment, text removed)

Ann Yang [MSFT] on 11/6/2023, 01:06 PM:

(private comment, text removed)

聪 李 on 11/6/2023, 02:12 PM:

(private comment, text removed)

Feedback Bot on 11/6/2023, 03:13 PM:

(private comment, text removed)

Feedback Bot on 2/5/2024, 00:15 PM:

(private comment, text removed)


Original Solutions

(no solutions)

Repro - AttachPropertyIssue.zip

miloush commented 2 months ago

Looks like a bug indeed. The namespace works when used directly, but not in a setter or binding.

MichaeIDietrich commented 2 months ago

Please change the Binding in your Style from {Binding (attaches:MyAttachProperty.MyImageSource),RelativeSource={RelativeSource Self}} to {Binding Path=(attaches:MyAttachProperty.MyImageSource),RelativeSource={RelativeSource Self}} to fix this issue.

new Binding(xyz) and new Binding() { Path=xyz } are not equivalent. The former interprets the path as a plain string where it is not able to understand the explicit property syntax. While the latter interprets the path as PropertyPath which correctly resolves that syntax.

In C# code you can explicitly pass a PropertyPath to the constructor of a Binding, but you cannot in XAML and therefore must use the Path property on Binding.

I can only make guesses why both things behave differently here. But in general I would just recommend to just always use the Path property on a Binding in XAML.

miloush commented 2 months ago

Hm I tried again and I can no longer reproduce the setter failure I was claiming ("Setter Property="attaches:..."), I must have had the binding still around. Thanks Michael!

The string constructor seems to be able to deal with explicit property syntax, I think it goes through the same parsing codepath, but it doesn't get the XAML context to map the namespaces. Theoretically we could make the ProvideValue fix the Path property, but then it would behave differently in code and in markup, which is probably not great.

lindexi commented 2 months ago

@MichaeIDietrich and @miloush , Addition, the origin Chinese blog is: https://huchengv5.github.io/post/WPF%E9%99%84%E5%8A%A0%E5%B1%9E%E6%80%A7%E7%BB%91%E5%AE%9A%E6%97%A0%E6%95%88%E7%9A%84%E9%97%AE%E9%A2%98.html