Unified Functional Testing Practitioners Forum

Custom add-in question

Go to solution
Respected Contributor.

Custom add-in question



My development team gave me a custom QTP add-in for an extjs application. There seems to be some problem with the approach we took in developing the custom add-in especially the way we are identifying each extjs control in the application. For Ex: For a ExtJS dialog box we defined a new control in the add-in called ExtJSDialogBox. The following is the identification properties we defined in the toolkit config xml for the dialog box


<Condition prop_name="classname" expected_value="x-panel-default-framed-resizable" is_reg_exp="true" />


We are identifying dialog component using its CSS class.  In the recent release of the application, my qtp script failed because the class name has changed from x-panel-default-framed-resizable to x-panel-default-resizable


The extjs application developer says that this way of using css class is not reliable.  This is exactly what he said


"I don't think there's a consistent css class across floating elements. it's all controlled at the framework level (we don't do any direct DOM stuff - so if we make a change, there's not saying how it effects that layer) - so hypothentically if we change anything about the resizing component that css class could go away "


I would like to know what is the best approach to handling this situation? Is it that we always keelp changing these identification in the tool kit config xml release after release?




Respected Contributor.

Re: Custom add-in question

What you describe is the initial approach that we took - and we failed for the same reason.
A number of users have been asking HP for ExtJS support in UFT, but I think your example demonstrates exactly why this is unlikely to happen - ExtJS is very big, very flexible and almost every application will use it in a different way.

Anyway, our solution was to get our developers to add two new html properties to each major widget - a TYPE and a unique ID.
In the add-in we map each TYPE to a new UFT object class e.g. myCombo, myGrid myButton etc.
We then add new instances to the object repository identified by the unique ID.
In our framework library we use RegisterUserFunc to add methods for each of our new objects - these use CSS, Xpath, DP or other techniques to locate the standard html objects that make up each widget.

Hope this helps
Respected Contributor.

Re: Custom add-in question

Hi Jon


Thanks for the reply.


Can you please give me one example of this. For Ex: ExtJS Edit control


I never used Xpath and CSS.  Can you please give me an example of how the repository will be and how xpath and CSS is used.


I undertsand you are overriding the web methods you inherited using your own method names in the function library. Do you avoid writing javascript behind the scenes and use VBscript directly to identify the objects. Our cutom add-in has javascript running behind the scenes for each component and it assigns values to the properties of the components by traversing the DOM. The javascript also has some custom methods defined for each component whereever we require it.




Respected Contributor.

Re: Custom add-in question

Yes, you are correct, all the methods for the new classes are written in a standard UFT library using VBScript. This is more familiar to our team members and for development and maintenance we have found it quicker than having to switch to JavaScript and build a new add-in for every change. We do add a few additional properties for each component in the add-in using Javascript, but overall there is very little code.


This is a bit rough, but here's a simple example:


Our application has a component that behaves like a Combo box. For all instances of this component our developers have give it two new attributes, xType and xID:


So for a particular component, it will have:




We use the Extensibility Accelerator to create a new object class called "ComboBox" and map it as follows:


 function ControlId() {

     switch (_elem.getAttribute("xType")) {

        case "xCombo":

            return "ComboBox";

        case ..

        case ... 


    return null;



This causes all components that have the type xCombo to be recognised as ComboBox's. In the add-in we also add xId as a new property for the ComboBox class.


Now we can add objects of this type to the object repository. Each object will be seen as class ComboBox and identified by the property xId. Only components that have xType's and xId's are added to the repository.


Our framework defines methods for each new class, thus:


    RegisterUserFunc "ComboBox", "SetInput", "combobox_set_input"

    RegisterUserFunc "ComboBox", "Select", "combobox_select"

    RegisterUserFunc "ComboBox", "GetValue", "combobox_get_value"




' Locate the edit box in a combo and set it

Public Function combobox_set_input(oComboBox, sValue)


    Dim oInput


    Set oInput = oComboBox.WebEdit("html tag:=input")    ' using descriptive programming

    'Set oInput = oComboBox.WebEdit("css:=input")     ' OR using CSS selector


    oInput.Set sValue

End Function


We use it as follows:


Browser("app").Page("pg").ComboBox("CurrencyCombo").SetInput "Dollars"  

Respected Contributor.

Re: Custom add-in question

Thanks Jon. This really helps