Export (0) Print
Expand All

Work Item Tracking Custom Controls

The Work Item Tracking Custom Controls mechanism provides a standard way to enhance WorkItems to include enhanced user-interface capabilities, extended event-based rules, and workflow capabilities. These custom controls can be bound to Fields within WorkItems. These custom controls enable users to view and edit data.

The Work Item Tracking Custom Controls are intended to enable the following capabilities:

  • Allow the use of new or existing Windows Form controls. This includes ActiveX controls wrapped as a Windows Form control.

  • Place controls on a WorkItem Form using design layout constraints.

  • Allow a Control to be read and to write to a WorkItem or WorkItem Field.

  • Allow a Control to read and write from external data sources.

There are some restrictions for custom controls.

  • Multiple value fields are not directly supported. The use of a single field value as a holder of multiple values makes querying very difficult to do reliably.

  • Attachments do not have an update capability. The use of Custom Controls cannot overcome this limitation.

  • The existing controls are not public and therefore cannot be extended.

  • The binaries for each custom control must be installed on the client computer. There is no requirement for Admin rights to install custom control binaries.

  • There is no provisioning system for custom control binaries in the Visual Studio system. Visual Studio assumes the binaries are already installed on the client computer.

  • Custom controls that are missing or are not configured correctly must not cause the client to crash. They must also provide enough information to troubleshoot the problem.

Custom Controls have the following rules:

As an option, they can implement the following interfaces:

IWorkItemClipboard

IWorkItemUserAction

IWorkItemToolTip

In the Work Item Type definition Layout, each Control element has a Type attribute. The schema previously identified the following valid control types:

<xs:restriction base="xs:string">
    <xs:enumeration value="FieldControl" />
    <xs:enumeration value="DateTimeControl" />
    <xs:enumeration value="HtmlFieldControl" />
    <xs:enumeration value="LinksControl" />
    <xs:enumeration value="AttachmentsControl" />
    <xs:enumeration value="WorkItemClassificationControl" />
    <xs:enumeration value="WorkItemLogControl" />
</xs:restriction>

This has been replaced with:

<xs:restriction base="xs:string">
    </xs:restriction>

This allows you to use any name. The built-in Types are still permitted. However, the use of a Type that does not match a built-in Type will infer the use of a Custom Control. This reference must not be to a specific DLL or Control. The reference is used as a name to look up an assembly manifest file on the client. For more information on assembly manifests see the topic, Assembly Manifests, on MSDN (http://go.microsoft.com/fwlink/?LinkId=74355).

Example

<Control Type="WorkItemIdReference" FieldName="MyFields.DuplicateId"  Label="&amp;Duplicate Id:" LabelPosition="Left" />

Use the value for the Control Type to identify the Work Item Custom Control (WICC) manifest file. The WICC file uses a naming convention of <Control Type>.wicc. It is located on the client computer in the following search path:

Environment.SpecialFolder.LocalApplicationData

User-specific Path

Environment.SpecialFolder.CommonApplicationData folder

All Users

This manifest contains the following information:

  • Assembly

  • FullClassName

Here is an example:

<?xml version="1.0"?>
<CustomControl xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <Assembly>WitCustomControlSample.dll</Assembly>
  <FullClassName>WitCustomControlSample.WorkItemIdReference</FullClassName>
</CustomControl>

Use the Assembly element to locate and load the assembly. This value can be either the relative path of the location of the assembly file or the absolute path of the location of the assembly file.

  • If you cannot find the control, or if some other error occurs, you will see a red, read-only error message. This message is substituted for the control itself.

  • Custom validation rules cannot be enforced in other client environments, such as Microsoft Excel and Microsoft Project. Use these rules carefully.

  • Validation rules cause the existing controls to change color when they are invalid. The colors are not customizable. Therefore, new controls should use standard colors to remain consistent.

  • The Work Item Object Model is updated on every change to a control. Custom control implementations must set the dirty flag correctly in the Object Model so that changes in the custom control will be saved.

Community Additions

ADD
Show:
© 2014 Microsoft