If a RenderPattern with a particular Name value is not provided for a field type, the field type inherits the RenderPattern with that name from its parent field type.

All field types must have a HeaderPattern type of RenderPattern element, either directly or by inheritance, because there is no alternate system for rendering column headers. The markup in a HeaderPattern can be quite simple when the field type is cannot be sorted or filtered. However, if the field type can be sorted or filtered, then the markup can become quite complex because the header serves not just as the title for the column but also as a drop-down menu control for sorting and filtering. Moreover, because the ability to be sorted and filtered can be disabled for particular columns (even when the field type the column is based on supports them) the markup must use Switch elements to test whether sorting or filtering is enabled for the column. See C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\XML\FLDTYPES.XML for examples.

A field type usually must have a DisplayPattern type of RenderPattern element (by inheritance, if not directly) so that the field can be rendered in each row of a list view. The DisplayPattern type of RenderPattern is also used to render most fields in Display mode; such as on the Display (list item) page. Alternatively, a field can be rendered in Display mode (but not on list views) by means of a rendering control (.ascx file). However, the main advantage of using a rendering control is to provide data validation and processing, and those functions are not needed when the data (valid or not) is merely being displayed instead of created or edited. For that reason, none of the field types that ship with Windows SharePoint Services 3.0 use a rendering control rather than a DisplayPattern type of RenderPattern element to render the field in Display mode. Probably, all of the custom field types that you create will use a DisplayPattern for Display mode also.

Note:
Two field types that ship with Windows SharePoint Services 3.0 do not have a DisplayPattern type of RenderPattern in FLDTYPES.XML: (1) ContentTypeId fields are never visible. (2) Computed fields are rendered on list views and in Display mode by a DisplayPattern element in their Field elements within the schema.xml of each list on which they appear.

The NewPattern and EditPattern types of RenderPattern are used to render a field in New mode and Edit mode, respectively, when the field does not require significant data processing or data validation when a list item containing the field is being created or edited. Free-form Note fields, for example, cannot be validated because any text is a valid value. Similarly, Choice fields and Lookup fields, by definition, limit the user's choices to only valid values. Other fields, such as Currency and DateTime, need only minimal validation that can be coded in script.

Custom fields you create that inherit from any of these types may, however, require more substantial processing. If so, use a rendering control to render the field. Usually, in fact, the reason you need a custom field is precisely because none of the fields that ship with Windows SharePoint Services 3.0 contain the data validation that you need.

See C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\XML\FLDTYPES.XML for examples of NewPattern and EditPattern types of RenderPatterns.

In your RenderPattern markup for a custom MultiColumn field, use the SubcolumnNumber attribute of a Column element to specify an individual column in a multicolumn field type. For more information about multicolumn field types, see Custom Multicolumn Field Classes.