New behavior for JScript Object prototype property

Thank you for your reply. I have experienced what you just described about what happens when the code resides in different units. In this case however, the code where new methods are added to arrays, numbers and strings is located in the same file as the code using these. It used to work, but not anymore, even though nothing has been modified in my script.

I believe I have finally narrowed it down, and it appears the answer to my problem lies in your first comment about code in different units. I have included an example below to illustrate this. My extension of Array with a new method, and the usage of this method, are both located in Unit1. If I create the array in Unit1 and use the method "contains", then everything is OK. On the other hand, if I create the array in Unit2, as below, then I get an exception.



An array created in Unit2 is an array not extended with the method "contains". But since this worked before, I'm thinking maybe there has been a change in how arrays are handled when "passed between units". Is there any way I can recreate/clone the array created in Unit2 in Unit1, and this way have it be an array with the method "contains". Or do I have to include "Array.prototype.contains = ..." in Unit2 as well?





-- Unit1 --

-----------



//USEUNIT Unit2



Array.prototype.contains = function(element)

{

  for (var i=0; i<this["length"]; i++)

  {

    if (this == element)

    {

      return true;

    }

  }

  return false;

};



function Main()

{

  try

  {

    var myArray = CreateArray();

    myArray["contains"](2);

  }

  catch(exception)

  {

    Log["Error"]("Exception", exception["description"]);

  }

}





-- Unit2 --

-----------



function CreateArray()

{

  var a = new Array();

  a["push"](1);

  a["push"](2);

  a["push"](3);

  return a;

}

I finally went with your suggestion about using a string variable and execute the eval function in each unit. Works very well. Thanks!

Is this going to be fixed in TC8 or is it a limitation in TC that cannot be resolved?

So, what you're saying is that SmartBear has effectively broken any meaningful form of JScript inheritance, and that's just tough? That's ridiculous!



Sigh....



So what do you mean/how do you do:



1. Place the code to a string variable and share the variable between units.

2. In the global scope of each unit, call the eval function to execute the shared code - this should make the additional functions available in each of the units.



I'm trying to configure JScript code for WebService testing. We use a couple different web service API's. Things like the target test server, port # etc. are common to both types of API requests, but the attributes for the soap envelope are different. I was trying to construct a JScript library like such:



fw_WebService

    fw_WebService_EIM    //ws library for the EIM API

    fw_WebService_MSP   //ws library for the MSP API.



Both the API libraries should inherit functions like "targetServer", "port", etc. from the base "class". The base module also contains functions like "POST", so I don't have to rewrite them in each API. The "//USEUNIT" directive was supposed to make it unnecessary for me to have to copy the contents of fw_WebService into each of the API libraries, but apparently that  is no longer a practical idea.



So is there a relatively painless way to accomplish what I'm trying to do?

Hi David,





First of all, note that JScript does not support multiple units natively. This functionality is a feature of TestComplete. So, nothing has been "broken". Also, I'm not sure how the original thread is related to inheritance and your task - it considered prototypes, not inheritance.





Anyway, you can use the following approach:

1. In unit A, define a function which creates the base object you need.

2. In unit B, type "USEUNIT..." and define a function which calls the method from unit A and adds the additional methods/fields to the returned object.

3. In unit C (which is supposed to use the inherited object), use the method from unit B to get the inherited object you need.

Actually, that's not true. By accident I discovered that if you don't name the script files with the same name as the object being defined, the inheritance mechanism works perfectly, including the constructor functions. E.g.:



Script: mod_Person.sj:



function Person(fname) {

   this.setFirstname(fname);

}





Person.prototype.setFirstname(fname) {

    this.firstname = fname;

}



Person.prototype.toString = function() {

   return "Person = '" + this.firstname + "'";

}





Script: mod_Employee.sj:

//USEUNIT mod_Person



Employee.prototype = new Person();

Employee.constructor = Employee();

Employee.superclass = Person.prototype;



function Employee(fname, id) {

  this.setFirstname(fname);

  this.setID(id);

}



Employee.prototype.setID = function(id) {

    this.id = id;

}



Employee.prototype.toString() {

    return Employee.superclass.toString + ", id = '" + this.id + "'";

}

    



I typed that from memory, so I hope I got it all right.