"But of course, Script Extensions can use other scrípt extensions, so modularization is not too difficult."
Yeah. I know they can call each other. I already do that with some other extension scripts.
But in the case of a VBScript custom class, does this mean I have to make the helper function avilable as a method of the extension containing the custom class declaration? In order for the other extension units to be able to call it?
In TC VBScript, a custom class instance can only be declared in the unit it's scripted in.
If another unit wants to use an instance of the class, it has to call into a "helper" function of the unit containing the custom class, and the function will pass back the class instance as the response. This is normally (in a standard script unit), done via the USEUNIT statement.
But I don't think that works in Script Extensions?
So for Ext-Unit 2 to get a custom class instance back from Ext-Unit 1, Ext-Unit 1 needs to make the function available to call in to retrieve the instance?
So if my helper function lived in "Unit1" and was called "Helper1", to get an instance of my class in unit 2, I would need to enable calls to Unit1 from unit 2 and then have something along the lines of:
Set NewThing = Unit1.Helper1
I can't just do:
USEUNIT Unit1
and
NewThing = Helper1
I wanted the class creating module to be self-contained within the extensions. I don't need, or want to make it available outwith the other extension units which will be using it. I suppose, I don't need to set up the code complete XML for it as I don't want it being used outwith the framework extensions.
Extension units effectively form a test framework for me. This is new functionality to extend our framework further ....
You're completely right:
"Set NewThing = Unit1.Helper1
I can't just do:
USEUNIT Unit1
and
NewThing = Helper1"
That's the way it works.
You do have the choice of
a) handing out an object of Your class Unit1.InternalClass, or
b) provide routines in Unit1, which use the InternalClass to provide their service.
In case of a), the class members do not have to be declared in the XML definition, so they are not visible for code completion. But it can be done, just add empty sub and function definitions with the member names outside the class definition and add these to the XML.
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 ....
