Hello,

I wonder if anyone can explain the difference between
InheritedPropertyDescriptor vs. ReflectedPropertyDescriptor classes? I'm
writing my own designer based on the .NET design time framework. I've got a
custom design surface and am performing custom serialization with my own
designer loader.

Most everything works properly except in some cases where serialization is
concerned, some properties of controls do not get serialized. I call the
property descriptor's ShouldSerializeValue method to help decide whether a
control property should be serialized. In some cases, this method returns
True and in other cases False, when I would not expect it to return False.
I've read the description of PropertyDescriptor.ShouldSerializeValue and I
think I understand the rules that shoud be applied.

I get a list of properties by calling
TypeDescritpor.GetPRoperties(<object>,false). I've noticed in some cases my
properties are of type InheritedPropertyDescriptor while in other cases, they
are of type ReflectedPropertyDescriptor. It is when the properties are of
type InheritedPropertyDescriptor that the call to ShouldSerializeValue
returns False when I don't expect it to. Why do I sometimes get
InheritedPropertyDescriptor and other times get ReflectedPropertyDescriptor?
The rules seem to be different between the two classes...

Thanks,
Notre

Hi Notre,

The ReflectPropertyDescriptor is an internal class, which we couldn't
access directly. We couldn't find any document about this class in MSDN. As
for the InheritedPropertyDescriptor you have mentioned, I couldn't find it
in MSDN or Reflector.

Have you implemented ICustomeTypeDescriptor on the control, or add a
CustomTypeDescriptionProvider to the control?

If possible, could you please send me a sample project that could just
reproduce the problem? To get my actual email address, remove 'online' from
my displayed email address.


Sincerely,
Linda Liu
Microsoft Online Community Support

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscripti...t/default.aspx.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

Notre,

This is something we ran into just few short weeks ago while converting our
application to .NET 2.0. We also have a custom serializer, which recursively
serializes root design component with all of its sub-components. The
workaround was to check for root designer and process it slightly
differently. Here's a pseudo code snippet:

PropertyDescriptorCollection properties;
if (comp is <RootDesigner>)
// New for .NET 2.0 implementation
properties = TypeDescriptor.GetProperties(comp.GetType());
else
properties = TypeDescriptor.GetProperties(comp);
WriteProperties(properties, ...);

HTH.
--
Sergey Mishkovskiy
http://www.usysware.com/dpack/ - free VS add-ons
http://www.usysware.com/blog/


"Notre Poubelle" <notre_poubelle (AT) online (DOT) nospam> wrote

Hi Linda,

Yes, I realize that ReflectPropertyDescriptor is an internal class that has
no MSDN documentation. Would you be able to speak with a developer on the
..NET framework team who may be able to clarify the differences between
ReflectPropertyDescriptor & InheritedPropertyDescriptor, when each gets
invoked by the framework, and differences in ShouldSerializeValue
implementations? (I imagine Brian Pepin or one of his colleagues may be able
to shed some more light).

I also discovered that the InheritedPropertyDescriptor class is not
documented in MSDN. It is available in the System.ComponentModel.Design
namespace in the System.Design assembly.

Yes, I have implemented ICustomTypeDescriptor on both the root designer
control (some of whose property descriptors use the
InheritedPropertyDescriptor class) & on most other controls (whose property
descriptors use the ReflectPropertyDescriptor class).

Unfortunately, I can't send you a sample project that demostrates the
problem as I'm not clear on where the problem (i.e. when some property
descriptors are using
the InheritedPropertyDescriptor class and others are using the
ReflectPropertyDescriptor class) is originating. The actually set of
controls, designers, and all the related pieces is quite big & integrated
with other parts of our system.

Thanks,
Notre

Hi Sergey,

While I was attempting to research the InheritedPropertyDescriptor class on
the web, I found your earlier post on the subject ('Root designer and form
serialization problem'). Thanks for taking the time to respond to my post.

Thanks for the suggestion. I gave it a try and it's quite interesting. By
passing in <object>.GetType() rather than the <object> into
TypeDescriptor.GetProperties(), all the property descriptors that are
returned are of type InheritedPropertyDescriptor rather than
ReflectPropertyDescriptor. Unfortunately, when I pass in <object>.GetType()
as an argument rather than <object>, I get back a different set of proeprty
descriptors; I get a lot of extra ones that I don't need. The reason this
happens is because I'm implementing ICustomTypeDescriptor on my root control
(and most of my other controls) to filter the set of properties exposed. So,
using <object>.GetType() as the argument will not work for me; if I used it,
I would be serializing properties I don't want serialized.

Thanks,

Notre

Notre,

Yeah, I can see why that would be an issue for you. Take a look at
TypeDescriptor.GetProperties() overloads that take an array of Attribute as
a second parameter. I omitted that in my last reply but that's actually what
we use. Perhaps you could use that to filter out properties you don't want
to get serialized. It's been a while since I looked into that part of the
application, but if I recall it correctly, we use attributes filter to force
it to serialize extender properties. HTH.
--
Sergey Mishkovskiy
http://www.usysware.com/dpack/ - free VS add-ons
http://www.usysware.com/blog/

Hi Sergey,

Thanks for your reply. I may go down this route, but I'd like to have a
better understanding of the InheritedPropertyDescriptor before I go down this
route, which might requiring changing some of my serialization design. I'm
going to wait a bit to see what Linda comes up with...

Thanks,
Notre

Hi Linda,

In addition to my earlier comment (see above post), I did some more digging
on this. I'm still not clear on the intent of the
InheritedPropertyDescriptor class, but I now know when the property
descriptors get changed.

If I call TypeDescriptor.GetProperties(myObject, false), then some
properties come back as type InheritedPropertyDescriptor. Doing some further
digging, I find that GetProperties eventually calls
ITypeDescriptorFilterService.FilterProperties. This calls
IDesignerFilter.PostFilterProperties. This is implemented in
System.ComponentModel.Design.ComponentDesigner. The
InitialInheritedProperties method in this same class is the method that look
at all the properties and creates a set of InheritedPropertyDescriptor.

I'm still unclear of the why, and how to get my property to serialize...

Notre

One more note -- I tried to use a DefaultValue attribute and then later a
ShouldSerialize<PropertyName> method, but neither helped in the case of the
properties that ended with an InheritedPropertyDescriptor.

I have some more information. Some of my properties are of type
InheritedPropertyDescriptor (after the call to
TypeDescriptor.GetProperties(myObject, false)) and when I call
ShouldSerializeValue on some of these properties the value returned is True
(which is what I would expect). In the case of these properties, the
ShouldSerialize<PropertyName> method is called, unlike in the other
properties' cases, where ShouldSerializeValue always returns false.

Looking at implementation of
InheritedPropertyDescriptor.ShouldSerializeValue in Reflector, I found that
there is a test of see whether the property IsReadOnly. In both cases (when
ShouldSerializeValue works as expected and not), the IsReadOnly property
returns false.

The next test in InheritedPropertyDescriptor.ShouldSerializeValue is to
compare a private 'defaultValue' field against the static
InheritedPropertyDescriptor.noDefault field. Looking in the VS debugger, I
find something interesting. In both cases,
InheritedPropertyDescriptor.noDefault evaluates to {Object}. In the case
where things serialize as I expect (i.e. ShouldSerializeValue returns true),
then the 'defaultValue' field matches the
InheritedPropertyDescriptor.noDefault. In the case where it does not work as
expected, the 'defaultValue' field is different. The third test in
InheritedPropertyDescriptor.ShouldSerialize is then invoked, which compares
the value of the property vs. the 'defaultValue' field's value. If these two
don't match, then true is returned; otherwise
InheritedPropertyDescriptor.ShouldSerialize returns false.

It turns out that in the case where things don't serialize as I expect, the
'defaultValue' private field in InheritedPropertyDescriptor matches the value
of the property! This is why the method returns false. Using Reflector
again, I find that the 'defaultValue' field appears to be set in
InheritedPropertyDescriptor.InitInheritedDefaultVa lue, which is called from
the InheritedPropertyDescriptor constructor. By trial and error, and
examining the InitInheritedDefaultValue implementation in reflector, I
believe that the code is going into the branch that does this:

if (!this.propertyDescriptor.ShouldSerializeValue(com ponent))
{
//Do stuff here - content removed by me for clarity
}
else
{
this.defaultValue =
this.propertyDescriptor.GetValue(component);
obj1 = this.defaultValue;
this.defaultValue =
this.ClonedDefaultValue(this.defaultValue);
}
That is, code execution goes into the else part of the if/else test and it
assigns the current value of the property to the defaultValue!

I'm not 100% clear, but it looks like the InheritedPropertyDescriptor object
is created each time TypeDescriptor.GetProperties(myObject, false) is called,
so that the 'defaultValue' always matches the current property value;
therefore, ShouldSerializeValue always returns false...

Notre