Forum Discussion

Colin_McCrae's avatar
Colin_McCrae
Community Hero
10 years ago

VBScript - Custom classes in Script Extensions?

Hi

 

Hopefully a simple question.

 

In a normal VBScript unit, you need to use a small helper function to pass an instance of a new class to a separate script unit.

 

(As per VBScript specifics here: http://support.smartbear.com/viewarticle/72409/ )

 

Which is fine.

 

Does the same logic hold true if the routines in question will become Script Extension units?

 

I'm adding much bigger TFS integration to my framework. It's using the new RESTful API into TFS so I have a JSON parser which will be used pretty frequently throughout all the TFS custom controls I'll be adding.

 

However, I would like to separate the JSON parser into it's own module.

 

So, do I still need to use the helper function way of creating new instances outside the (extension) script unit where the parser lives? Or is the logic different in Extensions and I can just declare the new instance directly in whatever module?

 

Thanks!

  • PS - In case anyone is wondering, I'm using the JSON parser from here:

     

    http://www.aspjson.com/

     

    The only thing I've had to change in the code for it so far, is this small function:

     

    	Public Function Collection()
    		set Collection = Server.CreateObject("Scripting.Dictionary")
    	End Function

     

     

    Just remove the "Server." part. It's not required in TC. So it simply becomes:

     

    	Public Function Collection()
    		set Collection = CreateObject("Scripting.Dictionary")
    	End Function

     

    I've only been using it to read thus far. Haven't tried writing with it yet. But the iterable object returned for a read action seems to be spot on. Saved me a lot of work!

     

    (And I'm much more familiar with VBScript, hence why I'm using it for the Script Extensions - in case anyone thinks I'd be better using Jscript)

    • Colin_McCrae's avatar
      Colin_McCrae
      Community Hero

      Was still searching after posting this. This post:

       

      http://community.smartbear.com/t5/Getting-Started-with/A-simple-example-of-script-extension-to-maintain-common-scripts/m-p/85551#M16123

       

      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!

      • Manfred_F's avatar
        Manfred_F
        Regular Contributor

        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