Thanks in advance,

chris

The Run method would look something like this ...

  ScriptFileName = "d:\somepath\scriptname.vbs"
  set oWS = CreateObject("Wscript.Shell")
  oWS.Run Wscript.FullName & " " & ScriptFileName, 1 , True

For more information on the syntax, see the WSH documentation.

The WSF file usage is best researched in the documentation.  See
'include' or '.wsf' in the Index.

Documentation (compiled html version for download) ...

  http://msdn.microsoft.com/scripting/windowshost/wshdoc.exe

Tom Lavedas
-----------
http://www.pressroom.com/~tglbatch/

If you need to execute several scripts in response to a given event, then how you would do that
depends on what each script needs to see when it executes.  By that I mean whether or not it needs
to be able to access the object model of the host application.

You'll need a "driver" script that is linked to the event that in turn executes the additional
scripts.  How you execute them depends on their need (or lack thereof) to access the host's object
model.

---> If no host object access is needed then use the WshShell.Run technique that has already been
suggested.

---> If host object access is needed, then you have a couple of choices.

One is to read the "child" scripts (to be executed) as a text files and then use Execute or
ExecuteGlobal to actually execute the text as code.  This executes the code in the same namespace as
the "driver" script, so the code will have access to the same host objects that the driver does.
The downside to this technique is that all of the dynamically executed code executes in the same
namespace as the "driver" which presents the possibility of namespace conflicts (names of variables,
procedures, etc.).  If the child scripts are carefully written, then that isn't a big issue.

The second method that avoids the namespace conflict problem is to write the child scripts as WSCs
(Windows Script Components).  The driver would create instances of the WSCs and pass references to
the host object model as needed.  The code within the WSC is a separate namespace so there is no
potential for namespace conflicts.

--
Michael Harris
Microsoft.MVP.Scripting
--

Please do not email questions - post them to the newsgroup instead.
--

Thank you for your post... The scripts will need access to objects that are
exposed by the host application (just as you anticipated).  The vendor has
indicated that registering all scripts with the host application even though
the main script is the only one tied to an event will make the child scripts
"available" to be called by main script.  I have attempted to simply call
the child script as you would any local procedure or function - with no
success (Main script exectes but does not execute the child script).  I will
explore your WSC suggestion as it seems to most closely resemble what I am
trying to do.
Assuming my vendor is not lying to me about the script registration and
script calling convention; any thoughts regarding the syntax for actually
calling a child procedure from another script (see code sample below)?

=[.vbs file 1]=================
'
' Main.vbs script - associated with host application event.
'
Sub Main()
    Call ChildProc()        ' Syntax in question for calling an external
procedure?
End Sub
'(eof)

=[.vbs file 2]=================
'
' ChildProc.vbs - only registered with host application.
'
Sub ChildProc()            ' the external procedure
    ' Do something...
End Sub
'(eof)

Thanks in advance... chris

I'm going to guess that you probably need to call the Functions or Subs in other "registered"
scripts as methods of a host provided object or objects.  When you "register" a script with the
application, do you need to assign it a unique name?  How do you "associate" a registered script
with an event?  By file name or via a registered name?  Is there a required convention for naming
the entry points into registered scripts associated with an application event?  ...???

Note that these are all rhetorical question...  Without knowing what the application (or who the
vendor) is and therefore not having access to any documentation (assuming they provide anything
useful ;-) this is only a guess on my part...

At least, if I were going to architect an application like this, I would do something similar.  In
fact, I would probably just use the MS Script Control and its Modules collection and the CodeObject
property of a Module....

--
Michael Harris
Microsoft.MVP.Scripting
--

Please do not email questions - post them to the newsgroup instead.
--