Implementing Custom Toolkit Support

You implement Java Add-in Extensibility by creating a custom toolkit support set for each Java toolkit you want to support. The custom toolkit support set is comprised of Java classes and XML configuration files. The Java classes you create extend existing Java Add-in classes and the support they provide, by overriding their methods and defining new ones.

This section explains how to create support for a custom toolkit. It explains what files you have to create for the custom toolkit support set, the structure and content of these files, and where they should be stored.

In this topic:

About Custom Toolkit Support

When you extend UFT One support of a custom toolkit, you create an API that is based on the existing UFT One Java Add-in and supplements it. This API, or custom toolkit support set, is composed of Java classes and XML configuration files. It provides an interface between UFT One and the Java application being tested, enabling UFT One to identify the Java controls in the application and correctly perform operations on those controls.

This section describes the different files, classes, methods, and definitions that you must include in a custom toolkit support set. For more information, see the API Reference.

Before you begin to create a custom toolkit support set, you must plan it carefully. For more information, see Planning Custom Toolkit Support.

The UFT One Java Add-in Extensibility SDK provides a plug-in for the Eclipse Java development environment, which provides wizards that help you create custom toolkit support sets. This plug-in also provides a set of commands that you can use to edit the files after they are created.

When you use the Java Add-in Extensibility wizards to create the custom toolkit support, the wizards create all of the required files, classes, and basic methods. They also provide method stubs for additional methods that you may need to implement.

To gain a better understanding of designing custom toolkit support sets before you begin to design your own, perform the lessons in Tutorial: Learning to Create Java Custom Toolkit Support. In these lessons you use the Java Add-in Extensibility wizards in Eclipse to create custom support for sample custom controls.

Even if you do not regularly use Eclipse to develop Java software, it is recommended that you use it for Java Add-in Extensibility, at least for performing the tutorial. It is generally simpler to create the skeleton of the custom toolkit support with the help of the Java Add-in Extensibility wizards than to do it manually. After you have completed this initial stage, you can continue the design of the toolkit support in the development environment of your choice.

For information on setting up Eclipse and the UFT One Java Add-in Extensibility Eclipse plug-in, as well as using the plug-in, see Installing the OpenText UFT One Java Add-in Extensibility Software Development Kit.

If you choose not use the Java Add-in Extensibility wizards in Eclipse, you can still extend full support for the custom toolkit manually by using the information in this section.

Back to top

Introducing Java Add-in Extensibility Terminology

The following terminology, specific to UFT One Java Add-in Extensibility, is used in this guide:

Back to top

Preparing to Create Support for a Custom Toolkit

You can extend UFT One support for any toolkit containing classes that extend java.awt.Component or org.eclipse.swt.widgets.Widget.

When you create a custom toolkit support set for each custom toolkit, the first step is to determine the set of classes that comprise your custom toolkit. For the purpose of Extensibility, a custom toolkit is a set of classes that extend the basic user interface component of the same native toolkit.

This does not prevent you from creating support for a toolkit containing classes that extend java.awt.Component, as well as those that extend org.eclipse.swt.widgets.Widget. Such a toolkit is simply seen as two separate custom toolkits, and you must create support separately for each set of classes.

Similarly, if you have user interface control classes that extend the basic user interface component of the same native toolkit, and are packaged in separate Java archives or class folders, you can treat them as one custom toolkit. This means you can create a single custom toolkit support set for all those classes.

Within a custom toolkit, you extend UFT One support for each control (or group of similar controls) separately. You do this by creating custom support classes for the different custom control classes in the toolkit. (In this guide, custom support classes are also referred to as support classes.)

Before you extend UFT One support for a custom control make sure you have full access to the control and understand its behavior. You must have an application in which you can view the control in action, and also have access to the class that implements it.

You do not need to modify any of the custom control's sources to support it in UFT One, but you do need to be familiar with them. For example, make sure you know which members (fields and methods) you can access externally and what events you can listen for. You use this information when you design the support class. To implement the interface between UFT One and the custom class, the support class uses custom class members. The support class can only access the members of the custom class that are defined as public.

In addition, you need access to the compiled classes in a Java archive or class folder because you add them to the classpath when compiling the support classes.

Back to top

Workflow for Implementing Java Add-in Extensibility

The following workflow summarizes the steps you need to perform to create UFT One Java Add-in Extensibility support for a custom toolkit, and the order in which you need to perform them. Follow these steps for each custom toolkit you want to support:

* You can use the wizards in the UFT One Java Add-in Extensibility Eclipse plug-in to create the custom toolkit support project, the custom classes, and all of the required files. Alternatively, if you choose not to use the wizards, you must create the necessary packages and files manually, as described in Creating a Custom Toolkit Support Set. In addition, if you then decide to map custom classes to new test object classes, you must define the new test object classes in a test object configuration file.

Back to top

Next steps:

• Creating a Custom Toolkit Support Set

• Understanding your Custom Toolkit Support Set

• Deploying and Running the Custom Toolkit Support

• Logging and Debugging the Custom Support Class