Determining the Inheritance Hierarchy for a Support Class

Within the custom toolkit for which you create UFT One support, you must decide:

  • Which custom classes must have matching support classes, and which can be supported by the support classes of their superclasses.

  • Which existing support class each new support class extends.
    (This also determines the order in which support classes must be created.)

Understanding the Hierarchy of Support Classes

The hierarchy of the support classes must reflect the hierarchy of the custom classes.

Example: The following example illustrates the hierarchy of the TextField class support. The column on the left illustrates the hierarchy of the TextField support class, TextFieldCS. The column on the right illustrates the hierarchy of the TextField class in the AWT toolkit:

In this example, a support class exists for every custom class, but this is not mandatory.

When UFT One learns an object, it can always identify the class name of the object. According to the class, UFT One determines the inheritance hierarchy of this class. UFT One then searches the toolkit configuration files for the support class that is mapped to that class. If no support class is found, UFT One searches for a support class that is mapped to the support class' immediate superclass, and so on, until a matching support class is found. Support classes can be provided by OpenText or any other vendor. If no other support class is found, AWT objects are supported by the ComponentCS class; SWT objects are supported by the WidgetCS class.

Example: The following example illustrates the hierarchy of the ImageButton class support. The column on the left illustrates the hierarchy of the ImageButton support class, ImageButtonCS. The column on the right illustrates the hierarchy of the ImageButton class in the AWT toolkit:

No support class is mapped to the superclass of ImageButton, ImageControl. Therefore, the support class for ImageButton extends the support class mapped to the higher level—CanvasCS.

Back to top

Determining Which Support Classes to Create

When determining which custom classes require support classes, you must consider the functionality and hierarchy of the custom classes.

If the support provided for a custom class' superclass is sufficient to support this custom class (meaning the custom class has no specific behavior that needs to be specifically supported), there is no need to create a support class for it.

Otherwise, you must create a new support class that extends the superclass' support class and map it to the custom class (in the toolkit configuration file). In the new support class you need to implement only those elements of support that are not sufficiently supported by the superclass' support class.

If more than one custom class extends the same superclass, and they share an identification property or test object method that requires the same support, provide this support in a support class for the superclass, and not separately in each class' support class.

Back to top

Determining Which Classes the New Support Classes Extend

To determine the existing support class that your new support class needs to extend, you examine the hierarchy of the custom class and check which support classes are mapped to its superclasses.

When you use the Java Add-in Extensibility wizards to create the custom toolkit support, the New Custom Support Class wizard determines which class to extend for each support class you create. It displays the custom class hierarchy and informs you which existing support class is the base (superclass) for the new support class. For more information, see Custom Class Selection Screen.

To determine the support class inheritance without the help of the Java Add-in Extensibility wizard:

  1. Determine the inheritance hierarchy of the custom class.

  2. Search the toolkit configuration files for a support class that is already mapped to a superclass of the custom class.

    You must search the toolkit configuration files that are part of the UFT One Java Add-in, as well as in those that are part of Extensibility custom toolkit support. These files are located in <UFT_One_installdir>\bin\java\classes\builtin and in <UFT_One_installdir>\bin\java\classes\extension, respectively.

  3. Create the support class for the custom class, extending the support class that you found mapped to its closest superclass.

    4. Note: If the closest support class you found is part of the UFT One Java Add-in, it is located in the com.mercury.ftjadin.support package. In this case, instead of extending it directly, you must extend the class with the same name provided in the com.mercury.ftjadin.qtsupport package.

    The example below uses the ImageButton custom control to illustrate the process of determining the hierarchy of a support class.

    This is the hierarchy of the ImageButton class:

    ImageButton's nearest superclass, com.demo.ImageControl, is not mapped to a support class. The next superclass, java.awt.Canvas is mapped to com.mercury.ftjadin.support.awt.cs.CanvasCS. This is part of the UFT One Java Add-in, so ImageButtonCS will extend the CanvasCS class in the qtsupport package: com.mercury.ftjadin.qtsupport.awt.cs.CanvasCS. This is the ImageButtonCS class definition:

    package com.mercury.ftjadin.qtsupport.imagecontrols.cs;
import com.mercury.ftjadin.qtsupport.awt.cs.CanvasCS;
...
public class ImageButtonCS extends CanvasCS {};

    Note: If you design your support classes to extend support classes from another toolkit support set, you create a dependency between the two toolkit support sets. Whenever you select to load the extending toolkit support set in the UFT One Add-in Manager, you must also select to load the toolkit support set that it extends.

Back to top

Next steps: