Hello,

I am not aware of any side-effects that I know of, but I haven't looked into it thorougly. I applied it to the class because in every situation for that property, I was going to use that particular TypeConverter. That's an interesting point; I wonder how existing classes in the .NET framework declare conversions, in reference to the data type or object converters (such as the StringConverter, Int32Converter, CollectionConverter, etc.).

By declaring it this way, it solve the issue of storing object references in the viewstate in the page; for a custom class, where I didn't declare it, I got an error stating that "it required that a TypeConverter be declared or the class be marked Serializable."

Brian

The error seems to make sense. The run-time must know how to serialize the class, before it can put the object in view state. And it also seems to make sense that the TypeConverter is used to do that. (Although marking it as <Serializable> will work equally well for classes that only expose simple, serializable, properties).

So, the more I think about it, the more it seems to make sense to apply the attribute at the class level. At first, I considered this attribute to be a design-time issue, so it's better off being applied to the public property of the control. However, issues with loading the values at run-time and serialization make this a run-time issue as well, so I think it's better to apply it to the class, rather than to the property.

I came across another (old) Microsoft article: http://support.microsoft.com/default...b;EN-US;319626 Here they apply the attribute to the class as well. Assuming Microsoft knows what it's doing, I'll stick to that.

Thanks,

Imar
---------------------------------------
Imar Spaanjaars
Everyone is unique, except for me.
While typing this post, I was listening to: Wrecking Ball by Neil Young (Track 9 from the album: Freedom) What's This?