How to Develop a Custom Server

This task describes how to create a custom server that contains the implementation UFT One needs to run to interact with the custom control.

This task is part of a higher-level task. For details, see How to Create Support for a Custom Toolkit.

In this topic:

Set up the Visual Studio project

Do one of the following:

Set up the project using an extensibility template:

In Microsoft Visual Studio, create a new project using the UFT One WPF CustomServer or UFT One Silverlight CustomServer project template installed with the WPF and Silverlight Add-in Extensibility SDK.

This sets up the files, references, and classes that you need to develop your custom server, simplifying the remainder of the steps in this task. For details, see WPF/Silverlight Custom Support Setup Dialog Box (in Microsoft Visual Studio).

Set up the project manually:

1. Create a C# project in Visual Studio using the Visual C# > Windows > Class Library template or the Visual C# > Silverlight > Silverlight Class Library template.

2. Add references to all necessary .NET framework libraries.

   For example, PresentationCore, PresentationFramework, and WindowsBase (when developing in WPF) or .NET Framework Class Library for Silverlight (when developing in Silverlight).

3. Add references to the libraries that implement the custom control classes. For example, these may be third party libraries.

4. Add a reference to the DLL file that contains the WPF or Silverlight Add-in Extensibility API. The file is located in the <WPF and Silverlight Add-in Extensibility installation folder>\SDK\WpfSlv folder.

   • If you are developing support for a WPF control, add a reference to the Mercury.QTP.WpfAgent.dll file.

   • If you are developing support for a Silverlight control, add a reference to the Mercury.QTP.Slv.CustomServer.dll file.

     If you develop your toolkit support set on a computer that does not have the extensibility SDK installed, copy the DLL from the computer on which you installed WPF and Silverlight Add-in Extensibility.

5. Add all required references in the Using section.

   • To reference the WPF Add-in Extensibility API, add a reference to the Mercury.QTP.WPF.CustomServer namespace and not the to Mercury.WpfAgent.

   • To reference the Silverlight Add-in Extensibility API, add a reference to the Mercury.QTP.Slv.CustomServer namespace.

Back to top

Create the custom server class

Create a custom server class for your custom control, extending the CustomServerBase class.

In the next steps, you implement various interfaces in this class, according to the UFT One functionality that you want to support.

For example, your custom server class declaration might look like this:

public class MyCustomSupport:
       CustomServerBase,
       IMyCustomSupportRun,
       IRecord,
       ITableVerify,
       IMyCustomSupportCustProp,
       IComponentDetector

When designing the support, you can call utility methods from the IUtilityObject interface implemented by UFT One in this base class. For details, see Utility Methods and Properties.

Back to top

Develop support for test object operations

1. To support running new or modified test object operations that you defined for your test object class, implement one Run interface in your custom server, and tag this interface with the RunInterfaceAttribute attribute.

   Note: If you used the UFT One WPF/Silverlight Custom Server or Custom Support template to set up the Visual Studio project, and specified that you want to customize running operations, the Run interface definition is created automatically.

2. In the Run interface, design a method for each test object operation that you want to support or override. Each method you design must have the same signature as the test object operation that it implements (as defined in the test object configuration file).

   Note: In the test object configuration file, you can define test object operations with optional arguments.

   When you develop the custom server methods that support running these test object operations, consider the following:

   For WPF: You must use the Optional attribute from the System.Runtime.InteropServices namespace to specify an optional parameter. For example, void myMethod(int p1, [optional] int p2).

   For Silverlight: UFT One does not support the use of C# annotations for optional parameters in these methods. Therefore, instead of designing one instance of a RunInterface method with a signature that includes optional parameters, design different instances of the method using the same method name, but different numbers of parameters.

3. If you are developing support for a Silverlight control, you must tag each one of the methods that you design to implement running a test object operation with the ScriptableMember attribute. (This is an existing Microsoft Silverlight attribute.)

   Example: If the custom server defines an ICheckBoxRun interface with the Set method to be used by UFT One for running a Set operation, tag that interface with RunInterfaceAttribute.

   If this custom server is designed to support a Silverlight check box, tag the Set method with ScriptableMemberAttribute.

Back to top

Develop support for identification properties

Design your custom server to retrieve identification property values from the control. Do this for any new identification properties you defined for your test object class, or if you want to override the value retrieval implementation inherited from the base class.

1. To support retrieval of identification properties values implement one Custom Properties interface in your custom server and tag this interface with the CustomPropInterfaceAttribute attribute.

   Note: If you used the UFT One WPF/Silverlight CustomServer template to set up the Visual Studio project, and specified that you want to customize property retrieval, the interface definition is created automatically.

2. In the Custom Properties interface, define a property for each identification property whose value you want to retrieve from the control. Each property returns the value relevant for the identification property with the same name.

   For example, if the custom server defines an ICheckBoxCustomProp interface with the MyIsChecked property to be used by UFT One for retrieving the custom MyIsChecked identification property, mark the interface with CustomPropInterfaceAttribute.

   Customizing the test object name (WPF only): If you implement a logical_name identification property, UFT One uses its value as the test object name. This enables you to provide a functionally logical name for the test object (for example, the text displayed on the control). Otherwise, UFT One generates a default name for the test object.

   Note: In the test object configuration file, you must define all identification properties relevant for your test object class. However, the implementation for retrieving the property values is inherited from the base class for any properties that it supports.

Back to top

Develop support for table checkpoints and output values

To support table verification and output value retrieval, implement all of the methods in the ITableVerify interface in your custom server.

Back to top

Specify children of the control that should not be treated as separate controls

To instruct UFT One that certain child controls are part of a higher-level control, implement the IComponentDetector interface, and design the IsKnownPartOf method in the to return true for those child controls.

Back to top

Develop support for recording steps

To support recording, implement the IRecord interface in your custom server class by overriding the callback methods. (Use this link for information on the IRecord interface in the Silverlight API.)

1. Define and implement the event handlers required by your test object.

2. Define and implement the message handlers required by your test object.

   • Implement OnMessage to listen directly to Windows messages.
     When developing support for a Silverlight control, the value returned from OnMessage indicates whether the custom server handled the message, or whether this message needs to be passed on to other registered event handlers.

   • When developing support for a Silverlight control, implement GetWndMessageFilter to specify the objects on which to listen to Windows messages. You can listen to messages on the control itself (and the children considered and integral part of it), on the control's children, or on all messages to the application.

     See also the limitation about handling Windows messages in Troubleshooting and Limitations - Developing Support.

3. Implement RecordInit and RecordStop to register and release your handlers.

Back to top

Prepare your custom server for deployment

Compile your custom server to create the DLL.

To enable your custom server to work with 32-bit and 64-bit applications, compile the custom server DLL with the Platform target option set to Any CPU.

Back to top