Thanks all, I guess it's just safer to dereference the objects... I've
created.

Well it certainly doesn't hurt.

--
HTH

Bob Phillips

(remove nothere from email address if mailing direct)

"vmegha" wrote in message
oups.com...
Thanks all, I guess it's just safer to dereference the objects... I've
created.

Well it certainly doesn't hurt.

Contradicting your own post?

Setting them to Nothing
yourself is a waste of code: VB has to check if they are Nothing anyway and
always generates the code the code to release them, so you're just
duplicating existing code.

Also, unneeded teardown code
obscures necessary teardown code buy burying it in a bunch of noise, which
makes it harder to maintain the real teardown code.

As to Remy's comment, has he ever written a strictly Excel internal vba
procedure that won't let Excel close because an object reference is
retained. I grant that his comment is correct for C++, but in VBA, VBA
handles that for the coder. If referencing automation, then the problem
with automation is not with Set statements, but with the creation of
implicit references that can not be released.

--
Regards,
Tom Ogilvy




"Bob Phillips" wrote in message
...


--
HTH

Bob Phillips

(remove nothere from email address if mailing direct)

"vmegha" wrote in message
oups.com...
Thanks all, I guess it's just safer to dereference the objects... I've
created.

Life and learn...
But yeah, too much C++ background. Glad C# is here :-)