Class or WSC?

I'm working primarily in vbscript with wsh.

I have wsf files that do various tasks for me. The wsf files use
fn/subs stored in separate .vbs files by using <script> in the wsf
file. The code is growing and I'm finding the need from my .vbs files
to call other fns/subs. Up to this point I've used a combination of
ExcecuteGlobal, wshell.run and wsf files to pass/return parameters and
call routines. I'm wondering now if I should put all my functions/sub
into a class or a wsc and just reference this one file in all my wsf
programs. The class/wsc would have some disparate functions, but it
seems to suit the purpose. Should I? Which one, class or wsc? Why?
Are there other options to solve my problems?

If you too have question about passing values I highly recommend
looking at Torgeir Bakken's post:
http://groups.google.com/group/microsoft.public.scripting.wsh/msg/9ebc58d1b5f5c51f
He mentions wsc, but not a simpler class. Why?

One of the drivers of my problems is my need to create a cental place
for storing constants. I reference many network paths and I want a
central place to be able to easily make changes. My initial solution
was a text file to hold the constants and a function that uses ado to
look up the values of named constants. But my architecture of calling
vbs files from wsf files didn't work well since now my vbs files needed
to call another vbs function that looked up the constants. You can't
call wsf files from wsf files.

I've looked at wsc and type libaries, but is this overkill for my need
to grab some constants?

Thanks in advance!

mayayana
Wed Mar 15 13:13:21 CST 2006


> I'm working primarily in vbscript with wsh.
>
> I have wsf files that do various tasks for me. The wsf files use
> fn/subs stored in separate .vbs files by using <script> in the wsf
> file. The code is growing and I'm finding the need from my .vbs files
> to call other fns/subs. Up to this point I've used a combination of
> ExcecuteGlobal, wshell.run and wsf files to pass/return parameters and
> call routines. I'm wondering now if I should put all my functions/sub
> into a class or a wsc and just reference this one file in all my wsf
> programs. The class/wsc would have some disparate functions, but it
> seems to suit the purpose. Should I? Which one, class or wsc? Why?
> Are there other options to solve my problems?
>
> If you too have question about passing values I highly recommend
> looking at Torgeir Bakken's post:
>
http://groups.google.com/group/microsoft.public.scripting.wsh/msg/9ebc58d1b5
f5c51f
> He mentions wsc, but not a simpler class. Why?
>
> One of the drivers of my problems is my need to create a cental place
> for storing constants. I reference many network paths and I want a
> central place to be able to easily make changes. My initial solution
> was a text file to hold the constants and a function that uses ado to
> look up the values of named constants. But my architecture of calling
> vbs files from wsf files didn't work well since now my vbs files needed
> to call another vbs function that looked up the constants. You can't
> call wsf files from wsf files.
>
> I've looked at wsc and type libaries, but is this overkill for my need
> to grab some constants?

It looks like Torgeir's option 1 is the alternative to a
WSC. There's no need for a class if you're just reading in
a group of constants. It can just be a simple VBS full
of declarations that gets executed globally.

Also, I don't know whether there are scope issues
with constants read in that way, but variables are
really the same thing. It doesn't matter as long as
you pick some kind of format that identifies them as
your global values rather than as changeable variables.

For instance:

Dim gServer1, gServer2, gServer3...etc.
'-- all global variables prepended by "g"

Or:

Dim SERVER_1, SERVER_2 ... etc.
'-- all global variables formatted with old-style
'-- constant formatting.

I think it's all just a matter of preference. Personally,
if I were going to use constants I think I'd rather just
keep the declarations on the Desktop in a text file and
paste them into each new script. Then they'd be accessible
when I forget one. You're going to have to do that much work,
anyway, by the time you create and call a WSC or
read in and execute globally a .VBS file. (In other words,
you'll have to paste in or type the code for those methods
in each script.) So you may as well just paste your constants
and have them accessible....and that method is also the least
CPU intensive, for what it's worth.