This is an MS Access forum, you should redirect your questions about vbs to a
vbs forum.
As for an answer, I came across this a while back. It is the most complete
answer I have ever come across.
"You can call another VBScript using the Run method. The downside is
that they cannot share code and variables (variables can of course be
"transferred" using command line parameters or saving then in
registry/in a file).
Here is an example on how to run another script and pass it a parameter
on the command line:
Set WSHShell = CreateObject("WScript.Shell")
WSHShell.Run "wscript.exe c:\Test.vbs param1", , True
In the Test.vbs file, you access the command line parameters with the
WScript.Arguments object:
Set oArgs = WScript.Arguments
For i = 0 to oArgs.Count - 1
WScript.Echo oArgs(i)
Next
If you want to share code and/or variables, there are several other
ways of doing this. The different methods all have their pros and cons.
Here is a quick overview:
1)
Read the second script into a textstream and run ExecuteGlobal or
Execute on it.
Pros:
Can share all variables, functions and subs.
Easy to implement.
Cons:
If you have an error in the included script, you will not get the line
number where the error arised
Potential for namespace collisions (variable/proceduer names) since all
script elements share the same namespace.
2)
Use a Windows Script Host File (.WSF) file and include scripts with
script tag.
Pros:
Can share all variables, functions and subs.
Easy to run both VBScript and JavaScript code together.
If you have an error in a included script, you will get the line number
where the error arised.
Easy to implement.
Cons:
Potential for namespace collisions (variable/proceduer names) since all
script elements share the same namespace.
3)
Use a Windows Script Component (.WSC, a COM component written in script)
Pros
You will get a COM interface to your script library (that also can be
used by other programs)
Method/property drop down list and syntax help in editors that supports
typelibs
No namespace collisions (variable/proceduer names) since the script
elements does not share the same namespace.
Ideal for development environment with more than one developer
Cons
The most "complicated" solution
***********************************************************
Here are some more details for each method:
___________________________________________________________
1)
Read the second script into a textstream and run ExecuteGlobal or
Execute on it.
Load the 2. script into the 1. script at runtime (on the fly) and
execute it with ExecuteGlobal. They can then also share variables,
functions etc. The sub below does this loading:
Sub Include(sInstFile)
Dim oFSO, f, s
Set oFSO = CreateObject("Scripting.FileSystemObject")
Set f = oFSO.OpenTextFile(sInstFile)
s = f.ReadAll
f.Close
ExecuteGlobal s
End Sub
___________________________________________________________
2)
Use a Windows Script Host File (.WSF) file and include scripts with
script tag.
Using Windows Script Files (.wsf)
http://msdn.microsoft.com/library/en-us/script56/html/wsAdvantagesOfWs.asp
An example:
<?xml version="1.0" ?>
<package>
<job>
' this will run "file1.vbs"
<script language="VBScript" src="file1.vbs" />
' this will run "file2.vbs"
<script language="VBScript" src="file2.vbs" />
<script language="VBScript">
'
' Some script code here if you want ...
'
' You can use variables, subs and functions
' from the included files.
'
</script>
</job>
</package>
___________________________________________________________
3)
Use a Windows Script Component (.WSC).
Use a Windows Script Component (.WSC) to get a COM interface for your
VBSscript "library".
You can eg. use Windows Script Component Wizard to create one. Take a
look here for more info:
http://www.microsoft.com/downloads/...ED-FAAD-4835-8E68-773CCC951A6B&displaylang=en
Look up the Windows Script Components chapter in the docs.:
WSH 5.6 documentation download:
http://msdn.microsoft.com/downloads/list/webdev.asp
Windows Scripting Components - An Introduction
http://www.aspfree.com/c/a/Windows-Scripting/Windows-Scripting-Components--An-Introduction/
Optional methods to reference the WSC that is not registered from a script:
http://groups.google.co.uk/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=uKQPMyT1BHA.2736@tkmsftngp03
A simple WSC file example:
From: Michael Harris \(MVP\) (
[email protected])
Subject: Re: WSC and ProgID Versions
Newsgroups: microsoft.public.scripting.scriptlets
Date: 2001-10-01 07:04:22 PST
http://groups.google.co.uk/groups?selm=u$yWwGoSBHA.2076@tkmsftngp03
If you want to create a WSC with Self-Registering Typelib, take a
look at this article:
From: Torgeir Bakken (
[email protected])
Subject: Re: Creating a Self-Registering Typelib for a WSC
Newsgroups: microsoft.public.scripting.wsh
Date: 2002-06-09 09:40:06 PST
http://groups.google.co.uk/[email protected]
and
http://groups.google.co.uk/[email protected]
More about WSF/WSC in the thread below:
Subject: Implimenting a common.wsf file
http://groups.google.co.uk/groups?th=cb544426cdee2bdc
Also, if you go the WSC route, be sure not to have this
line in the WSC file if you create a self-registering
typelib:
implements id="Behavior" type="Behavior"
If you have it, the Write method for Scriptlet.TypeLib
will fail.
--
torgeir, Microsoft MVP Scripting and WMI, Porsgrunn Norway
Administration scripting examples and an ONLINE version of
the 1328 page Scripting Guide:
http://www.microsoft.com/technet/scriptcenter/default.mspx"
--
Hope this helps,
Daniel Pineault
http://www.cardaconsultants.com/
For Access Tips and Examples:
http://www.devhut.net
Please rate this post using the vote buttons if it was helpful.
