OK.
Have set the parser up as a standalone script extension. With a tiny helper function (which is the bit you actually call from script units) which passes back a new instance of the custom JSON object.
I had this set up in a script unit initially and had been using USEUNIT and calling it from another script unit until today.
Today, I packaged it up into a script extension and added the extension to TestComplete. The USEUNIT inclusion has been removed. I've checked the script extension has loaded OK, and it has. Comes up in code complete as expected as well.
Which is where it started getting wierd.
What I call is identical. I haven't chasnged the actual parser unit for ages. So the same little helper function still gets called, and it returns the same type of object it always has. Only difference is it's now via a script extension rather than USEUNIT. All calls to it have obviously now been updated to the syntax of the script extension call.
It still works. It still returns a JSON object. The object still appears to contain all the right data.
BUT .....
I was using iterable loops to check through JSON blobs which contained lists. While calling it via USEUNIT, it worked fine. But with the object coming back from my script extension, iterable loops no longer seem to work?
The data is all still there. If I populate the index values manually in the debug watcher, they return all the right data. But,
For Each <MEMBER> in <JSON_OBJECT>.data(<CONTAINER>)
no longer works.
While it was called via USEUNIT, it worked perfectly. Thats the only thing I've changed. Everything else in the calling script is the same.
Any ideas? Have I missed something? I can't understand how it's all still there, but no longer iterable?
I'm confused ....
** EDIT **
To add a little more info ....
The error I get when calling it via script extension is "object not a collection". But, as I say, if I populate index numbers (for the items within the collection) in the debug watcher, it works just fine and reports back all the correct data.
I've verified this by calling it via USEUNIT, then commenting that out and calling it via script extension. The iterable loop works fine in the former but not the latter. Which doesn't make sense as the mere fact that the index values work manually implies it is indeed a collection.
If all else fails, I'll move the parser into the extension that deals with all the TFS calls. But I'd rather not as I may well end up wanting to use it elsewhere. Or I can get a count on the collection and use that I think - with an old skool numerically defined loop rather than an iterator.
But, it would be easier if the iterable loop just worked like it's supposed to ....
This remembers me of a problem I had using vbs script extensions and returning arrays to standard modules: I got the error "The application called an interface that was marshalled for a different thread".
I stopped using standard arrays and created a custom array class instead.
Maybe Your problem is similar, as You are also facing a problem with a container object.
Can't You use a different type of container (e.g. dictionary), as a workaround?
Thanks for the info.
Not sure how easy or not that will be. I didn't write the JSON parser, just found a ready made one online and incorporated it. I'll have a better look through it and see exactly what the object it creates is. But I don't want to end up writing/re-writing my own JSON parser so easier if I can work with whats there ....
I've just learnt the hard way that You shall never ever use vbscript for class-generation purpose in script extensions. It leads You to memory leaks, causing TC to fail.
They said Jscript was better, with the "CollectGarbage()" function You could do it...?
Main reason I use VBScript is I know it ...
It appears that the JSON object returned by the VBScript custom class in the script extension has a "count" property if it contains an array/list of elements.
So replacing my iterable loops with simple numeric ones based on the value of the "count" property seems to work OK. The index values work fine. End result is exactly the same as using an iterable loop.
Wasn't aware that memory leaks were another potential drawback of this! Keeping an eye on memory consumption at the moment. If it looks like it's going to be a problem (looks OK so far ...) then I'll think about switching it all over to Jscript.
