Open topic with navigation
This task describes how to create a custom server that contains the implementation UFT 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 WPF or Silverlight Toolkit.
Note: The links in this task link to the Mercury.QTP.WPF.CustomServer namespace section in the Custom Server API Reference. For the most part, the information there is relevant for Silverlight as well, and is identical to the information provided in the Mercury.QTP.Slv.CustomServer namespace section. An alternative link is provided for the Silverlight information when it is significantly different.
Do one of the following:
Set up the project using an extensibility template:
In Microsoft Visual Studio, create a new project using the UFT WPF CustomServer or UFT 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 Server Setup Dialog Box (in Microsoft Visual Studio).
Set up the project manually:
Create a C# project in Visual Studio using the Visual C# > Windows > Class Library template or the Visual C# > Silverlight > Silverlight Class Library template.
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).
Add references to the libraries that implement the custom control classes. For example, these may be third party libraries.
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.
Add all required references in the
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.
Create a custom server class for your custom control, extending the CustomServerBase class.
Note: If you used the UFT WPF/Silverlight CustomServer template to set up the Visual Studio project, the class declaration is created automatically.
In the next steps, you implement various interfaces in this class, according to the UFT 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 in this base class. For details, see Utility Methods and Properties.
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 WPF/Silverlight CustomServer template to set up the Visual Studio project, and specified that you want to customize running operations, the Run interface definition is created automatically.
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 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.
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 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.
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.
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 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.
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 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 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 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.
To support table verification and output value retrieval, implement all of the methods in the ITableVerify interface in your custom server.
Note: If you used the UFT WPF/Silverlight CustomServer template to set up the Visual Studio project, and specified that you want to design support for table checkpoints, a preliminary implementation of this interface is created automatically.
To instruct UFT 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.
Example: A calendar control might be implemented using buttons. To prevent UFT from learning these buttons as separate objects, or recording steps when the user clicks each button, the IsKnownPartOf method in the calendar's custom server returns
true for any button that is part of the calendar.
Note: If you used the UFT WPF/Silverlight CustomServer template to set up the Visual Studio project, and specified that you want to customize child object handling, a preliminary implementation of this interface is created automatically.
Note: If you used the UFT WPF/Silverlight CustomServer template to set up the Visual Studio project, and specified that you want to customize recording, a preliminary implementation of this interface is created automatically.
Define and implement the event handlers required by your test object.
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.
Implement RecordInit and RecordStop to register and release your handlers.
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.