This section explains how you can optimize your toolkit support.
Note that the implementation you used for the label identification property in the ImageLabel class is very similar to the implementation of the label identification property in the ImageButton class. Since both of these classes extend the ImageControl class, it might have been preferable to implement support for the label identification property in a support class for the ImageControl (ImageControlCS).
This means that when planning support for the ImageButton and ImageLabel controls, the answer to the second question in the Custom Class Support Planning Checklist would have been Yes (I should first extend support for a control higher in the hierarchy). ImageButtonCS and ImageLabelCS would then extend ImageControlCS, and in ImageLabelCS you would fine-tune the label property by overriding the inherited label_attr method.
In the following sections you modify the ImageControls toolkit support set to prevent the duplicate implementation of the label_attr method. The changes do not affect the functionality of the support. You create the ImageControlCS support class and modify ImageButtonCS and ImageLabelCS to extend ImageControlCS.
In this section, you create a custom support class for the ImageControl class in the ImageControlsSupport project.
Open the New UFT One Custom Support Class wizard.
In the Eclipse Package Explorer tab, select the new UFT One Java Add-in Extensibility project, ImageControlsSupport. Select File > New > Other. The New dialog box opens.
Expand the UFT One folder, select UFT One Custom Support Class and click Next. The Custom Class Selection screen opens.
Select the custom class to support, and set the options for the support class.
Expand the com.demo package and select the ImageControl class:
In the Custom toolkit tree pane, you can see that the ImageControl class is the only class in the com.demo package that is not yet supported.
In the Custom class inheritance hierarchy pane, you can see the hierarchy of the ImageControl class you have selected. The ImageControl class extends java.awt.Canvas, therefore the Base support class for the ImageControl support class you are creating is CanvasCS.
Leave the default name, ImageControlCS, for the ImageControl support class.
Click Next. The Test Object Class Selection screen opens.
Select a test object class to represent the custom control.
You are creating the ImageControlCS support class only to use it as a base support class for other support classes, not to support actual controls. Therefore, it is not important to which test object class you map the ImageControl custom class.
Perform the following:
Select Same as base support class. This maps the ImageControl custom class to whichever test object class is mapped to java.awt.Canvas. No direct mapping takes place. The new support class does not implement a to_class_attr method, but inherits it from the base support class.
Click Next. The Custom Support Test Object Identification Properties screen opens.
Determine the set of test object identification properties to implement in ImageControlCS.
This screen displays the identification properties supported by the base support class you are extending, as well as additional properties that are defined in the test object class you selected, but are not yet supported.
The left pane displays all of the identification properties whose support is implemented by CanvasCS, and therefore inherited by the new ImageControlCS support class. It enables you to select properties whose support you want to override with new functionality.
In the Test Object Class Selection screen, you did not select a specific test object class. Therefore, the wizard does not know which test object class is mapped to the ImageControl custom control. As a result, no identification properties are displayed in the right pane.
Select the label property by clicking its check box. After you finish generating the support files using the wizard, you will override the existing support for this property with a custom implementation that matches the needs of the custom control.
Click Next. The Custom Support Test Object Methods screen opens.
Determine the set of test object methods to implement in ImageControlCS.
This screen displays the test object methods defined in the test object class you selected.
In the Test Object Class Selection screen, you did not select a specific test object class. Therefore, the wizard does not know which test object class is mapped to the ImageControl custom control. As a result, no test object methods are displayed in this screen.
Consider that the ImageControl custom control does not have any test object methods that need to be supported.
Click Next. The Custom Control Recording Support wizard screen opens.
Determine the set of events for which to listen, to support recording on the ImageControl control.
This screen displays the event listeners implemented by the support class you are extending. It enables you to select event handler methods whose implementation you want to override with new functionality and to add new event listeners to implement.
In the left pane, you can see the listeners implemented by CanvasCS. You do not have to override any of these for the ImageControlCS custom support class.
Consider that you are creating the ImageControlCS support class only to use it as a base support class for other support classes, not to support actual controls. Therefore, it is not necessary to support recording on ImageControl controls.
Click Finish. The Custom Control Support Class Summary screen opens.
View the custom control support class summary.
Review the planned content of the custom support class, and click OK.
The following changes are made in the ImageControlsSupport project:
The ImageControls.xml file is modified to map the ImageControl custom class to its support class—ImageControlCS.
A new UFT One custom support class, ImageControlCS, is created in the ImageControlCS.java file in the com.mercury.ftjadin.qtsupport.imagecontrols.cs package. The file is opened and displayed in a tab in the right pane.
The ImageControlCS class extends CanvasCS and contains only one method stub—label_attr.
The asterisk (*) next to the ImageControlCS file name (in the ImageControlCS tab) indicates that it has not been saved. The changes made by the wizard are codependent, and must be saved to prevent discrepancies. Select File > Save, or click the Save button.
Implement the label_attr method in the ImageControlCS class.
In Eclipse, in the ImageControlCS.java file, in the label_attr method stub, replace
return super.label_attr(obj);with the following code, so that it returns the name of the image file used for the ImageControl (without the full path):
ImageControl ic = (ImageControl)arg0; String res = ic.getImageString(); if(res == null || res.length() == 0) return null; int last = res.lastIndexOf('/'); if(last == -1) return res; return res.substring(last+1);
Click the Save button, or select File > Save to save your changes.
The hierarchy of the support classes must match the hierarchy of the custom classes. Now that the ImageControl class is mapped to the support class ImageControlCS, the support classes for the ImageControl descendants must extend ImageControlCS.
Both ImageButtonCS and ImageLabelCS inherit label_attr method. ImageLabelCS needs to override this method to fine-tune its support of the label property.
Modify the ImageButtonCS class to extend ImageControlCS.
Open the ImageButtonCS.java file in the ImageControlsSupport project in Eclipse, and locate the ImageButtonCS class signature:
Modify the signature so that ImageButtonCS extends ImageControlCS:
Remove the label_attr method from the ImageButtonCS class.
Save the ImageButtonCS.java file.
public class ImageButtonCS extends CanvasCS implements ActionListener
public class ImageButtonCS extends ImageControlCS implements ActionListener
Modify the ImageLabelCS class to extend ImageControlCS.
In the ImageLabelCS.java file, replace
public class ImageLabelCS extends CanvasCSwith
public class ImageLabelCS extends ImageControlCS.
Replace the following lines in the label_attr method in the ImageLabelCS class:
Save the changes.
ImageLabel il = (ImageLabel)obj; res = il.getImageString(); if(res == null || res.length() == 0) return null; int last = res.lastIndexOf('/'); if(last == -1) return res; return res.substring(last+1);
When you created the new ImageControlCS support class, the wizard modified the ImageControls.xml file to map the ImageControl class to the ImageControlCS support class. Therefore, you must redeploy the ImageControls toolkit support for your changes to take effect.
Deploy the ImageControls toolkit support to UFT One.
In the Eclipse Package Explorer tab, select the ImageControlsSupport project.
Click the Deploy Toolkit Support button, or select UFT One > Deploy Toolkit Support. In the confirmation messages that open, click Yes and then OK.
Test the modified custom support.
Repeat the procedures in Planning Support for the ImageButton Control and Planning Support for the ImageLabel Control, to re-run the SampleApp application and to ensure that the support for ImageButton and ImageLabel is functioning properly.
Note: You did not change any test object configuration files, therefore you can use an open session of UFT One (running with the ImageControls custom toolkit support loaded).
The changes you made to the custom toolkit support set do not affect the way UFT One recognizes and tests the ImageLabel and ImageButton controls. However, the support for the label identification property for both of these controls is now inherited from the ImageControlCS class. If additional custom classes that extend ImageControl are created, their label property will be similarly supported on UFT One with no additional effort required.
You can find a ready-made example of the improved support for the ImageControls toolkit in the <UFT One Java Add-in Extensibility SDK installation folder>\samples\ImageControlsSupportAdvanced folder. (If you deploy this example manually, you must compile the Java classes before deploying.)