Was still searching after posting this. This post:
Mentions some disadvantages to Script Extensions. Number 1 being they can't reference other script units.
Can someone (either who has used it or staff/mod) confirm? If this is the case, my parser will have to live in the same extension unit as all the TFS functions. I'm starting to set up the TFS functions now (I write all the VBScript as a normal TC project then ship it out to create the TCX file for the extension) so I'd rather not have to restructure it and change all my class declarations if I can't separate the two .....
Thanks again!
Script Extensions can't use script units, that's true.
But of course, Script Extensions can use other scrÃpt extensions, so modularization is not too difficult.
Another point is, that Script Extensions can't use all of the libraries available in script units.
As a workaround, references to the missing libraries can be handed into the Script Extension e.g. via an initialization routine and stored there on a module-global level. After using the Extension, they should be reset to Nothing in a shutdown routine.
Initialisation and shutdown can be done in event routines
GeneralEvents_OnStartTest, GeneralEvents_OnStopTest
Regards,
Manfred
"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 ....
