Re: Looking for "Terminate Event" in Windows Script Components???

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

From: Al Dunbar [MS-MVP] (alan-no-drub-spam_at_hotmail.com)
Date: 02/05/05 

Date: Fri, 4 Feb 2005 23:20:57 -0700

"Gerry Hickman" <gerry666uk@yahoo.co.uk> wrote in message
news:uU5KodxCFHA.2960@TK2MSFTNGP14.phx.gbl...
> Hi Al,
>
> >>Package for re-use?
> >
> > I think he wants to write code in such a way that he can easily re-use
it in
> > different projects, and that he considers WSC components and "classes"
as
> > alternate mechanisms the way to "package" the script.
>
> Thanks, but let's say we're using the "class" model;

By "the class model" can I assume that you are referring to vbscript classes
generated by the class statement?

> how exactly would
> this work? Would the classes reside in a WSF file,

Some of them might indeed be contained within a <script> block in a .wsf
file.

> and how would the
> "packaged" script be called?

Well, the class wouldn't be called (it's not a subroutine), but used to
instantiate objects based on the class (somehow I think you know of these
basics). The "packaged" (the OP's term) script (i.e. the .wsf file) would be
called (invoked, run) in the usual manner.

> Or would it be in a VBS file?

Some of them might indeed be contained within a .vbs file.

> I'm trying to
> think in terms of how command line parameters would be passed and
> validated to these packages...

By the usual methods.

> Are we talking calling with WScript.Run()
> or something a bit more elaborate? I'm assuming these packages are
> called from "other" scripts, or are they simply called from the CMD line?

I think you might be confusing the OP's terminology and use of the word
"packaged" with the <package> element of either a .wsf file or a .wsc file.
As noted in a recent thread, the concept of multiple jobs in a .wsf is now
seen, even by the developer, as either a poorly thought out concept, or a
poorly executed one.

My guess is that the OP is simply looking for some methodology on which to
base scripts using multiple files.

> It would appear the script component WSC has to be registered (?),

No, there is a way to instantiate a component from an unregistered .wsc file
simply by giving its path in a particular format - sorry, but I forget the
details.

The advantage of registering a WSC is that referencing scripts need not know
the name or location of the actual code. The name and location of an updated
copy could even be different without having to modify the referencing
scripts in any way. The disadvantage of using an unregistered WSC is that
referencing scripts need to know the name or location of the actual code. If
you are managing either a large-ish project or a series of somewhat related
ones sharing some common code, the further advantage of registering is that
it provides a standard installation requirement, so you don't need to roll
your own.

Of course, the disadvantage of registering is having to register. The
advantage of using an unregistered WSC is that scripts can be run on systems
without having to ensure they have received the expected WSC installations.

> and
> I'd consider this a major downside in comparison to using shared code
> (which are merely text files that can run on any system). It would also
> mean somewhat non-standard ProgIDs, CLSIDs being required in the calling
> script.

Non-standard because they are not provided by the system, standard because
you would be providing them according to some company standard.

> I don't think I'd use this for SysAdmin scripting, but it looks
> ideal for web server scripting where you can easily keep track of all
> installed objects and also put them back when you re-build the server.

Actually, it is good for SysAdmin scripting. Although I lean more towards
classes subs and functions in .vbs files statically included by a series of
separate .wsf scripts, the advantages I noted above are appealing.

> >>How exactly would this work in real life, how would you call it, what
> >>kind of thing would happen in the WSC, that would cause it to terminate,
> >>and what would you do in the caller when it did?
> >
> >
> > A terminate event is not called by the script, but fired automatically
when
> > an object instantiated out of a vbscript class is de-instantiated.
>
> When I said "how would you call it" above, I was meaning "how would you
> call the packaged script", not "how would you call the terminate event".

Sorry, my mistake.

> Regarding the event itself, I'm far from convinced this will correctly
> clean up memory allocated by crashed API calls from within a WSC.

A good point to which I have no answer.

/Al

Relevant Pages

  • Re: Loops in COM
    ... Yes I'm using it as a WSC, ... object wscript and using wscript.sleep but that did not work. ... > or IE or MSHTA hosted scripts, then you're more or less out of luck. ...
    (microsoft.public.scripting.wsh)
  • Re: Loops in COM
    ... Yes I'm using it as a WSC, ... object wscript and using wscript.sleep but that did not work. ... > or IE or MSHTA hosted scripts, then you're more or less out of luck. ...
    (microsoft.public.scripting.vbscript)
  • Re: Setting new date with offset in days
    ... or .vbs or .wbs scripts. ... You mean .wsf instead? ... Usual file extensions: .vbs, .asp ... VBScript .vbs files can be included in two other types of scripting files: ...
    (comp.lang.javascript)
  • Re: debugging .wsf files for use under WSH
    ... > SRC element to include .vbs files with library code in them, and wsf files ... editor, it has the desired features like highlighting and intellisense. ... Most of my scripts run under wscript, so if I forget to remove the debugging ...
    (microsoft.public.scripting.wsh)
  • Re: call vbs from within vbs
    ... number of related administrative scripts. ... Our scripts are in .wsf format. ... > Exit Sub ... > Call LoadGroups(objPriobject, objGroup) ...
    (microsoft.public.scripting.vbscript)