Hi all.

I'm a recent migrant from VB6 so I'm used to creating references to
objects and then setting them to Nothing when they are no longer
needed.

Do I understand correctly that setting to Nothing is unnecessary in VB
2008 when the owning class or form is about to close anyway?

Can disposal of objects always be left to the garbage collector, or
are there times when setting to Nothing would be useful or desirable?

Second, though related, question: when showing a form, using
..ShowDialog, I always call the form's .Dispose method on return.
Should I set the form to Nothing as well? Everything seems to work
whether I set to Nothing or not, but I can't tell whether resources
are being retained unnecessarily.

Thanks for any guidance.

Gale.

On 2010-04-04, Gale Green <(E-Mail Removed)> wrote:
>
> Hi all.
>
> I'm a recent migrant from VB6 so I'm used to creating references to
> objects and then setting them to Nothing when they are no longer
> needed.
>
> Do I understand correctly that setting to Nothing is unnecessary in VB
> 2008 when the owning class or form is about to close anyway?
>
> Can disposal of objects always be left to the garbage collector, or
> are there times when setting to Nothing would be useful or desirable?
>
> Second, though related, question: when showing a form, using
> .ShowDialog, I always call the form's .Dispose method on return.
> Should I set the form to Nothing as well? Everything seems to work
> whether I set to Nothing or not, but I can't tell whether resources
> are being retained unnecessarily.
>
> Thanks for any guidance.
>
> Gale.

Setting an local object to nothing is almost always useless - just as it was
in VB6 (except in very rare circumstances). About the only time setting an
object to nothing is valuable is when it is a module or class level reference.

The only time special handling is required is when an object implements the
IDisposable interface. This is generally an indication that the object holds
some resource (most often unmanaged) that needs cleanup. In those cases you
will generally want to make sure that Dispose is called on the object when you
are through with it. The easiest way to do this is to use Using...

Using d As New MyDialog()
If d.ShowDialog() = DialogResult.OK Then
' do cool stuff
End If
End Using

The value of using is that it will ensure that Dispose is called on the
object, even if an exception is thrown. It is bascially syntactic sugar for a
Try/Finally block.

There are objects that implement IDisposable that calling Dispose is not
strictly necessary - such as DataSet. These objects actually end up with
Dispose because they inherit from component. You may see advice from some
that says to avoid calling dispose on these objects. I personally disagree
with this advice for a number of reasons and suggest that you make it a strict
rule to always call dispose if an object implments IDisposable.

The reasons I disagree is because:

1) It makes the rules for Dispose more complicated - always call dispose
except on object a, b, c, d. It's easier to remember, if an object implements
IDisposable call dispose.

2) In OOP it is generally a bad idea to program to an objects implementation.
As a rule, it is better to program to an Interface - and ignoring dispose on
certain objects means you are programming against a known implementation
details. This can leave your code broken if a future implementation
changes...

But, feel free to follow what ever rule you are most comfortable with...

--
Tom Shelton

On Sun, 04 Apr 2010 10:20:33 -0700, Tom Shelton
<(E-Mail Removed)> wrote:

> Good stuff.

Thanks for all that Tom. All is now clear, and I agree with your
attitude to the Dispose method.

Gale.

However, in fact Tom does not call the Dispose method in 90% of the cases,
because he knows that those are implicitly called.


"Gale Green" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> On Sun, 04 Apr 2010 10:20:33 -0700, Tom Shelton
> <(E-Mail Removed)> wrote:
>
>> Good stuff.
>
> Thanks for all that Tom. All is now clear, and I agree with your
> attitude to the Dispose method.
>
> Gale.

On 2010-04-05, Cor Ligthert[MVP] <(E-Mail Removed)> wrote:
> However, in fact Tom does not call the Dispose method in 90% of the cases,
> because he knows that those are implicitly called.
>
>

Cor... It is true that I do not often call the Dispose method directly -
I generally enclose disposable objects in a using block, which guarentees the
call to dispose. The point that I was makeing is that I generally code to
make sure that the object is disposed when I am done with it. I in fact,
pointed this out in my post to the OP - the use of using. I am suggesting
that the OP does likewise. Making sure a dispose call is made, implicitly via
using, or explicitly amounts to about the same thing in my book.

I wonder, did you have some valid point to make?

--
Tom Shelton

Yes I've a point, don't tell Wabash, it seems just to create a Trolling
thread, this is not the VB6 newsgroup.

You wrote
> There are objects that implement IDisposable that calling Dispose is not
> strictly necessary - such as DataSet. These objects actually end up with
> Dispose because they inherit from component. You may see advice from some
> that says to avoid calling dispose on these objects. I personally
> disagree
> with this advice for a number of reasons and suggest that you make it a
> strict
> rule to always call dispose if an object implments IDisposable.

What you wrote, is the same reason why the OP was setting anything to
Nothing in VB6, somebody had written that and he took the chance that that
one was right as the best. Now you tell him that he should change that
practice to use on everything which implements Idisposable the "often"
senseless dispose method, which only trashes often code in the same way as
for ever using nothing in VB6.

Form Closing
label1.dispose
Label2.dispose
Label3.dispose

Why don't you write that he should always count like this.

Result = Cint(X.ToString) += 1 because every value type implements even an
overloaded ToString method, so in your theory it must be used.

All Forms controls and components implement the dispose method inherited
from the Component class.

You know likewise me that where calling the dispose is needed, this for
forms and components is done implicit but since version 2005 hidden for most
beginners in VB.Net in the designer part.

You know also very well, that I am almost the only one who shows in the
Microsoft Visual Basic forums samples with "using", so don't accuse me from
things, which you know that aint true.

You know how some regulars in this newsgroup disagree about this with you,
while other of those agree, no problem but don't see it as a kind of
evangelism to newbie's, who have set in past everything to nothing, just to
take no risk and somebody wrote it.

With every object which implements IDisposable, can be used with Using, so
calling Dispose has no sense anymore, use the better code for that, it
trashes at least not the code like I showed above.

So where Dispose is needed it is better to use the Using keyword and if you
don't know, you can also use that using keyword.

Luckily the newer Classes don't implement IDisposale anymore so much anymore
as in past.

Your message could have also been without that sentence I quoted, it would
have been a good and correct message.

Now it seems at least to me more a little bit to kick some regulars here to
the head.

Cor



"Tom Shelton" <(E-Mail Removed)> wrote in message
news:#(E-Mail Removed)...
> On 2010-04-05, Cor Ligthert[MVP] <(E-Mail Removed)> wrote:
>> However, in fact Tom does not call the Dispose method in 90% of the
>> cases,
>> because he knows that those are implicitly called.
>>
>>
>
> Cor... It is true that I do not often call the Dispose method directly -
> I generally enclose disposable objects in a using block, which guarentees
> the
> call to dispose. The point that I was makeing is that I generally code to
> make sure that the object is disposed when I am done with it. I in fact,
> pointed this out in my post to the OP - the use of using. I am suggesting
> that the OP does likewise. Making sure a dispose call is made, implicitly
> via
> using, or explicitly amounts to about the same thing in my book.
>
> I wonder, did you have some valid point to make?
>
> --
> Tom Shelton

Hmmm ,,,.........

to the OP

This is discussed here manny times and it mostly indeed ends in a nothing
saying thread

http://www.developersdex.com/vb/mess...1121&r=6705983
http://bytes.com/topic/visual-basic-...ommand-dispose
http://www.pcreview.co.uk/forums/thread-3854824-3.php
etc etc etc etc etc etc

http://www.google.nl/#hl=nl&source=h...c54ad77a0995ae

Read a few of them and try some of the examples i showed in these threads
and you will notice that your program in some of my described situations can
run forever
while if you follow the Not call dispose camp in the same situation your
progs will crash or degrade overall system performance .

In case you are wondering ,, yes i am in the call dispose and set to nothing
camp when it actually makes sense to do so , and if you are in doubt just do
it, as it also doesn`t hurt while omitting it wil sure hurt your app.

As i am a so called "Balena" programmer i follow his design patterns ( wich
actually conform to MS standards as he is also the writer of the MS VB core
reference guides ) described in the Core reference guides of Visual Basic
..Net and in these guide there are examples where a object pointer is set
to nothing and it perfectly makes sence to do so , i have posted this
example several times in the group so with the provided links you should
find it :-) .

Regards

Michel Posseth




"Cor Ligthert[MVP]" <(E-Mail Removed)> schreef in bericht
news:(E-Mail Removed)...
> Yes I've a point, don't tell Wabash, it seems just to create a Trolling
> thread, this is not the VB6 newsgroup.
>
> You wrote
> > There are objects that implement IDisposable that calling Dispose is not
>> strictly necessary - such as DataSet. These objects actually end up with
>> Dispose because they inherit from component. You may see advice from
>> some
>> that says to avoid calling dispose on these objects. I personally
>> disagree
>> with this advice for a number of reasons and suggest that you make it a
>> strict
>> rule to always call dispose if an object implments IDisposable.
>
> What you wrote, is the same reason why the OP was setting anything to
> Nothing in VB6, somebody had written that and he took the chance that that
> one was right as the best. Now you tell him that he should change that
> practice to use on everything which implements Idisposable the "often"
> senseless dispose method, which only trashes often code in the same way as
> for ever using nothing in VB6.
>
> Form Closing
> label1.dispose
> Label2.dispose
> Label3.dispose
>
> Why don't you write that he should always count like this.
>
> Result = Cint(X.ToString) += 1 because every value type implements even an
> overloaded ToString method, so in your theory it must be used.
>
> All Forms controls and components implement the dispose method inherited
> from the Component class.
>
> You know likewise me that where calling the dispose is needed, this for
> forms and components is done implicit but since version 2005 hidden for
> most beginners in VB.Net in the designer part.
>
> You know also very well, that I am almost the only one who shows in the
> Microsoft Visual Basic forums samples with "using", so don't accuse me
> from things, which you know that aint true.
>
> You know how some regulars in this newsgroup disagree about this with you,
> while other of those agree, no problem but don't see it as a kind of
> evangelism to newbie's, who have set in past everything to nothing, just
> to take no risk and somebody wrote it.
>
> With every object which implements IDisposable, can be used with Using,
> so calling Dispose has no sense anymore, use the better code for that, it
> trashes at least not the code like I showed above.
>
> So where Dispose is needed it is better to use the Using keyword and if
> you don't know, you can also use that using keyword.
>
> Luckily the newer Classes don't implement IDisposale anymore so much
> anymore as in past.
>
> Your message could have also been without that sentence I quoted, it would
> have been a good and correct message.
>
> Now it seems at least to me more a little bit to kick some regulars here
> to the head.
>
> Cor
>
>
>
> "Tom Shelton" <(E-Mail Removed)> wrote in message
> news:#(E-Mail Removed)...
>> On 2010-04-05, Cor Ligthert[MVP] <(E-Mail Removed)> wrote:
>>> However, in fact Tom does not call the Dispose method in 90% of the
>>> cases,
>>> because he knows that those are implicitly called.
>>>
>>>
>>
>> Cor... It is true that I do not often call the Dispose method directly -
>> I generally enclose disposable objects in a using block, which guarentees
>> the
>> call to dispose. The point that I was makeing is that I generally code
>> to
>> make sure that the object is disposed when I am done with it. I in fact,
>> pointed this out in my post to the OP - the use of using. I am
>> suggesting
>> that the OP does likewise. Making sure a dispose call is made,
>> implicitly via
>> using, or explicitly amounts to about the same thing in my book.
>>
>> I wonder, did you have some valid point to make?
>>
>> --
>> Tom Shelton
>

On 2010-04-05, Cor Ligthert[MVP] <(E-Mail Removed)> wrote:
> Yes I've a point, don't tell Wabash, it seems just to create a Trolling
> thread, this is not the VB6 newsgroup.
>
> You wrote
> > There are objects that implement IDisposable that calling Dispose is not
>> strictly necessary - such as DataSet. These objects actually end up with
>> Dispose because they inherit from component. You may see advice from some
>> that says to avoid calling dispose on these objects. I personally
>> disagree
>> with this advice for a number of reasons and suggest that you make it a
>> strict
>> rule to always call dispose if an object implments IDisposable.
>
> What you wrote, is the same reason why the OP was setting anything to
> Nothing in VB6, somebody had written that and he took the chance that that
> one was right as the best. Now you tell him that he should change that
> practice to use on everything which implements Idisposable the "often"
> senseless dispose method, which only trashes often code in the same way as
> for ever using nothing in VB6.
>

And as always, we disagree on this point (and despite your inferences, you are
almost the only one I know who does). I see you once again bring in a
long set of unrelated arguments. I will ignore the rest of your post, and
just try to make sure my position is clear.

Integer.ToString(): Totally irelavent. I am in no way saying that every
method of an object must be called simply because it exits.

IDisposable is part of a resource management pattern. The presence of
IDisposable is supposed to signal to the developer using the object that this
class potentially contains resources that should be released as early as
possible. As such, it should be called when you are done with the object.

Now, I treat controls and components that are sited on forms a bit
differently, because the system generates the code to dispose of these. In
other words, the parent forms dispose method disposes all of it's children.
So, using a dialog:

Using dlg As New MyDlg
If dlg.ShowDialog() = DialogResult.OK Then
...
End If
End Using

Is sufficent to dispose the form and all of it's children. So, with the
exception of the main form - since that object lives the entire life of the
program, it's a pretty safe bet that I am making sure a call to dispose is
made.

Other objects, that maybe used as local values, ect that implement Dispose are
almost always wrapped in a using block - so I very rarely call Dispose
directly. And yes, I do advocate the use of a using with classes such as
dataset, memorystream, etc. The main reason is that I like to keep rules
simple and consistant. And, I don't believe in programming to an object's
implementation. Just because I've looked, and I know a memorystream holds no
unmanaged resources - it's simply wrapper for a byte array, I still wrap it in
a using block. Why? Because I try to program to interfaces and not
implementations. It implements IDisposable, that is an interface with a
special meaning - so I follow the contract.

--
Tom Shelton

<Snipped quote from Tom>
> And as always, we disagree on this point (and despite your inferences, you
> are
> almost the only one I know who does). I see you once again bring in a
> long set of unrelated arguments. I will ignore the rest of your post, and
> just try to make sure my position is clear.
>
There is a guy here already a while active with the name Armin Zingler,

It is of course possible you've never seen any post from him.

He has in this no other opinion than me.

Another guy, Herfried Wagner. Ever seen a post from him?
The same.

In past; somebody who changed his opinion and then told the same like me,
Jay B. Harlow.

A pity that you've never seen any post from them about dispose.

If you had read my last post in this thread, you would have seen, that I am
not discussing the use of using.
I assume that I am making more propaganda (at least in quantity) for that
then you.
However, in my idea is therefore the use of the dispose method a proof of
non well formed code.

Cor

Am 05.04.2010 19:18, schrieb Cor Ligthert[MVP]:
>>
> There is a guy here already a while active with the name Armin Zingler,

I'm not really getting your point mentioning my name, but I was about to
reply to Tom's message and say that I 100% agree with him.

Despite, let's stay friends.

--
Armin