Solved
JScript vs VBScript
Hi all
I've been using TestComplete for a few years now and have been writing scripted tests in VBScript and have to say that I've never encountered any problems with doing so (at least no issues with VBScript!!)
I'm now trying my hand at JScript and, thus far, have managed to replicate one of my class files that I'd written in VBScript. I've even got my head round the idea of prototyping, in that I've created a function (class for want of a better description) and have added several methods to its prototype. I can cerate an instance of it in anouther project and call any of the methods - so far, so good. I am, however, finding it a little frustrating in the way I have to handle any application properties that I need to work with. For example, in VBScript, if I need to work with the contents of a text field and compare it to another string value, I simply use the wText or Text properties, something like this:
In JScript, the only way I can get this to work is like this:
I find that I also have to do similar conversions when working with integer values using the Number function.
Am I missing something here or is this just how JScript must work? It seems like a lot of extra work. Since JScript doesn't have typed variables (like VBScript), why can't it just work directly with the properties? Is it because everything in JScript is an object and in the case of strings and integers (and presumably other primitive types), we need to do an explicit conversion?
Any assistance or explanations welcome!!
Regards
Stephen.
I've been using TestComplete for a few years now and have been writing scripted tests in VBScript and have to say that I've never encountered any problems with doing so (at least no issues with VBScript!!)
I'm now trying my hand at JScript and, thus far, have managed to replicate one of my class files that I'd written in VBScript. I've even got my head round the idea of prototyping, in that I've created a function (class for want of a better description) and have added several methods to its prototype. I can cerate an instance of it in anouther project and call any of the methods - so far, so good. I am, however, finding it a little frustrating in the way I have to handle any application properties that I need to work with. For example, in VBScript, if I need to work with the contents of a text field and compare it to another string value, I simply use the wText or Text properties, something like this:
if (aTextBox.wText = myCompareStr) then ....end if
In JScript, the only way I can get this to work is like this:
var textBoxText = new String(aTextBox.text);
textBoxText = textBoxText.toString();
if (textBoxText == myCompareStr) {.......}
I find that I also have to do similar conversions when working with integer values using the Number function.
Am I missing something here or is this just how JScript must work? It seems like a lot of extra work. Since JScript doesn't have typed variables (like VBScript), why can't it just work directly with the properties? Is it because everything in JScript is an object and in the case of strings and integers (and presumably other primitive types), we need to do an explicit conversion?
Any assistance or explanations welcome!!
Regards
Stephen.
- Hi Stephen,
This is interesting... I never ran into your issue because all our application (VS C++) elements that respond to wText return a String.
With the following test code:
function someString() {
this.type = "someString";
}
someString.prototype.getString = function (){
return new Object("aString for class " + this.type);
}
function TestStringVar()
{
var aStringObject = new someString();
var anObject = new Object("someOtherString");
Log.Message(aStringObject.getString());
Log.Message(aStringObject.getString().toLowerCase());
Log.Message(aStringObject.toString());
// This raises the exception that triggered this thread
//Log.Message(aStringObject.toLowerCase());
Log.Message(anObject.toLowerCase());
Log.Message(anObject.toString());
Log.Message(anObject);
}
And with your code, I can reasonnably assume that if textBox.wText.toLowerCase() doesn't work, textBox.wText.toString().toLowerCase() will.
Sincerely
