Cool Client Stuff : .NET - Random Tips

Why doesn't my TypeConverter get called?

rprabhu — Mon, 25 Apr 2005 11:03:00 GMT

Consider the following code:

public class MyControl : Control {

[TypeConverter(typeof(SomePropertyConverter))]
public Foo SomeProperty {
get { ... }
}

}

[TypeConverter(typeof(FooConverter))]
public class Foo {

...
}

Now here are a couple of questions:

Let's say both SomePropertyConverter and FooConverter implement conversion to and from String, given an instance of Foo. If I drop MyControl on a Form designer and try to edit SomeProperty in the property grid, which TypeConverter will get called?
Let's say both SomePropertyConverter and FooConverter implement conversion to InstanceDescriptor, given an instance of Foo. The intention is to control how an object of type Foo gets serialized to code. Which TypeConverter will get called?

The answer to question 1 is SomePropertyConverter. This is because the property grid will query the TypeConverter off the PropertyDescriptor for SomeProperty. The converter look up for properties gives precedence to TypeConverters attached to the property itself over the TypeConverter attached to the object or type. This allows a class like MyControl to control the behavior of the type Foo in the property grid, as related to SomeProperty.

What about question 2? One might expect the behavior to be consistent with 1. Well, no, it is not - the correct answer is FooConverter. This is because the serialization code queries the TypeConverter off the object or type itself, not off the PropertyDescriptor.

It is not immediately obvious why this is the case, and many people wonder if this 'inconsistency' is a bug in the component model. No, it is actually by design. To understand this, let's assume for a moment that the serializer did query the TypeConverter off the PropertyDescriptor. What would happen if the same instance of Foo is assigned to several different properties, each of which had their own TypeConverters specified? How then would the serializer know which TypeConverter to pick? After all, the object itself can be serialized in only one way. It is to avoid such ambiguities that type serializers ignore TypeConverters (and certain other metadata) attached to properties in determining how to serialize objects. This is also why the DesignerSerializerAttribute can only be applied to types, not to properties.

Note that this doesn't mean MyControl doesn't have a say in the serialization of SomeProperty. As I have explained in an earlier post, there are several ways it can control how the property itself is serialized. Note that there is a distinction between type serializers and member serializers. This distinction is made clear in Whidbey by bifurcating the CodeDomSerializer class hierarchy into two base classes, called TypeCodeDomSerializer and MemberCodeDomSerializer, both of which derive from a common base class called CodeDomSerializerBase.

Do you really need a custom CodeDomSerializer?

rprabhu — Wed, 16 Mar 2005 09:45:00 GMT

When you author a new component for .NET for which you want to offer a smooth user experience within the Visual Studio designers, you may find you need to write a few more classes to get it working the way you want. For example, you may need to write a designer for it to customize how it looks and behaves at design time. You may need to write TypeConverters for new types that you add, so that, among other things, they can be configured from the property grid. Maybe you will need to write a UITypeEditor.

Sometimes, you may feel you need to write a custom CodeDomSerializer for the component too. Now, the CodeDomSerializer class hierarchy is definitely designed to be extensible and customizable. In fact, in Whidbey, we have refactored this class hierarchy a bit to expose more common functionality you may need in your custom serializer.

However, before you start writing a custom CodeDomSerializer, you should ask yourself this question: do I really need a custom CodeDomSerializer? After all, very very few of the built in controls and components in Windows Forms have their own custom serializers. Even for the 2-3 components that do, they mostly do only a few lines of work and delegate the rest to the base serializers.

Let me first explain why I believe you should think twice before writing a custom CodeDomSerializer:

You may not need it in the first place. I will describe below some ways in which you can customize code generation without writing a custom serializer.
Writing a well behaved custom serializer is not trivial. There are many things you need to be careful about. For example, what happens when your component is placed on a Localizable Form? What about if it is in a collection or array? What if someone derives from it and configures some metadata differently? Does your serializer work fine when invoked in a different context than normal code generation - like for undo/redo (in Whidbey)?
What if your component is hosted in a design time environment that doesn't use CodeDom at all? For example, the component may be hosted on a DesignSurface that has a DesignerLoader that uses an xml based serialization scheme (like Xaml). Your custom CodeDomSerializer will not work in this situation, and serialization may not happen as you expect it to.

How then do you customize code generation? Well, it is mostly through the use of metadata. Here are a few possibilities:

The DesignerSerializationVisibilityAttribute helps you hide properties that you don't want serialized from the serializer and also tell it not to serialize the value, but only its content (typically useful for collections).
The DefaultValueAttribute and ShouldSerializeBlah methods (where 'Blah' is the name of a property) help control under what conditions to serialize a particular property.
The LocalizableAttribute controls whether a property is serialized into code or into the resource file when the component is on a Localizable Form.
The DesignOnlyAttribute, as the name suggests, can be applied to properties that are only meaningful at design time and don't need to be serialized as runtime property sets.
You can write a TypeConverter for your component (or any new type you have authored) that knows how to convert to InstanceDescriptor to control how objects of the type are instantiated by the serializer.
You can also control how objects are serialized into resx files by writing a TypeConverter that can convert to and from string, for example.

Now, I do understand there are legitimate scenarios where you will need to implement custom CodeDomSerializers, and this post is not meant to discourage doing so (in fact, as I said, we have made it easier in Whidbey to write these). However, before you implement one, just remember to consider the issues and suggestions mentioned here. I repeat: for our own components, we have extremely few that implement custom serialization and when they do, the serializer is only a few lines of code and lets the base serializer do most of the work.

See also this post that explains some serialization rules. If you are new to this topic, you will find this excellent article by Shawn Burke very useful.

Win32 <-> .NET API Mapping

rprabhu — Tue, 15 Feb 2005 08:03:00 GMT

This is another of those links that you simply must add to your favorites if you develop using .NET. This page tells you when not to use that other very handy website - PInvoke.net. So before you go the p/invoke route, make sure there isn't already a .NET equivalent API available.

Someday, when you can do everything you want purely in managed code and everyone has forgotten Win32, these links will become irrelevant. But today, they are definitely useful!

Smart Client in focus again

rprabhu — Wed, 09 Feb 2005 10:42:00 GMT

Good to see that Soma's keynote at VSLive! San Francisco brings the concept of 'smart client' back in focus. This is something I am personally passionate about and it is also the theme of this blog. Here is Soma's blog post on the topic and you can view the keynote video here.

Still not sure what a smart client is as opposed to a simple client application or a 'rich client'? I don't blame you - there are too many of these terms floating around. Believe it or not, 'smart client' isn't just a fancy new term for the same old thing - it is indeed a new kind of application model that attempts to combine the best of the client and web worlds. Check out the Smart Client Developer Center on MSDN to understand exactly what smart client means.

With features like ClickOnce and Client Settings, not to mention the very significant advances in Windows Forms, .NET Framework 2.0 is going to be a great platform for smart client application development!

Windows Forms and Avalon roadmap

rprabhu — Sun, 05 Dec 2004 03:10:00 GMT

If I am planning to write a Windows client application in the coming months, what technology should I target - Windows Forms or Avalon? This is a question that comes up every so often and results in a lengthy debate, but no clear conclusion. In an attempt to clarify, John Montgomery has posted a set of guidelines that have been reviewed by both teams. (via Chris Sells)

Smart Client Developer Center reloaded

rprabhu — Sat, 04 Dec 2004 08:39:00 GMT

Check out the new and improved MSDN Smart Client Developer Center page - it is a great place to start if you are looking for information about client application development. Jonathan, who is co-editor for the site with Chris Sells, has more information about it in his blog post.

.NET Framework SPs now available on Windows Update

rprabhu — Wed, 08 Sep 2004 16:12:00 GMT

The final versions of .NET Framework 1.1 SP1 and 1.0 SP3 are now available for download on Windows Update.

.NET Framework SPs - Tech Preview announced

rprabhu — Thu, 08 Jul 2004 08:04:00 GMT

Technical previews of .NET Framework 1.1 SP1 and 1.0 SP3 are out. You can find links to download, newsgroups and information about what's in the service packs here.

Smart Client Developer Center

rprabhu — Mon, 28 Jun 2004 09:01:00 GMT

If you haven't seen it already, check out the Smart Client Developer Center on MSDN launched earlier this month. It's a great place to start if you are looking for any kind of information relating to client application development. It also has an RSS feed. Here is the Windows Forms section.

Brian explains Components, Containers and Services

rprabhu — Tue, 20 Apr 2004 07:55:00 GMT

Brian blogs about the fundamental concepts of the .Net component model. The post is typical of Brian - his explanation is always crystal clear!

How to create non-rectangular Windows Forms applications

rprabhu — Sun, 04 Apr 2004 00:51:00 GMT

Ever wanted to write an app with forms that have arbitrary shapes rather than the usual rectangular windows? Mike Harsh describes on MSDN TV how you can accomplish this in Windows Forms, without writing a single line of code, using the RegionMaster controls available for download on WindowsForms.net.

Why are the interop definitions in System.Windows.Forms internal?

rprabhu — Thu, 25 Mar 2004 16:56:00 GMT

In a comment on BradA's blog, Chris wonders why Windows Forms didn't expose the structures and p/invoke declarations it uses for interop. This would have saved users from having to redefine them for their own use.

I guess there were mainly two reasons:

1) These declarations were put together on an “as necessary“ basis. Whenever we needed to call some Win32 API to implement a Windows Forms class, we added some p/invoke declarations. Obviously, the list isn't quite complete - there are many declarations you might need that aren't there. We didn't really want to expose an incomplete set of declarations.

2) Since the declarations were added for internal use by Windows Forms, chances are we expose a managed way to accomplish whatever you need the declarations for in the first place. So, in most cases, you will probably not find the p/invoke declarations you need in our set.

That said, we do realize that defining p/invoke structures and functions can be difficult to get right. The CLR team has put together a list of common Win32 definitions you may need. You will find the link (and many other useful resources) here.

Windows Forms Markup

rprabhu — Mon, 08 Mar 2004 20:14:00 GMT

Check out Mike Harsh's post about Windows Forms Markup Language (WFML). The sample and article by Joe Stegman are up on windowsforms.net. Note that this is based on .Net Framework v1.1, so you can try it out today!

How does the designer decide what properties to persist on a given component?

rprabhu — Tue, 03 Feb 2004 09:04:00 GMT

Any component has a bunch of properties on it. For example, the WinForms Button control has properties like BackColor, ForeColor, Text, Name, BackgroundImage and so on. When you place a Button on the Form in the VisualStudio designer and look at the generated code, you will find only a subset of the properties are persisted in code. Typically, these are the properties for which you explicitly set a value. What is the mechanism the designer uses to achieve this behavior?

First of all, the object that controls this is the CodeDomSerializer associated with the component. It decides how the component should be persisted to code. Here are some of the rules that the CodeDomSerializer associated with common controls like Button uses (well, more accurately, the serializer leaves the decision to the PropertyDescriptor associated with the property and our implementation of the latter uses these rules):

If the property has a DesignerSerializationVisibilityAttribute attached to it, then the serializer will use it to decide whether to serialize or not (like Visible or Hidden), and how to serialize (Content).
For a property called XXX, if the component implements a method called ShouldSerializeXXX, we make a late bound call to it to determine whether to serialize or not. For example, for BackColor, the method we look for will be called ShouldSerializeBackColor().
If the property has a DefaultValueAttribute specified, it is compared with the current value on the component. The property is serialized only if the current value is non-default.

Further, the designer associated with the component can also play a part in making this decision by “shadowing“ properties or by implementing ShouldSerializeXXX methods.

Not happy with this mechanism? Want to serialize your component in a different way? Sure! All you need to do is write your own Serializer class that derives from CodeDomSerializer and associate it with your component using the DesignerSerializerAttribute.

By the way, Whidbey is not just about cool new controls, layout, configuration, improved visual styles support, better design time experience etc. There are a ton of improvements to the designer infrastructure too, as we mentioned briefly at the PDC:

A new architecture that makes it much simpler to host designers
Improvements to the localization model (I didn't mention above how Localizable properties get serialized - that's a topic for another time)
A bunch of new classes that make it easier to write custom serializers
A provider based model that makes it easier to plugin custom type descriptors.

Some of these new classes are already documented at http://longhorn.msdn.microsoft.com. Look under the System.ComponentModel.* and System.*.Design namespaces.

On using Windows Forms controls as ActiveX controls

rprabhu — Thu, 15 Jan 2004 21:12:00 GMT

[Update: Reformatted and edited the quote below]

Here is a great summary by Mark Boulter (Tech Lead on .NET Client Team):

To summarize our official position on using Windows Forms controls as ActiveX controls:

v1.0 of Windows Forms only supports using Windows Forms controls in Windows Forms and IE 5.x
In v1.1 of the Framework we extended our hosting support to include using Windows Forms controls in MFC 7.x and up or any container that is fully compatible with the MFC 7.x ActiveX control container.
However we do not support registration of Windows Forms controls as ActiveX controls and we do not support CoCreateInstance of Windows Forms controls. We only support managed activation of the Windows Forms controls. Once the controls are created they can be hosted in MFC just as you would any other ActiveX control. This article by Chris Sells explains how to do this.