WPF Custom Support Setup Dialog Box (Version 2022 or later)

Relevant for version 2022 or later

This topic describes WPF Custom Support Dialog Box (in Microsoft Visual Studio) for the version 2022 or later. For version 2021 or earlier, see WPF/Silverlight Custom Support Setup Dialog Box (Version 2021 R1 or earlier)

OpenText Functional Testing 2022 and later: Following the discontinuance of the Silverlight development framework, OpenText Functional Testing no longer supports the Silverlight Add-in by default.

If you need to use and extend the Silverlight Add-in, contact OpenText Support.

This dialog box opens when you select the OpenText Functional Testing WPF Custom Support template to create an OpenText Functional Testing Extensibility project in Microsoft Visual Studio.

The Custom Support Setup dialog box enables you to provide specifications that describe the support that you want to create. When the extensibility project is created in Visual Studio, its files are created with the basic content, infrastructure, and references required to create the support you described.

The template sets up both the XML files and the Microsoft Visual Studio solution that you need to create the custom server DLL. When you create support for more than one control in a toolkit, you have to combine the XML content created for each control into one toolkit configuration file and one test object configuration file for the toolkit.

This image displays a WPF Custom Support Setup dialog box.

OptionDescription
To access
  1. In Microsoft Visual Studio, select File > New> Project.

  2. Enter UFT in the search box and select the UFT WPF Custom Support template.

  3. Provide a name and location for your new project, and a name for the solution (or accept the default values provided).

  4. Click OK. The WPF Custom Support Setup dialog box opens.

Relevant tasks

How to create support for a Custom WPF Toolkit (Version 2022 or later)

Important information

Once you enter the Custom control type, all other field values are generated automatically.

You can accept the default values, or clear the relevant "Auto generate..." check box and define your own.

If you do not change the default values, any modifications you make to the Custom control type in this dialog box, modify the other fields as well.

See also

User interface elements are described below:

UI Element

Description

Target

Specify whether your custom support needs to target the .NET Framework or .NET.

This depends on whether the application you want to test uses a version of .NET or .NET Framework.

Note: .NET is supported only on Visual Studio 16.8 or later.

For information on the .NET/.NET Framework versions supported by OpenText Functional Testing WPF Add-in Extensibility, see the OpenText Functional Testing support matrix.

Custom control type

The name of the custom control type for which you want to develop support.

This can be one of the following:

  • A full type name, including namespaces. For example: Infragistics.Controls.Editors.XamComboEditor

  • A full type name and an assembly name. For example: Infragistics.Controls.Editors.XamComboEditor, InfragisticsWPF4.Controls.Editors.XamComboEditor.v12.1

  • An assembly qualified name. For example: Infragistics.Controls.Editors.XamComboEditor, InfragisticsWPF4.Controls.Editors.XamComboEditor.v12.1, Version=12.1.20121.1010, Culture=neutral, PublicKeyToken=7dd5c3163f2cd0cb

Note: In most cases, the full type name is sufficient. You can use the more complex name when the same control is included in more than one assembly, for example, when your application includes different versions of the same control.

Base class name

The test object class that your new test object class extends.

Select from the list of built in OpenText Functional Testing test object classes, or enter a name of a test object class that you defined in a WPF Add-in Extensibility test object configuration file.

Default: WpfObject

Support class name

The name of the support class to create in the new project.

Note: This class is also referred to as the custom server class.

Customize running operations

Indicates that you want to design or override implementation for running test object operations on the control.

If you select this option, the Run interface that you specify is defined and tagged with the RunInterfaceAttribute. In the custom server class, the interface is implemented with a method stub for an example test object operation. The example test object operation is also added to the project's test object configuration file.

Run interface name

The name of the interface in which you want to implement support for the test object operations.

Available only when Customize running operations is selected.

Customize property retrieval

Indicates that you want to design or override implementation for retrieving identification property values from the control.

If you select this option, the Property interface that you specify is defined and tagged with the CustomPropInterfaceAttribute. In the custom server class, the interface is implemented with a method stub for an example identification property. The example identification property is also added to the project's test object configuration file.

Property interface name

The name of the interface in which you want to implement support for property value retrieval.

Available only when Customize property retrieval is selected.

Toolkit name

A name for the environment, or set of controls, that you want to support with this toolkit support set.

After you deploy your support, OpenText Functional Testing displays this name in the Add-in Manager as a child node under the WPF add-in node, enabling the user to specify whether to load support for this environment.

In the new project created, the toolkit name is used to create the configuration file names, and entered in the PackageName attribute of the TypeInformation element in the test object configuration file. It is also used for the root namespace of the project.

Mapped test object class

The test object class that you want OpenText Functional Testing to use to represent the custom control.

In the new project created, a basic definition for this new test object class is created in the test object configuration file.

Customize recording

Indicates that you want to design support for recording test object operations on the control.

If you select this option, the custom server class is defined to implement the IRecord interface and includes method stubs for the interface's methods.

Design support for table checkpoints

Indicates that you want the standard checkpoints and output values that OpenText Functional Testing creates on your test object to be table checkpoints and output values.

If you select this option, a preliminary implementation of the ItableVerify interface is created in the custom server class. Implement this interface according to your needs.

Customize child object handling

Indicates that you want OpenText Functional Testing to treat some of the custom control's child objects as an integral part of the control and not as independent objects.

If you select this option, a preliminary implementation of the IsKnownPartOf method in the IComponentDetector interface is created in the custom server class. Implement the method to return true for the relevant child objects.

Generate comments and sample codeIndicates that you want the created files to include additional comments and code samples, helpful for beginner users.
Use .NET SDK Project Style

Indicates that you want the generated code to use the new, simplified, .NET SDK project style. For details on the .NET SDK style, see the Microsoft documentation.

Permanently selected for .NET projects.

Optional for .NET Framework projects. Selected by default. (Recommended)

Note: This option is supported only on Visual Studio 16.8 or later.