Ideas on VBS structure to allow common code

Question

To all the VBS Gurus out there...

I have written a suite of VB scripts (for automating installs, if you must know) which use a set of common functions for thing like logging, starting/stopping services etc.

I have come up with a design which uses a script which contains the common functions in a class. It also declares and instantiates a variable of the class type.
I also have a 'loader' script which checks to see if the class object exists and if it doesn't, runs the class script.

Each script I write includes a call to the loader, then I can call methods of the instantiated class.

It is quite a neat solution (IMHO) but I was wondering if anyone had any other/better ways of achieving the same?

- Pete

Note: This only applies to VB Scripts in .vbs files

Answer 1

We achieved the same in VB5.

In our application VB scripts were used to customize the business rules and even UI. There was an appropriate file structure , for example base classes were in base\ folder.

When VB application was running, we use MSScript control to run scripts. Initialization step was to load names of VBS files and create in memory an association tree. Then when VB need to call certain script, for example CreateNewCustomer(), an engine was informed that it should load in MSScript 2 files: CreateNewCustomer.vbs and base\CreateNewCustomer.vbs

In this case we implemented something that allows us to use inheritance in VBScripts.

Also, a reference to the our COM class, VBScriptEngine, was also passed to the MSScript control. So in any VBScript we were able to call VBScriptEngine.ExecuteScript("CreateNewCustomer", params) and it again can execute another VBScript

What was the challenge in this task is that we dont want to create and initialize too many instances of MSScript control, but MSScript control cannot execute another script when current script is not finished. So in our VBScriptEngine we have script execution stack. If any VBScript need to call another VBScript, we need to create a new MSScript control and put it in the stack. Sometimes we have nested calls that require 3 or more MSScript control simultaneously

Yes all this seems very strange nowadays when dynamic languages or dynamic assemblies in .NET could be used to achive better results with less efforts.