Custom Class Selection Screen

This topic describes the Custom Class Selection screen in the New Custom Support Class Wizard, where you choose the class to support and review how the wizard derives the base support class.

In this topic:

Overview

Use this screen to identify the custom class to support and confirm the inheritance context that drives the generated support class. Decisions made here determine the base support class and influence all following wizard screens.

Wizard map

Custom Class Selection Screen > Test Object Class Selection Screen > Custom Support Test Object Identification Properties Screen > Custom Support Test Object Methods Screen > Custom Control Recording Support Screen > New Test Object Class Details Screen > Custom Control Support Class Summary Screen

Screen details

The Custom Class Selection screen is the first screen in the New UFT Custom Support Class wizard. In this screen, you select the custom class you want to support and set the relevant options. The wizard automatically determines which existing support class the new support class must extend, based on the custom class inheritance hierarchy.

When you click Next, the Test Object Class Selection Screen opens.

Main area options

The main area of this screen contains the following options:

• Custom toolkit tree

• Custom class inheritance hierarchy

• Base support class

The sections below describe each option.

Custom toolkit tree

Displays all of the classes in the custom toolkit that are candidates for support (taken from the custom toolkit class locations you listed in the New UFT Java Add-in Extensibility Project wizard). Use the expand (+) and collapse (-) signs to expand and collapse the tree, and to view its packages and classes.

Only classes that fulfill the following conditions are displayed:

• Classes that extend java.awt.Component or org.eclipse.swt.widgets.Widget.

• Classes for which support has not yet been extended. If support for a custom class was previously deployed to OpenText Functional Testing, or if support for a custom class is being developed in the current Eclipse project, the custom class does not appear in this tree.

  Note: If you think a certain class meets all of the requirements above, but it still does not appear in the tree, try to update your environment by using the Reload Support Configuration command.

  For example, if you delete custom support in an Eclipse Java Add-in Extensibility project to create new support for the same custom control, you must reload the support configuration. This enables the custom class to appear in the Custom toolkit tree.

Custom class inheritance hierarchy

Displays the inheritance hierarchy of the class selected in the Custom toolkit tree. Gray nodes indicate classes that are not included in this toolkit. Black nodes indicate classes that are part of the custom toolkit.

You can select the custom class you want to extend in the Custom toolkit tree or the Custom class inheritance hierarchy. (In the Custom class inheritance hierarchy you can select only black nodes, and only classes that do not have OpenText Functional Testing support.)

Base support class

The support class that the new support class must extend. You cannot modify this information. The wizard selects the support class of the closest ancestor in the hierarchy that has OpenText Functional Testing support. (If support for a custom class was previously deployed to OpenText Functional Testing, or if support for a custom class is being developed in the current Eclipse project, the wizard recognizes the custom class as having support.)

When OpenText Functional Testing recognizes a Java object that is not mapped to a specific support class, it uses the support class mapped to the object's closest ancestor. Therefore, the base support class is the class that would provide support for the custom control if it were not mapped to a specific support class. In the new custom support class, you need to implement (or override) only the support that the base support class does not adequately provide.

You can use the information displayed in the Custom class inheritance hierarchy and Base support class to help you decide whether you should first extend support for another custom class, higher in the hierarchy. Before you decide, consider the following:

• Is there a custom class higher in hierarchy that does not have support?

• If so, does the custom class have elements that need to be supported in a similar manner for more than one of its descendants?

If you answered "yes" to the above, consider creating support for the higher class first. This will enable its support class to be used as the Base support class. If the class is displayed as a black node in the hierarchy, you can select it in this screen and create support for it in this session of the wizard. If the class appears as a gray node, it is not part of this toolkit, and you cannot create support for it within the current extensibility project.

If the higher class extends the base toolkit of the current support project, you can add it to the scope of this project by adding it to the custom toolkit. For information on base toolkits, see Custom Toolkit Details Screen. For information on adding a custom class to an existing support project, see Modifying Project Properties.

Otherwise, if you want to create support for the higher class first and then use its support class as a base support class, you must perform the procedure described below.

Bottom area options

The bottom of the Custom Class Selection screen contains the following options:

Controls of this class represent top-level objects

Enables you to specify that the control might have to be recognized as the highest Java object in the test object hierarchy. For more information see, Supporting Top-Level Objects.

If you select this check box, the wizard implements the isWindow method in the new custom support class. This method returns true.

This option is available only if the class you selected to support is a container class, meaning that it extends java.awt.container or org.eclipse.swt.widgets.Composite. The check box is selected by default if the new support class extends one of the following support classes: ShellCS (SWT), WindowCS (AWT), AppletCS (AWT).

Change custom support class name

Enables you to modify the default name the wizard provided for the support class, if needed.

By default, the name for a support class is <custom class name>CS. In most cases, there is no need to change the default name. However, if your custom toolkit contains classes from different packages, you might have more than one custom class with the same name. In this case, you must provide different names for the custom support classes because they are stored in one package.

To modify the custom support class name, select the Change custom support class name check box and then enter the new name.

The options in the Custom Class Selection screen are identical to the options available in the Custom Static-Text Class Selection screen in the New Custom Static-Text Support Class Wizard.

Use support for a higher class as base support

To create support for a higher class that is not part of this custom toolkit and use this support as a base support class:

1. Create support for the higher class in another extensibility project.

2. Deploy the support to OpenText Functional Testing.

3. Reopen the original extensibility project. Select UFT > Reload Support Configuration or click the Reload Support Configuration button.

4. Open the New Custom Support Class Wizard. The wizard now selects the new support class you created as the Base support class.

Next steps

• Test Object Class Selection Screen