Calling //job from //job in .wsf

[Marcus E. Carlson]

Greetings All:

I'm creating a .wsf file with multiple jobs. I want to call other (sub) jobs
from Main job or control job execution sequence dynamically. Is this
possible or should I just write sub routines to accomplish basically the
same thing? Also, do jobs execute in order, first job auto-magically per
docs, until no more jobs or can I stop file execution at end of first (main)
job with WScript.Quit?

I can't seem to get other jobs to execute when called from Main job. I've
tried:

OtherJobId
and
file://job:OtherJob

(ignore 'file:' in above, OE auto-magically inserts)

I'm either syntactically challenged or barking up the wrong tree.

Insights appreciated,

Marcus

[Michael Harris]

When you define more than one <job> in a wsf file, you can only execute one job at a time.  By default, the 1st job is executed.  To execute any other, use (ignore the _ )

 

wscript_//job:foobar

 

to execute <job id="foobar">

 

When executing any given job, you can't access anything in any of the other <job> elements.  As far as the current job is concerned the other jobs don't exist.  You can use a WScript.Shell object's Run method to execute other jobs using the wscript_//job:jobid syntax above.  But you have limited communication between jobs.  You can pass command line arguments to the 2nd job and it can return a numeric exit code, but that's about it.

 

To share common code across jobs, you have 2 choices...

 

1) put the common code in separate .vbs/.js file and "include" them with

 

<script language="vbscript" src="path\commoncode.vbs" />

<script language="jscript" src="path\commoncode.js" />

 

where path can be absolute (fully qualified) or relative to the folder containing the .wsf file.

 

2) convert the common code to public methods of a Windows Script Component (a .wsc  file), register the .wsc file as a component, and "include" it with

 

set cc = createobject("commoncode.wsc")

or

set cc = getobject("script:fullpath\commoncode.wsc")

 

assuming you used commoncode.wsc as both filename and the progid when you created the .wsc file.   If you use the getobject method with the "script:" COM moniker, you don't need to register the component (in fact it doesn't even need a <registration> element.

 

Now subs/functions are called as object methods

 

result = cc.myfunction(<myarguments>)

cc.mysub arguments <myarguments>

 

HTH

 

--
Michael Harris

 

 

"Marcus E. Carlson" <m...@hepco.com> wrote in message news:#HRH583Z$GA.202@cppssbbsa05...

[Marcus E. Carlson]

Michael:

Excellent info. I guess I'll stick to sub/function routines :-) I do have a
question on the following:

<snip>

2) convert the common code to public methods of a Windows Script Component
(a .wsc file), register the .wsc file as a component, and "include" it with

set cc = createobject("commoncode.wsc")
or
set cc = getobject("script:fullpath\commoncode.wsc")

assuming you used commoncode.wsc as both filename and the progid when you
created the .wsc file.
If you use the getobject method with the "script:" COM moniker, you don't
need to register the component (in fact it doesn't even need a
<registration> element.

Now subs/functions are called as object methods

result = cc.myfunction(<myarguments>)
cc.mysub arguments <myarguments>

</snip>

How do you specify progid or does it just happen when you create the .wsc
file?
Not sure I follow the "..don't need to register" approach. I thought you had
to register. Do the docs explain this? So if I had a .wsc file I wouldn't
have to register on all my clients I could just do the following:

result = [relative path | <share>] \cc.myfunction(<myarguments>) ?

I would appreciate furthur info,

Marcus

[Marcus E. Carlson]

Thanks G., your sites been a solid resource for me.

Marcus

Günter Born <Guente...@csi.com> wrote in message
news:86m5r5$f13$1...@ssauraab-i-1.production.compuserve.com...
> Shell the 2nd job using run
>
> Set oAdr = CreateObject ("WScript.Shell")
> oAdr.Run "WScript.exe file://J:Jobname " & wsf-file
>
> G. Born
>
> Check out the WSH Bazaar at:
>
> http://ourworld.compuserve.com/hompages/Guenter_Born/index0.htm
>
>
>
>
> Marcus E. Carlson schrieb in Nachricht <#HRH583Z$GA.202@cppssbbsa05>...

[Michael Harris]

Download the "Script Component Wizard" and it handles those details for you...

 

Windows Script Component Wizard released

--
Michael Harris

 

 

"Marcus E. Carlson" <m...@hepco.com> wrote in message news:eAw$JMBa$GA.259@cppssbbsa04...

Michael:

Excellent info. I guess I'll stick to sub/function routines :-) I do have a
question on the following:

<snip>

2) convert the common code to public methods of a Windows Script Component
(a .wsc  file), register the .wsc file as a component, and "include" it with

set cc = createobject("commoncode.wsc")
or
set cc = getobject("script:fullpath\commoncode.wsc")

assuming you used commoncode.wsc as both filename and the progid when you
created the .wsc file.
If you use the getobject method with the "script:" COM moniker, you don't
need to register the component (in fact it doesn't even need a
<registration> element.

Now subs/functions are called as object methods

result = cc.myfunction(<myarguments>)
cc.mysub arguments <myarguments>

[Michael Harris]

Missed part 2 of the question...

 

The --> set cc = getobject("script:drive\path\foobar.wsc") <-- syntax is tucked away in the Windows Script Components tutorial.   When creating an instance of a wsc this way, the "component engine" (scrobj.dll) knows exactly where the source for the component is (note that the current (5.1) version of scrobj.dll doesn't support relative paths).  That's why it doesn't need to be registered with a progid or even need a registration element.  But this applies only to creating an instance.  After that you access it normally.

 

It's a good idea to read the tutorial, because there quite a few things in there that (IMO) should be included in the "reference" section...

 

Script Component Tutorial
http://msdn.microsoft.com/scripting/scriptlets/doc/lettitle.htm

 

--
Michael Harris

 

 

"Marcus E. Carlson" <m...@hepco.com> wrote in message news:eAw$JMBa$GA.259@cppssbbsa04...

Michael:

Excellent info. I guess I'll stick to sub/function routines :-) I do have a
question on the following:

<snip>

2) convert the common code to public methods of a Windows Script Component
(a .wsc  file), register the .wsc file as a component, and "include" it with

set cc = createobject("commoncode.wsc")
or
set cc = getobject("script:fullpath\commoncode.wsc")

assuming you used commoncode.wsc as both filename and the progid when you
created the .wsc file.
If you use the getobject method with the "script:" COM moniker, you don't
need to register the component (in fact it doesn't even need a
<registration> element.

Now subs/functions are called as object methods

result = cc.myfunction(<myarguments>)
cc.mysub arguments <myarguments>

[Michael Harris]

Clarence's and Ian's site are probably the best you'll find for general scripting.  

 

If you're willing to part with about $20, I'd recommend picking up a copy of "VBScript Programmer's Reference" from Wrox Press.  It does an excellent job of introducing nearly all of the scripting "host contexts" where you can use vbscript, including a full chapter on windows script components.

--
Michael Harris

 

 

"Marcus E. Carlson" <m...@hepco.com> wrote in message news:O9LXUvEa$GA.1532@cppssbbsa06...

Already got it. Been reading the documentation and now realize there's more than meets the eye with these scripting technologies. My head's starting to spin! I'm not sure I've been able to sort out when to create a vbs file, a wsf file or a wsc file.

 

I've found lots of WSH, VBS/JS resources but few Component resources. Know anybody with a site devoted primarily to Script Components? I've read most the msdn articles but the examples are fairly light, though beneficial.

 

It seems like there is quite a bit of overlap amongst the technologies as a wsf or wsc file can contain any supported language so when's it best to use which technique? Do you create stand alone vbs/js files and "src=..." them in a wsf? Create stand-alone vbs/js files that call jobs in a wsf file that has a "src=.." to outside vbs/js files? Create a wsf that instantiates a component? Create a Component with multiple <component> elements that can reference each other? Sheesh, I'm confused. Any recomendations on "best practices"?

 

TIA,

 

Marcus

 

Michael Harris <Please...@To.NewsGroup> wrote in message news:#qeY9cEa$GA.264@cppssbbsa04...

[Marcus E. Carlson]

[Marcus E. Carlson]

Thanks.

 

Marcus

 

Michael Harris <Please...@To.NewsGroup> wrote in message news:OT3qWzEa$GA.259@cppssbbsa04...

[Günter Born]

Shell the 2nd job using run

Set oAdr = CreateObject ("WScript.Shell")

oAdr.Run "WScript.exe //J:Jobname " & wsf-file