Understanding your Custom Toolkit Support Set

This topic describes the files that make up your Custom Toolkit Support Set.

In this topic:

Understanding the Toolkit Support Class

When all of the classes in a custom toolkit extend the basic user interface class of another toolkit (for example java.awt.Component) we say the custom toolkit extends that toolkit (in this example: AWT). Every custom toolkit support set has one toolkit support class that indicates the native toolkit that the custom toolkit extends.

By extending the custom toolkit support class from the correct native toolkit support set, you ensure that your toolkit inherits all of the necessary utility methods for basic functionality (such as event handling and dispatching).

The UFT One Java Add-in provides custom toolkit support classes for AWT, SWT, and JFC (Swing). When you create new Java Add-in Extensibility custom toolkit support classes you extend one of these, or the custom toolkit support class of other existing Extensibility custom toolkit support sets.

The inheritance hierarchy of toolkit support classes reflects the hierarchy of the custom toolkits. For example, the JFCSupport class extends the class AWTSupport. A toolkit support class of a toolkit that extends JFC will extend JFCSupport thereby inheriting AWTSupport functionality. No further implementation is required in this class.

For example, this is the toolkit support class for the Javaboutique custom toolkit, which extends the AWT native toolkit:

package com.mercury.ftjadin.qtsupport.javaboutique;
import com.mercury.ftjadin.support.awt.AwtSupport;
public class JavaboutiqueSupport extends AwtSupport {}

The following table shows which toolkit support class to extend, if you want to extend the toolkit support classes provided for AWT, SWT, or JFC:

Back to top

Understanding the Toolkit Configuration File

Every custom toolkit support set has one toolkit configuration file named <Custom Toolkit Name>.xml, which is stored under the UFT One installation folder. This file provides the information that UFT One needs to find the classes of the custom toolkit support set.

The toolkit configuration file specifies:

• The location of the toolkit support class

• The location of the compiled support classes (a class folder or Java archive)

  UFT One adds this location to the Java application classpath when the application runs, enabling the application to find the required support classes.

• The support toolkit description

  UFT One displays the description in the Add-in Manager when a user selects the custom toolkit's name in the list of available add-ins. If you are developing this toolkit support set for distribution, include a Provided by clause in this description, specifying the relevant person or company.

• A mapping of each custom class to its custom support class

  A single custom support class can be mapped to more than one custom class, but each custom class can be mapped to only one custom support class.

The following example illustrates the configuration file of the javaboutique toolkit support, with one supported custom class—AwtCalc:

<?xml version="1.0" encoding="UTF-8"?>
<Controls 
     class="com.mercury.ftjadin.qtsupport.javaboutique.javaboutiqueSupport" 
     SupportClasspath="C:\JE\workspace\javaboutiqueSupport\bin" 
     description="Javaboutique toolkit support.">
    <Control Type="org.boutique.toolkit.AwtCalc">
        <CustomRecordReplay>
            <ImplementationClass>
            com.mercury.ftjadin.qtsupport.javaboutique.cs.AwtCalcCS
            </ImplementationClass> 
        </CustomRecordReplay>
    </Control>
</Controls>

You can validate your toolkit configuration file against: <UFT One installation folder>\bin\java\sdk\eclipse\plugins\com.mercury.qtjext.plugin.QTJavaExt_1.0.0\ToolkitSchema.xsd

For information on the structure and syntax of the toolkit configuration file, see the Toolkit Configuration Schema Help.

For information on where to store the toolkit configuration file, see Deploying and Running the Custom Toolkit Support.

Back to top

Understanding the Test Object Configuration File

If you map custom controls to new (or modified) test object classes, you must create one or more test object configuration files in the custom toolkit support set. For more information, see Mapping a Custom Control to a Test Object Class.

In a test object configuration XML, you define the test object classes (for example, the test object methods they support and their identification properties).

You can also create a definition for an existing test object class in the test object configuration XML. This definition is added to the existing definition of this test object class, affecting all test objects of this class. It is therefore not recommended to modify existing test object classes in this way. For example:

• If you add a test object method, it appears in the list of test object methods in UFT One, but if you use the test object method in a test, and it is not implemented for the specific object, a run-time error occurs.

  If you add test object methods to existing test object classes, you might add a prefix to the method name that indicates the toolkit support for which you added the method (for example, CustomButtonClick, CustomEditSet). This enables test designers to easily identify the custom methods and use them in test steps only if they know that the custom method is supported for the specific object.

• If you add an identification property, it appears in UFT One in the list of properties for all test objects of this class, but has no value unless it is implemented for the specific supported object.

In the test object configuration XML file, you create a ClassInfo element for each test object class that you want to define. In addition, you define the name of the environment or custom toolkit for which the test object classes are intended (in the PackageName attribute of the TypeInformation element), and the UFT One add-in which these test object classes extend (in the AddinName attribute of the TypeInformation element).

If the relevant add-in is not loaded when UFT One opens, UFT One does not load the information in this XML. Similarly, if the name of the environment or custom toolkit is displayed in the Add-in Manager dialog box and its check box is not selected, the information in this XML is not loaded.

For more information, see How UFT One Loads the Test Object Configuration XML .

The sections below describe the information that you can include in a test object class definition.

Class Name and Base Class

The name of the test object class and its attributes, including the base class—the test object class that the new test object class extends (relevant only when defining new test object classes). A new test object class extends an existing JavaUFT One test object class, directly or indirectly. The base class may be a class delivered with UFT One or a class defined using Java Add-in Extensibility.

By default, the base class is JavaObject.

The test object class name must be unique among all of the environments whose support a UFT One user might load simultaneously. For example, when defining a new test object class, do not use names of test object classes from existing UFT One add-ins, such as JavaButton or JavaEdit.

Note:

• A test object class inherits the base class' test object operations (methods and properties), generic type, default operation, and icon. Identification properties are not inherited.

• If you create test object classes that extend test object classes defined in 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.

Generic Type

The generic type for the test object class, if you are defining a new test object class and you want the new test object class to belong to a different generic type than the one to which its base class belongs. (For example, if your new test object class extends JavaObject (whose generic type is object), but you would like UFT One to group this test object class with the edit test object classes.)

Generic types are used when filtering objects (for example, in the Step Generator's Select Object for Step dialog box and when adding multiple test objects to the object repository). Generic types are also used when creating documentation strings for the Documentation column of the Keyword View (if they are not specifically defined in the test object configuration file).

Test Object Operations

A list of operations for the test object class, including the following information for each operation:

• The arguments, including the argument type (for example, String or Integer), direction (In or Out), whether the argument is mandatory, and, if not, its default value.

• The operation description (shown in the Object Spy and as a tooltip in the Keyword View and Step Generator).

• The Documentation string (shown in the Documentation column of the Keyword View and in the Step Generator).

• The return value type.

• A context-sensitive Help topic to open when F1 is pressed for the test object operation in the Keyword View or Editor, or when the Operation Help button is clicked for the operation in the Step Generator. The definition includes the Help file path and the relevant Help ID within the file.

Default Operation

The test object operation that is selected by default in the Keyword View and Step Generator when a step is generated for an object of this class.

Identification Properties

A list of identification properties for the test object class. You can also define:

• The identification properties that are used for the object description.

• The identification properties that are used for smart identification. (This information is relevant only if smart identification is enabled for the test object class. To enable smart identification, use the Object Identification dialog box in UFT One.)

• The identification properties that are available for use in checkpoints and output values.

• The identification properties that are selected by default for checkpoints (in the UFT One Checkpoint Properties dialog box).

When defining identification properties, it is recommended to start by copying existing identification properties from the base object in your schema or from similar objects in related toolkits.

Icon File

The path of the icon file to use for this test object class. (Optional. If not defined, the base class' icon is used.) The file can be a .dll, .exe, or .ico file.

Help File

A context-sensitive Help topic to open when F1 is pressed for the test object in the Keyword View or Editor. The definition includes the .chm Help file path and the relevant Help ID within the file.

You can practice creating support for a custom control that is mapped to a new test object class in the tutorial lesson Learning to Support a Complex Control.

You can validate your test object configuration file against: <UFT One installation folder>\bin\java\sdk\eclipse\plugins\com.mercury.qtjext.plugin.QTJavaExt_1.0.0\ClassesDefintions.xsd

For information on the structure and syntax of a test object configuration file, see the UFT One Test Object Schema Help.

For information on the location in which to store the test object configuration file, see Deploying and Running the Custom Toolkit Support.

Test Object Configuration File Example

The following example shows parts of the test object configuration file that defines the Calculator test object class definition for the javaboutique custom toolkit:

<TypeInformation Load="true" PackageName="javaboutique" AddinName="Java">
    <ClassInfo BaseClassInfoName="JavaApplet"DefaultOperationName="Calculate" Name="Calculator">
        <IconInfo IconFile="C:\Program Files\OpenText\Unified Functional Testing\samples\Javaboutique\Calculator_3D.ico"/>
        <TypeInfo>
            <Operation ExposureLevel="CommonUsed" Name="Calculate"PropertyType="Method">
                <Description>Builds the whole calculation process</Description> 
                <Documentation><![CDATA[Perform %a1 operation with %a2 and %a3 numbers]]></Documentation> 
                <Argument Direction="In" IsMandatory="true" Name="operator">
                    <Type VariantType="Variant"/>
                </Argument>
                <Argument Direction="In" IsMandatory="true" Name="num1">
                    <Type VariantType="Variant"/>
                </Argument>
                <Argument Direction="In" IsMandatory="true" Name="num2">
                    <Type VariantType="Variant"/>
                </Argument>
            </Operation>
            ...
        </TypeInfo>
        <IdentificationProperties>
            <IdentificationProperty ForVerification="true" ForDefaultVerification="true "Name="value"/>
            <IdentificationProperty ForVerification="true" Name="objects count"/> 
            <IdentificationProperty Name="width"/>
            <IdentificationProperty ForDescription="true" Name="toolkit class"/>
            ...
        </IdentificationProperties>
    </ClassInfo>
</TypeInformation>

This example shows that the Calculator test object class extends the JavaApplet test object class. It uses the Calculator_3D.ico icon file, and its default test object method is Calculate (which has three mandatory input parameter of type Variant:operator, num1 and num2).

The PackageName attribute in the TypeInformation element indicates that the Calculator test object class is created for the javaboutique toolkit support.

The following identification properties are defined for the Calculator test object class:

• value. Available for checkpoints and selected by default in the Checkpoint Properties dialog box in UFT One.

• objects count. Available for checkpoints but not selected by default.

• toolkit class. Used for the test object description but not available for checkpoints.

How UFT One Loads the Test Object Configuration XML

Each time you run UFT One, it reads all of the test object configuration files and merges the information for each test object class from the different files into one test object class definition. For more information, see Understanding How UFT One Merges Test Object Configuration Files.

The following attributes of the Identification Property element in the test object configuration file specify information that can be modified in UFT One (using the Object Identification dialog box): AssistivePropertyValue, ForAssistive, ForBaseSmartID, ForDescription, ForOptionalSmartID, and OptionalSmartIDPropertyValue. These attributes determine the lists of identification properties used for different purposes in UFT One.

Therefore, by default, UFT One reads the values of these attributes from the XML only once, to prevent overwriting any changes a user makes using the Object Identification dialog box. In this way, UFT One provides persistence for the user defined property lists. For more information, see Modifying Identification Property Attributes in a Test Object Configuration File.

Back to top

Understanding Custom Support Classes

In a custom toolkit support set, there is a custom support class for each supported custom class. The custom support class provides the actual interface between the custom class methods and the UFT One capabilities, thus providing the UFT One Java Add-in Extensibility.

A single custom support class can provide support for more than one custom class. The support class can be mapped (in the toolkit configuration file) to more than one custom class. This support class then provides support for the custom classes that are mapped to it, and for their descendants.

For details, see Understanding Custom Support Classes.

Back to top