New post: Attachable Read-only Collection Dependency Properties

[Bill Kempf]

http://wekempf.spaces.live.com/?lc=1033

 

Fits in with the recent discussion about command bindings.  This is a wonderful little trick to know about, and I thank Mr. Gossman profusely.

--
Quidquid latine dictum sit, altum sonatur.
- Whatever is said in Latin sounds profound.

War is peace. Freedom is slavery. Bugs are features.

[Andrew]

Personally it seems like a bad idea to rely on an implementation that differs based on how you access it (e.g. using the DP or the wrapper). I think the better thing would be for the WPF framework to expose its internal DefaultValueFactory so you could initialize the value for each instance and in this case extend that infrastructure to allow it to be used to provide the default value for a readonly dependency property. Putting aside the fact that the documentation indicates you shouldn't rely upon them calling the wrapper, the fact that the designer isn't setup to handle this would make me hesitant to use this in a production environment.

[JohnGossman]

I wish this had been fixed in WPF before we shipped, but it is safe to
rely on it. It works because the XAML spec says you can define an
attached property using just the static Property. That the XAML
parser also will look up the DP is an implementation detail that is in
there for a perf optimization. So, as weird as it is, when the XAML
parser ignores the DP it is doing the right thing.

That Cider doesn't support this correctly is a bug in Cider and
scheduled to be fixed. It is the same issue noted by Silverlight Beta
2 customers that the VisualStateManager.VisualStateGroups property is
marked as an error by the designer, so it *has* to be fixed.

This is completely covered by our test suites, so we won't be breaking
it.

-JG

[Josh Smith]

That's some good insight.  Thanks John.  Do WPF and SL use the exact same XAML parser?

[JohnGossman]

No, Silverlight has a native code XAML parser so that it can support
JavaScript only content and the WPF parser is written in managed
code. They are tested for compat though.

-JG

[Andrew]

Thanks. Thats good to know but it still would be better if WPF exposed the DefaultValueFactory so you don't have to worry about how the property will be accessed. There are things like this, inheritance context control, ancestor change notifications, etc. that intrinsic WPF elements and controls use internally that should really be exposed as public/protected members. The Silverlight controls are implemented in a separate assembly so there is less likelihood for this happening (assuming you don't start using InternalsVisibleTo). It would be nice if the WPF controls were implemented in this way too (doesn't mean they have to be released in this fashion) so you can see just what developers need when developing their own elements and controls.

 

BTW, in Bill's implementation he registered a property with a different name than the Get/Set accessor methods and from his blog this seems to be required for this approach to work. Another subtle issue with this is that a DependencyPropertyDescriptor will not be created for this. So in his sample his property will not be returned in the TypeDescriptor.GetProperties. However if you change the sample so that it registers it with the proper name - "Instance" - then it will be returned. Is this another bug?

 

Thanks,

Andrew

[JohnGossman]

You seem to offer a couple of options:

1) Expose more of the internals of WPF so 3rd party controls can use
the same mechanisms built-in controls do
2) Implement the WPF controls like the Silverlight controls with less
coupling to the internals

I'm strongly in favor of #2. I'd like to reduce the complexity of WPF
with fewer classes and concepts...and given that is going to be
difficult to do with breakings folks, I want to hold the line. It
also makes it easier for us (and customers) to share control
implementations between Silverlight and WPF and to release new
controls without changing the framework.

In this particular example, my dream would be that we not have
DependencyProperties at all. It would be nice if CLR properties
sufficed, but to support attached properties we need something like DP
for backing storage...so we seem to be stuck with them. However, if
the DP is hidden (in VSM we made it internal) and we can use the
existing CLR property mechanism for setting the default value, I
prefer that to providing a DefaultValueFactory and thus another
extensibility mechanism.

Given the current obscurity of this trick, we should probably think
about extending the PropertyMetadata...either to initialize a
collection property, or to force the static setter and getter always
be called. If these are new options, they won't break old behavior
and we're okay. Have to say though, once you figure it out, I really
like just using the CLR property.

In other cases, I agree, if we unseal or make public certain classes
and interfaces, things get simpler.

[Mike Brown]

I'm still sore that you can't implement a custom ActionTrigger because it's an abstract class with the only abstract method marked internal. You could do some cool stuff with a custom ActionTrigger.

[JohnGossman]

Funny, because that's the exact issue I was thinking about when I
mentioned unsealing certain classes. It will almost certainly happen
in the next release.

[Bill Kempf]

On most of this I heartily agree.  I'm OK with the published hack for now, because there's few downsides that I can see (the descriptor issue is one I didn't think about).  However, it's still a hack.  Something like this deserves an actual, baked in, solution.  Of course, you've got to do that without breaking backwards compatibility.  But exposing currently internal details and/or adding new concepts shouldn't break things.

 

While we're on that subject, I find it vexing that the RoutedCommandArgs heirarchy makes all of the constructors internal.

[Josh Smith]

Any thoughts on making the inheritance context APIs public?  That would be awesome.  It would prevent us from having to use tricks, like relying on Freezable, just to get an inheritance context for bindings on elements external to the tree.

[Zhou Yong]

As far as I know, the inheritence context is hard coded in current version of WPF, so it's not a "change internal modifier to public modifier " fix to add this feature support in the next version of WPF.

Yong

[Josh Smith]

Thanks Zhou.  I have been deep into the inheritance context code in Reflector, so I know that what you say is true.  But, I'm not looking at it from Microsoft's perspective.  I'm looking at it from the outside world's perspective, where the amount of work required for MS is inconsequential.  :)

Josh

[Zhou Yong]

Josh, I am also looking at this from outsider's view, but based on my personal experience working with many issues on the MSDN forums, there are some of bugs directly or indirectly related to inheritance context, so I am afraid that it might take WPF team some time to actually define an inheritance context extensibility point in the future version of WPF. But to be honest, the trick with Freezable is simply too dirty, although thing can work, but symantically speaking, deriving from Freezable for very wrong purpose could confuse people, and since this behaviour is not documented in the MSDN, it might change without notice:)

Yong

[Josh Smith]

I agree.  But, sometimes there's no choice.  :(

[JohnGossman]

Could you give me an example of how you want to use inheritance
context?

[Pavan Podila]

I actually prefer this approach of baking information into a CLR
property rather than creating separate DPs. One possible
implementation for this would be to add a compiler-step that could
auto bake this information into the assembly, say through some custom
assembly injection. I wonder if this approach was thought of in the
design discussions. I think if one can express the intent clearly,
Attributes on CLR properties can be the glue to do this auto injection

- Pavan

[Mike Brown]

I think we spoke about the issue before in the forums. It's great having you here John. With Karl infiltrat...err...joining the Cider team, and you participating in the discussion, it makes it easier to get info about issues we bump into straight from the horse's mouth.

On Tue, Jul 29, 2008 at 1:04 AM, JohnGossman <gossm...@gmail.com> wrote:

[Josh Smith]

One example is in my workaround that enables ElementName bindings from a tooltip: http://joshsmithonwpf.wordpress.com/2008/07/22/enable-elementname-bindings-with-elementspy/

Sure, there are other ways to solve that particular problem, as Andrew blogged about,  but that's not the only place I've used ElementSpy (which hacks into Freezable's InheritanceContext prop).

Josh

[Andrew]

Is it really? Then why are there internal members like DependencyObject.AddInheritanceContext, DP.ProvideSelfAsInheritanceContext, etc?

 

-Andrew

----- Original Message ----
From: Zhou Yong <footb...@gmail.com>
To: wpf-di...@googlegroups.com
Sent: Tuesday, July 29, 2008 9:16:30 AM
Subject: Re: New post: Attachable Read-only Collection Dependency Properties

[Andrew]

The ListView is a perfect example. The GridViewColumn (and even the ViewBase) is a DependencyObject but in order to support ElementName and DataContext bindings, it has an inheritance context. We have cases where we have "subobjects" that should support binding but don't make sense to be freezables or contentelements just to support this type of binding. If the ListView were developed outside the PresentationFramework assembly, it would have been more apparant that this type of functionality needs to be externalized. :-)

 

----- Original Message ----
From: JohnGossman <gossm...@gmail.com>

To: WPF Disciples <wpf-di...@googlegroups.com>
Sent: Tuesday, July 29, 2008 9:59:56 AM
Subject: Re: New post: Attachable Read-only Collection Dependency Properties

[Mike Brown]

Agreed, I think the perfect proof of whether the framework is expressive enough for control developers would have been having the built in controls built as consumers of the framework. Isn't that how the silverlight controls are built: as a separate assembly?