Learn to use Visual Studio, Visual Studio Online, Application Insights and Team Foundation Server to decrease rework, increase transparency into your application and increase the rate at which you can ship high quality software throughout the application lifecycle
Note: This is draft documentation for the Team Foundation Server SP1 Beta. The contents of this article should not be considered as final. All feedback is welcome.
The Work Item Tracking Custom Controls mechanism provides a standard way to enhance T:Microsoft.TeamFoundation.WorkItemTracking.Client.WorkItems to include enhanced user-interface capabilities, extended event-based rules, and workflow capabilities. These custom controls can be bound to T:Microsoft.TeamFoundation.WorkItemTracking.Client.Fields within T:Microsoft.TeamFoundation.WorkItemTracking.Client.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 T:Microsoft.TeamFoundation.WorkItemTracking.Client.WorkItem Form using design layout constraints.
· Allow a Control to be read and to write to a T:Microsoft.TeamFoundation.WorkItemTracking.Client.WorkItem or T:Microsoft.TeamFoundation.WorkItemTracking.Client.WorkItem T:Microsoft.TeamFoundation.WorkItemTracking.Client.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 Visual Studio. 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:
· They must derive from the T:System.Windows.Forms.Control class
· They must have a no-argument constructor
· They must implement the T:Microsoft.TeamFoundation.WorkItemTracking.Controls.IWorkItemControl interface
As an option, they can implement the following interfaces:
In the Work Item Type definition Layout, each Control element has a Type attribute. The schema previously identified the following valid control types:
<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" />
This has been replaced with:
This allows any name to be used. 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).
<Control Type="WorkItemIdReference" FieldName="MyFields.DuplicateId" Label="&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:
This manifest contains the following information:
Here is an example:
<CustomControl xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
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.
FYI: Here is link with sample and step-by-step instructions on custom control building: http://blogs.msdn.com/narend/archive/2006/10/02/How-to-use-Custom-Controls-in-Work-Item-Form.aspx
How can i set the workitem Dirty from my custom control.
Can you post code snippets about this issue.
thanks a lot.
How is it possible to update the WIT schema to match the 'new' schema described above? The WIT importer seems to choke if I use a custom control type. Where is this schema stored?