Re: Can I call a VBscript from another VBscript?
From: Al Dunbar [MS-MVP] (alan-no-drub-spam_at_hotmail.com)
Date: 05/20/04
- Next message: Al Dunbar [MS-MVP]: "Re: How hard would it be to script this process"
- Previous message: Michael Harris \(MVP\): "Re: Help me."
- In reply to: Wesley: "Re: Can I call a VBscript from another VBscript?"
- Next in thread: Torgeir Bakken \(MVP\): "Re: Can I call a VBscript from another VBscript?"
- Messages sorted by: [ date ] [ thread ]
Date: Wed, 19 May 2004 20:00:24 -0600
"Wesley" <anonymous@discussions.microsoft.com> wrote in message
news:56F1FD3B-A656-45FC-ABF7-DDC3265991A3@microsoft.com...
> Thanks to you and Al for your replies. I am catching on slowly. I got a
copy of VBscript Programmers Reference and had found COM objects but I still
have to read chapter 5 to get up to speed on the concepts.
>
> If I wanted to include Prog2.vbs in Prog1.vbs what would the code in prog1
look like? Or would prog1 be a .wsf extension instead of a .vbs.
>
> This seems a whole lot more complicated than writing a REXX exec on an IBM
VM or MVS mainframe. I know REXX exists for Windows systems but not in this
shop.
You are welcome.
I don't use REXX so I cannot comment on the relative complexity. There
certainly *are* some common scripting techniques that do not have a native
counterpart in WSH. The main one is the ability (or lack thereof) for one
script in one file to simply "call" another script in another file.
The main issue with this is that if you are used to doing this, whether in
batch, kixtart, or whatever, it may seem like a big loss. This is more so if
you think of your script files as containing chunks or sequences of
otherwise unrelated code to be executed in the context of the calling
script.
WSH tends to allow you to treat code more like objects, which can take a
while for a batch scripter to catch on to (and just wait until longhorn
comes along with its object-oriented update to batch, called monad). But I
digress...
Now to answer the questions in your second paragraph... it depends. One of
the main benefits of the .WSF format is that you can maintain a single copy
of your "library routines" in one or more .vbs (or .js) files, and
statically "include" them into any number of .wsf scripts that need them.
This is miles better than cutting and pasting individual routines into a
series of separate .vbs scripts. Just think of how much easier it will be to
provide each separate script with the new and improved version of one of
your functions - by editing the only copy!
For all but the simplest scripts I recommend .wsf over .vbs. Of course, the
XML syntax can be a bother, but that's what script editors such as
primalscript are for. I use .wsf scripts almost exclusively, but it has been
a long time since I actually saw the XML code.
I think I might have also mentioned the generic INCLUDE function. It is not
build in to vbscript, but must be written for (and included in) any script
that requires it. Each of us uses our own version, but the basic idea is
that it is passed the name of a .vbs file, reads the file in, and then
executes it, typically with the EXECUTEGLOBAL statement.
It is possible for the included code to be open ended script, written so as
to use variables defined in the code that calls it and to be "includable"
whenever needed. A better approach is to have the included script contain
only definitions, whether of subs, functions, global variables, or global
constants; to include it only once, and then to call the subs or reference
the functions it has defined. This is a more efficient approach if the
routine/script needs to be called many times, and is generally easier to get
the code right. Both methods have problems, though, in that syntactical and
other errors are not displayed showing the line number.
Finally, you can create external COM objects using windows script
components. These can be referenced in your script code without having to
write a specialized handler function like include.
/Al
- Next message: Al Dunbar [MS-MVP]: "Re: How hard would it be to script this process"
- Previous message: Michael Harris \(MVP\): "Re: Help me."
- In reply to: Wesley: "Re: Can I call a VBscript from another VBscript?"
- Next in thread: Torgeir Bakken \(MVP\): "Re: Can I call a VBscript from another VBscript?"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|