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

[vsfeedback]

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

---

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

---

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

[MichaeIDietrich]

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]

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]

@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