In my case, it's not a syntax problem but a transport problem. The JSCRIPT objects created within the context of the extension either are not 100% compatible with the JavaScript code or they lose some of the context.
I developed my framework code within the TestComplete IDE so I had all the syntax stuff worked out. It even worked PERFECTLY in that IDE environment because it was all JSCRIPT. So, whIle the SDK might have a lot more power, I think Script Extensions are still viable for framework construction.
EDIT: Specifically, the JScript array does not support the spread syntax. IF, somehow, I could create a Script Extension in JavaScript... THEN... things my be different.
I did some poking around today to see if I could determine if it is a JScript vs JavaScript... not exactly. It's more a matter of, as I mentioned, context. Encapsulated within the Script Extension itself, the objects created are completely useable as JScript. However, once the object is passed out of the ScriptExtension to the regular project, something gets lost in the transition.
For example, in the MusicBox extension I created, there is a constructor called Notes. Within the Script Extension, you would do the following:
function foo() {
var myNote = new Notes('C4', 2000);
if (myNote.constructor == Notes) Log.Message('It worked');
}
This would actually log the message just fine. Now, I expose that Notes constructor to the script extension as a method. So, MusicBox.Notes will return an object. So, if I change my ode just a little bit...
function foo() {
var myNote = new MusicBox.Notes('C4', 2000);
if (myNote.constructor == Notes) Log.Message('It worked');
}
No message gets logged. So, something is lost in the "translation" of the object from the Script Extension to the IDE where the constructor gets lost. This, I'm assuming, would be the problem no matter what language my extension is written in.
HKosova You seem to be one of the resident experts on JavaScript/JScript etc... Do you know if there is a work around for this limitation?
OK... I actually submitted this problem as a SmartBear customer care ticket because I just wanted to make sure that this wasn't a bug in TC and was actually a limitation in JScript extensions (can't vouch for VBScript).
It turns out that, technically speaking, there are two instances of the JScript engine in TestComplete. One is used for running the automation code, one is used for script extensions. The problem has to do with transporting objects from one instance to another... and apparently, even, transporting from the JScript engine instance for Script Extensions across to any other engine (VBScript, JavaScript, etc). It's something funky with JScript itself that it just doesn't play nice... it's not a TC issue, but an issue with JScript.
So, the JSON workaround that I've implemented is actually a good way of getting around this. Customer care also suggested that you can created an iterable collection of the fields or properties or methods on any object generated in the extension using aqObject. This worked VERY well as well. I did a quick performance check between using the JSON method or using aqObject and it doesn't seem like either one is faster or slower than the other for this particular situation.