Why does "TypeConverter.GetProperties" exist

[Larry Smith]

Hi there,

Can anyone provide any insight on why MSFT introduced
"TypeConverter.GetProperties()". There are two classes for dealing with
metadata in .NET, 'Type" and "TypeDescriptor". Each has a "GetProperites()"
method so why complicate the situation even more than it already is by
adding a "GetProperties()" method to "TypeConverter". The class is supposed
to be for converting types so "GetProperties()" seems misplaced and
redundant (as well as confusing given the absence of documentation
explaining how it fits into the big picture). Can anyone shed any light on
this. Thanks.

[Nicholas Paldino [.NET/C# MVP]]

Larry,

The TypeConverter class is meant to work with abstractions, not with
concrete types. Granted, for a good amount of the time, you are working
with concrete types, but there are a good amount of times where you are
working with an abstraction over a concrete type (working with an untyped
data set, forms and controls in designers, etc, etc) where having the actual
type isn't desired. It's because of this that GetProperties exists on the
TypeConverter. It's returning to you a PropertyDescriptorCollection, not a
PropertyInfo instance.

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]

Post by Larry Smith
Hi there,
Can anyone provide any insight on why MSFT introduced
"TypeConverter.GetProperties()". There are two classes for dealing with
metadata in .NET, 'Type" and "TypeDescriptor". Each has a
"GetProperites()" method so why complicate the situation even more than it
already is by adding a "GetProperties()" method to "TypeConverter". The
class is supposed to be for converting types so "GetProperties()" seems
misplaced and redundant (as well as confusing given the absence of
documentation explaining how it fits into the big picture). Can anyone
shed any light on this. Thanks.

[Larry Smith]

Post by Nicholas Paldino [.NET/C# MVP]
The TypeConverter class is meant to work with abstractions, not with
concrete types. Granted, for a good amount of the time, you are working
with concrete types, but there are a good amount of times where you are
working with an abstraction over a concrete type (working with an untyped
data set, forms and controls in designers, etc, etc) where having the
actual type isn't desired. It's because of this that GetProperties exists
on the TypeConverter. It's returning to you a
PropertyDescriptorCollection, not a PropertyInfo instance.
Hope this helps.

Thanks for the info. I'm still unclear on the matter however.
"TypeDescriptor.GetProperties()" does the same thing and AFAIK, the various
designers you mentioned rely on it. So when would you use one over the
other. Moreover, some "features" in .NET will use "TypeConverter" if you've
attached your own "TypeConveter" derivative to a class who does this and
when aren't really spelled out anywhere. For instance, the standard
"PropertyGrid" control will retrieve an object's properties using
"TypeConverter.GetProperties" if you've attached your own "TypeConverter" to
the object's class using the "TypeConverterAttribute". If not then it will
use "TypeDescriptor.GetProperties()" instead. In fact, "PropertyGrid"
ignores the latter function altogether if there's a "TypeConverter" attached
to the class so that even if you return "false" from a
"TypeConverter.GetPropertiesSupported" override, no properties will appear
in the grid at all. The details surrounding all this is very fuzzy since I
can't find any comprehensive documentation on the subject.

[Larry Smith]

Post by Larry Smith
attached your own "TypeConveter" derivative to a class who does this and

s/who does this/but who does this/

(ignore my first attempt to post this under your initial response).

[Larry Smith]

Post by Larry Smith
attached your own "TypeConveter" derivative to a class who does this and

s/who does this/but who does this/

[schneider]

Some times you want to change the way the default TypeDescriptor works.

Example: You only want specific properties to show in the PropertyGrid, you
could provide your own TypeConverter.

Schneider

Post by Larry Smith
Hi there,
Can anyone provide any insight on why MSFT introduced
"TypeConverter.GetProperties()". There are two classes for dealing with
metadata in .NET, 'Type" and "TypeDescriptor". Each has a
"GetProperites()" method so why complicate the situation even more than it
already is by adding a "GetProperties()" method to "TypeConverter". The
class is supposed to be for converting types so "GetProperties()" seems
misplaced and redundant (as well as confusing given the absence of
documentation explaining how it fits into the big picture). Can anyone
shed any light on this. Thanks.

[Larry Smith]

Post by schneider
Example: You only want specific properties to show in the PropertyGrid,
you could provide your own TypeConverter.

You don't need a "TypeConverter" for that. You can either inherit from
"ICustomTypeDescriptor" (requiring you to implement "GetProperties()") or in
2.0 and later, roll your own "TypeDescriptionProvider" derivative instead
(overriding "GetTypeDescriptor()" and implementing "GetProperties()" on the
returned "ICustomTypeDescriptor"). I can find no documentation that explains
the need for "TypeConverter.GetProperties()" or how it fits into the big
picture (when and why it's called instead of using the other techniques I
mentioned).

[schneider]

You may be right. But I use other features of TypeConverter. I currently use
one the format number with Accounting styles "(123,345.40)" in a
PropertyGrid.

Post by Larry Smith

Post by schneider
Example: You only want specific properties to show in the PropertyGrid,
you could provide your own TypeConverter.

You don't need a "TypeConverter" for that. You can either inherit from
"ICustomTypeDescriptor" (requiring you to implement "GetProperties()") or
in 2.0 and later, roll your own "TypeDescriptionProvider" derivative
instead (overriding "GetTypeDescriptor()" and implementing
"GetProperties()" on the returned "ICustomTypeDescriptor"). I can find no
documentation that explains the need for "TypeConverter.GetProperties()"
or how it fits into the big picture (when and why it's called instead of
using the other techniques I mentioned).