Joe
Wed Sep 17 09:49:59 CDT 2003
Hi,
"Ben Blackmore" <bjblackmore@nospam.hotmail.com> wrote in message
news:3f68325b$0$257$cc9e4d1f@news.dial.pipex.com...
| OK thanks, I'll change my script!
| Strange that this windows2000 scripting book got it wrong though! You'd
have
| thought they would test it first
| Cheers
| Ben
|
| "Nick HK" <hkf1@netvigator.com> wrote in message
| news:bk9ahs$ras1@imsp212.netvigator.com...
| > Ben,
| > oNetwork and sPrintPath are objects, so they should be set to Nothing.
| >
| > NickHK
| >
| >
| > "Ben Blackmore" <bjblackmore@nospam.hotmail.com> wrote in message
| > news:3f682c06$0$251$cc9e4d1f@news.dial.pipex.com...
| > | Hi,
| > |
| > | I'm programming a logon script to map to a printer, I got this script
| out
| > of
| > | a windows 2000 scripting book so it should work. However I receive: -
| > Error:
| > | Object required: 'vbEmpty' Code: 800A01A8.
| > | The book just says that its releasing the memory required for those
| > | variables.
| > |
| > | Option Explicit
| > | Dim oNetwork, sPrintPath
| > | Set oNetwork = CreateObject("WScript.Network")
| > | sPrintPath = "\\PRINTSERVER-2K\ORG_FS-7000"
| > | oNetwork.AddWindowsPrinterConnection sPrintPath
| > | oNetwork.SetDefaultPrinter sPrintPath
| > | Set oNetwork = vbEmpty
| > | Set sPrintPath = vbEmpty
| > |
| > | Anyone see anything wrong?
| > |
| > | Cheers
| > |
| > | Ben
As Nick stated, if you use the "set" format, you need to set the variables
to Nothing. This preserves the object structure in the variable list, but
destroys the connection to the object. You can achieve a release as well,
by resetting the object variable to an empty subtype. This destroys the
object structure associated with the variable in the variable list, which
releases the connection in the process. Your "book", however, got it wrong
there, too. The intrinsic constant vbEmpty is simply the integer value 0,
and is designed for use with the VarType function, not for setting to an
empty subtype. The syntax that you're after is one of the following:
set objVar= nothing
objVar= empty
Here's some cumulated info that I maintain on object instances:
When a typical COM class object is "accessed" by the creation of an
"instance" of the object, a pointer to the IDispatch interface and a new
virtual "object" (an interface definition of parameters with assigned
memory) are created. Memory is allocated in which the new object's members
may store data. For the typical COM class object, a new pointer and virtual
object are created for each instance of the underlying object accessed. If
the COM class object is a "singleton" object, only a single instance will be
created, which will be shared not only by all object variable instances in
the same script, but by all scripts or other processes accessing the object.
...
When all object access references are fully terminated, VBS runs a cleanup
process that deletes the pointers and begins the process of eliminating the
interface and memory-allocation. An object will be disconnected only after
all references to it have been released, and Windows may retain certain
references, depending on the object type and how it was instantiated. It is
possible, for example, to lock an object, when employing multiple object
references. Care must be taken with techniques and object types that allow
the object instance to continue beyond its scope in the script or even
beyond the termination of the script. A review of posts relating to
concerns with continued object connections and memory leaks seems to
indicate a number of reasonably distinct situations, including, among
others: (1) failure to properly exit a with statement by progressing
through the end with statement, (2) multiple or duplicate object references
where object variables in higher levels of scope are not released, or (3)
recursive procedures that create multiple copies of an object. The most
pernicious "memory leaks" appear to involve EXE or special DLL objects, that
are essentially applications that, once initiated, continue independently,
despite being released from the object connections to the script. With
these, it is always best to try to force them to shut down through internal
means, usually a Quit method, before terminating the object reference.
The VBS process releasing the object references is part of the cleanup
procedures involved anytime that an object reference goes out of scope. For
purposes of an object variable as a reference to an existing object
instance, the going-out-of-scope cleanup is initiated for the existing
object reference whenever: (1) the variable is reset to nothing or to a
different object reference, or even to a subsequent instance of the same
object reference; (2) the variable is reset to empty or to a non-object
subtype and/or value; (3) the script is terminated; (4) a procedure in which
the object instance has been assigned to a local variable is exited; (5)
either the intrinsic createobject or getobject function is used directly for
a transitory instance of the object, instead of assigning it to a variable;
or (6) either the intrinsic createobject or getobject function is used
directly in a with statement for a block-limited instance of the object, but
only when the with block is properly exited. Setting unused object
variables to nothing is the "preferred" cross-platform coding practice, and
it is useful to release system resources more quickly when the object
instance will not otherwise promptly go out of scope. Setting unused object
variables to nothing, however, ultimately accomplishes nothing more in VBS
than does any other method of going out of scope.
When passing object instances to multiple scripts and/or multiple hosts, the
object instance will go out of scope whenever the originating script or host
is closed.
Credit posts by Michael Harris (MVP), Chris Barber and Alexander Mueller.
Joe Earnest
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (
http://www.grisoft.com).
Version: 6.0.512 / Virus Database: 309 - Release Date: 08-19-03