Adding Designer Support

If your custom metadata requires a complex user interface (anything beyond the simple text edit control provided by the property grid) to edit, you'll need to add designer support. Otherwise, there won't be any way for the user to enter values for properties that make use of your metadata type. To add designer support, you'll need to build an editor for your type. An editor is simply a class that subclasses the .NET System.Drawing.Design.UITypeEditor class.

You can find several examples of implementing custom designers in the SampleCustomProperties project in the SampleProjects folder installed by CodeSmith. For example, DropDownEditorProperty is a class that wraps up a string and a boolean value together into a single piece of metadata. To edit this data, it provides a class, DropDownEditorPropertyEditor, which derives from UITypeEditor. The declaration of DropDownEditorProperty is decorated to indicate that this is the editor class that CodeSmith should use in the property grid:

[Editor(typeof(CodeSmith.Samples.DropDownEditorPropertyEditor), typeof(System.Drawing.Design.UITypeEditor))]
public class DropDownEditorProperty

In a template, you can use this metadata type just like any other (although you need to remember to reference its assembly, because CodeSmith doesn't know about this type by default):

<%@ Property Name="DropDownEditorProperty" Type="CodeSmith.Samples.DropDownEditorProperty" Category="Options" Description="This property uses a custom dropdown editor." %>
<%@ Assembly Name="SampleCustomProperties" %>

When the user wants to edit the DropDownEditProperty and clicks in the property sheet, CodeSmith will display the custom designer:

Note: For more information on building custom designers, refer to Michael Weinhardt and Chris Sells' article "Building Windows Forms Controls and Components with Rich Design-Time Features, Part 2" on the MSDN Web site.