Thank you, Ian. Based upon your excellent and thorough examination of this subject, I've decided to continue using Reflection, and not get sidetracked with the nuances of Property/Event Descriptors.
If the need arises to extend or hide members, I'll reconsider. For now, the requirements are simple enough that the Reflection namespace more than meets my needs. Thanks again for taking the time to respond. -Steve -----Original Message----- From: Unmoderated discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED] On Behalf Of Ian Griffiths Sent: Monday, January 31, 2005 3:55 AM To: [email protected] Subject: Re: [ADVANCED-DOTNET] Which namespace to use: System.Reflection or System.ComponentMode l Actually, if you look more carefully you'll see that Steve's right - System.ComponentModel *does* provide a set of facilities that do provide very similar services to those available through reflection. (They are a subset - reflection is more powerful. But it's simply not accurate to say that "System.ComponentModel is not related, at all, to Reflection.") Take a look at TypeDescriptor and PropertDescriptor, and you'll realise that you can in fact find out about and invoke services on an existing type at runtime. For example, this works: static void DumpProperties(object o) { foreach (PropertyDescriptor pd in TypeDescriptor.GetProperties(o)) { Console.WriteLine("{0}: {1}", pd.Name, pd.PropertyType.FullName); } } This works for any type by the way - it doesn't matter whether it implements IComponent or not. And it's clearly pretty much equivalent to this Reflection-based example: static void DumpProperties(object o) { foreach (PropertyInfo pi in o.GetType().GetProperties()) { Console.WriteLine("{0}: {1}", pi.Name, pi.PropertyType.FullName); } } You can't look at these two examples and then convincingly claim that there's no overlap here... And it's not just about discovery. For example, the PropertyGrid uses the TypeDescriptor service not only to discover what properties are available on an object, but also to edit them. It does not use reflection. (Although the TypeDescriptor mechanism that it relies on is itself based on reflection under the covers.) So why does the ComponentModel namespace appear to duplicate some of the functionality of reflection? (Specifically the dynamic discovery and invocation of properties and events.) It's there to provide a layer of virtualization. By default, the properties visible through the TypeDescriptor infrastructure will be the same as those visible through Reflection because by default, TypeDescriptor just uses reflection. However, there are various mechanisms by which the set of visible properties and events can be changed or extended. The component can implement ICustomTypeDescriptor to add new properties or hide existing ones dynamically. It's also possible for the designer environment to modify the set of visible properties - for example, I gather that VS.NET does this to attach pseudoproperties like Locked and Name, and extender properties. (The TypeDescriptor mechanism also happens to provide a number of services useful at design time, such as type conversion. The propertygrid uses this to map between strings and the underlying property type. The XAML compiler (as shipped with the Avalon CTP) also uses this same mechanism to convert strings in the XAML to property values. But these are really just convenience functions - they don't have a direct analogue in the way that PropertyDescriptor maps to PropertyInfo.) So which do you use and when? You would use TypeDescriptor and friends if you need the virtualization. This is mostly useful in design-time environments, but that's not the only use case. If you're going to use the PropertyGrid at runtime (e.g. you might use it to present a configuration UI - lots of apps do this) then you need to get to grips with the TypeDescriptor infrastructure to get the most out of it. For example, it's possible to use the virtualization services to present localized strings as property display names. Reflection offers a precise view, and also provides more information than the TypeDescriptor mechanism. So if you want to make sure you're dealing with the real underlying object, or you need access to the things that are not visible through TypeDescriptor, use Reflection. -- Ian Griffiths - DevelopMentor http://www.interact-sw.co.uk/iangblog/ > -----Original Message----- > From: J. Merrill > > System.ComponentModel is not related, at all, to Reflection. You cannot > use its methods to do the things that Reflection does. ComponentModel is > (quoting from URL below) "to implement the run-time and design-time > behavior of components and controls." It's not for finding out about (and > possibly invoking) the interface of an existing type at runtime. > > http://msdn.microsoft.com/library/default.asp?url=/library/en- > us/cpref/html/frlrfsystemcomponentmodel.asp > > At 02:16 PM 1/28/2005, Gravitz, Steve wrote > >Since discovering the power of reflection in .NET, I've been able to > realize > >significant benefits. > > > >My helper class for Reflection contains methods that use Assemblies, > >System.Type, EventInfo, PropertyInfo, etc. Most of these types are > located > >in the System.Reflection namespace. > > > >Everything works fine; the performance hit is hardly noticeable (at least > >with the stuff I'm doing), and I'm thrilled with all of the new > >functionality and flexibility now at my disposal. > > > >Then I run across PropertyDescriptors, ICustomTypeDescriptors and other > >types that appear to provide similar functionality, yet live in the > >System.ComponentModel namespace. > > > >As I expected, the Microsoft MSDN documentation is basically useless > since > >it simply provides a member listing (and about 5 lines of sample code), > >which I could have obtained from the object browser or Reflector add-in. > > > >My hunch is that the types previously mentioned in the > System.ComponentModel > >namespace (PropertyDescriptors, etc) just provide a convenient wrapper > >around Reflection Namespace logic. > > > >If this is the case, what guidelines should be used to determine which > >approach to take? > > > >Using types in the System.Reflection namespace > >Or > >Using types in the System.ComponentModel namespace > > > >Thanks to anyone than can shed some light on this issue which has been > >bugging me for a while now. > > > J. Merrill / Analytical Software Corp > > =================================== > This list is hosted by DevelopMentor(r) http://www.develop.com > > View archives and manage your subscription(s) at > http://discuss.develop.com =================================== This list is hosted by DevelopMentor(r) http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com =================================== This list is hosted by DevelopMentor� http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
