Does DataGridView.Dispose Call DataGridViewRow.Dispose?

  • Thread starter Thread starter eBob.com
  • Start date Start date
E

eBob.com

When I call DataGridView.Dispose does that call Dispose methods for all of
the things, like DataGridViewRow, contained with the DataGridView? Or do I
have to call DataGridViewRow.Dispose for all of the rows and then call
DatGridView.Dispose?

Thanks, Bob
 
When I call DataGridView.Dispose does that call Dispose methods for all of
the things, like DataGridViewRow, contained with the DataGridView?  Or do I
have to call DataGridViewRow.Dispose for all  of the rows and then call
DatGridView.Dispose?

Thanks,  Bob
Click to expand...

Just call Dispose on DataGridView.

In general all you need to do is call Dispose on the root object and
let it determine which of it's members it needs to call Dispose on.
That's how the IDisposable is suppose to work.
 
Have a look at what Tom Shelton wrote about using the dispose method for a
control in this newsgroup.

Cor
 
When I call DataGridView.Dispose does that call Dispose methods for all of
the things, like DataGridViewRow, contained with the DataGridView?  Or do I
have to call DataGridViewRow.Dispose for all  of the rows and then call
DatGridView.Dispose?

Thanks,  Bob
Click to expand...

The simple answer is no, you don't need to dispose the child rows.
DataGridView will take care of that - as it's supposed to. The real
question is do you have a good reason for calling dispose on
DataGridView in the first place? Unless you have special situation,
like dynamically creating the control, and then maybe replacing it
during the lifetime of the form - there probably isn't a reason to
even call dispose on the DataGridView because the containing form will
call it when it is disposed....
 
Hi Tom,

On the one hand, Thanks. And yes I do have a dynamically created
DataGridView which gets replaced.

On the other hand ... I'll have to keep looking for my memory leak!

Thanks again, Bob


When I call DataGridView.Dispose does that call Dispose methods for all of
the things, like DataGridViewRow, contained with the DataGridView? Or do I
have to call DataGridViewRow.Dispose for all of the rows and then call
DatGridView.Dispose?

Thanks, Bob
Click to expand...

The simple answer is no, you don't need to dispose the child rows.
DataGridView will take care of that - as it's supposed to. The real
question is do you have a good reason for calling dispose on
DataGridView in the first place? Unless you have special situation,
like dynamically creating the control, and then maybe replacing it
during the lifetime of the form - there probably isn't a reason to
even call dispose on the DataGridView because the containing form will
call it when it is disposed....
 
Hi Tom,

On the one hand, Thanks. And yes I do have a dynamically created
DataGridView which gets replaced.

On the other hand ... I'll have to keep looking for my memory leak!
Click to expand...

Are you interacting with any legacy com objects/controls?
 
Hi Tom,

Thanks for your interest. No, no legacy com objects/controls. It's really
a simple app. Is there any way that my code could see ALL objects? Then I
could list them all and see which ones are still around which I should have
gotten rid of. GC can find all objects, right? Can my code?

Thanks again, Bob
 
Tom, (or anyone,)

Related to my other posts in this thread and Dispose in general, maybe you
can help me with the following.

I've noticed that in my code I do the following:

somearray(sub) = Nothing ' get rid of any existing thingamajig
somearray(sub) = New thingamajig
somearray(sub).stringvalues = Split(inputbuffer, ...

But I know from some debugging code I have in my app that if I have a
DataGridView, called dgv, that dgv = Nothing does not really free the
storage. I have to do a dgv.Dispose.

So could the code above be causing my memory leak? My thingamajig class is
literally nothing more than two Integers and a String array. (It doesn't
even have an explicit constructor.) My Balena book says that a class only
has to implement a Dispose method if it allocates resources other than
memory. (But then I wonder why DataGridView implements a Dispose method? I
don't see why it would be allocating anything other than memory.)

And if my thingamajig class does need to implement Dispose how do you get
rid of Integers and Strings? I get compiler errors when I try, e.g.,
intvar.Dispose or strvar.Dispose. I can do intvar = Nothing and strvar =
Nothing but my experience with DataGridView is that setting something to
Nothing is not sufficient.

Any amelioration of my confusion in this area would be much appreciated.
(In fact any amelioration of my confusion in general would be appreciated
too. Actually any amelioration would be appreciated!)

Thanks, Bob
 
Tom, (or anyone,)

Related to my other posts in this thread and Dispose in general, maybe you
can help me with the following.

I've noticed that in my code I do the following:

somearray(sub) = Nothing ' get rid of any existing thingamajig
Click to expand...

Completely unnecessary, and likely optimized out of a release compile anyway.
The fact is that the line below, will automatically orphan the reference and
make the old reference ready for garbage collection...

somearray(sub) = New thingamajig
somearray(sub).stringvalues = Split(inputbuffer, ...

But I know from some debugging code I have in my app that if I have a
DataGridView, called dgv, that dgv = Nothing does not really free the
storage. I have to do a dgv.Dispose.
Yep..


So could the code above be causing my memory leak? My thingamajig class is
Click to expand...

Are you sure you have a memory leak? What symptoms do you see? Many people
confuse windows memory management and GC as a memory leak when they are not.

First, GC will usually only run when the system in under some sort of memory
pressure - usually the heap has become fragmented so gc will run to clean up
the unused objects and relocate stuff for more efficient access..

And second, even if the gc does run and actually cleans up the memory -
windows may not reclaim it. Memory allocated to a process will often stay
allocated to the process, for performance reasons. It will be reclaimed if it
is unused and the OS needs the memory.

Another mistake is that people often look at the TaskManager to diagnose these
issues, and that is not the correct place to look. You should look in the
system performance counters and monitor the memory usage there.
literally nothing more than two Integers and a String array. (It doesn't
even have an explicit constructor.) My Balena book says that a class only
has to implement a Dispose method if it allocates resources other than
memory. (But then I wonder why DataGridView implements a Dispose method? I
don't see why it would be allocating anything other than memory.)

And if my thingamajig class does need to implement Dispose how do you get
rid of Integers and Strings? I get compiler errors when I try, e.g.,
intvar.Dispose or strvar.Dispose. I can do intvar = Nothing and strvar =
Nothing but my experience with DataGridView is that setting something to
Nothing is not sufficient.
Click to expand...

Setting something to nothing is in general, completely unnecessary in .NET (in
fact, it was pretty much the same way in VB6 - but, people were confused there
as well). Basically, shared references, module or class level
variables are about the only place that it actually makes sense.
 
Hi Tom,

Helping me out on the weekend is really above and beyond the call of duty.
I'm very appreciative.

The numbers which indicate a memory leak to me are collected by the app
itself (i.e. the app which I suspect has a memory leak).

GC.Collect()
CurrentMemory = GC.GetTotalMemory(True)
- display CurrentMemory, LastMemory, and CurrentMemory-LastMemory
LastMemory = CurrentMemory

Based on the doc I read I thought that GetTotalMemory would be a reliable
number to look at for indications of a memory leak. And it sounded like
Collect would force garbage collection so that the number returned by
GetTotalMemory would be up to date.

The app just displays a file in a customized way. Roughly, the amount of
memory in use should be porportional to the file size and how it is being
displayed (there are various options). Generally memory use goes up when I
think it should and down when I think it should. But telling the app to
display the same small file over and over again, which should result in no
memory growth, results in memory increases of 5544 (on the 2nd display),
then 1392, 1360, 1360. Displaying a larger file over and over again results
in memory increases of 1232 (on the 2nd display), then 1360, then 1312.

It turned out to be a bit more interesting to keep it on the same file and
turn on and off a particular display option. This resulted, as it should
have, in an increase when the option was turned on and a decrease when the
option was turned off. The increases and decreases were as follows:
6168/-5784, 6192/-5808, 6168/-5784, and 6192/-5808. Notice that the decrease
was always less than the increase - always by 384 bytes. Also notice that
the increase/decrease pairs oscilate back and forth between two pairs (of an
increase/decrease)

Well, sorry, I can't expect you to diagnose the problem based on those
numbers. But maybe you can suggest a debugging approach. The only thing I
can think of at this point is to try to bypass certain areas of code and to
see if that helps. The problem of course is that when some areas of code
are bypassed other areas of code can't be expected to execute correctly.

Thanks again for your interest and help - especially on a weekend!

Bob
 
Hi Tom,

Helping me out on the weekend is really above and beyond the call of duty.
I'm very appreciative.

The numbers which indicate a memory leak to me are collected by the app
itself (i.e. the app which I suspect has a memory leak).

GC.Collect()
CurrentMemory = GC.GetTotalMemory(True)
- display CurrentMemory, LastMemory, and CurrentMemory-LastMemory
LastMemory = CurrentMemory

Based on the doc I read I thought that GetTotalMemory would be a reliable
number to look at for indications of a memory leak. And it sounded like
Collect would force garbage collection so that the number returned by
GetTotalMemory would be up to date.

The app just displays a file in a customized way. Roughly, the amount of
memory in use should be porportional to the file size and how it is being
displayed (there are various options). Generally memory use goes up when I
think it should and down when I think it should. But telling the app to
display the same small file over and over again, which should result in no
memory growth, results in memory increases of 5544 (on the 2nd display),
then 1392, 1360, 1360. Displaying a larger file over and over again results
in memory increases of 1232 (on the 2nd display), then 1360, then 1312.

It turned out to be a bit more interesting to keep it on the same file and
turn on and off a particular display option. This resulted, as it should
have, in an increase when the option was turned on and a decrease when the
option was turned off. The increases and decreases were as follows:
6168/-5784, 6192/-5808, 6168/-5784, and 6192/-5808. Notice that the decrease
was always less than the increase - always by 384 bytes. Also notice that
the increase/decrease pairs oscilate back and forth between two pairs (of an
increase/decrease)

Well, sorry, I can't expect you to diagnose the problem based on those
numbers. But maybe you can suggest a debugging approach. The only thing I
can think of at this point is to try to bypass certain areas of code and to
see if that helps. The problem of course is that when some areas of code
are bypassed other areas of code can't be expected to execute correctly.

Thanks again for your interest and help - especially on a weekend!

Bob
Click to expand...

Personally, unless the there are problems with system or app performance
issues associated with it - I probably wouldn't bother to investigate :) But,
one good way to detect memory issues, etc - is to use a profiling tool. One
that I've had good luck with is Ants profiler from Red Gate:

http://www.red-gate.com/products/ants_performance_profiler/index.htm
 
Hi Tom,

Helping me out on the weekend is really above and beyond the call of duty..
I'm very appreciative.

The numbers which indicate a memory leak to me are collected by the app
itself (i.e. the app which I suspect has a memory leak).

GC.Collect()
CurrentMemory = GC.GetTotalMemory(True)
 - display CurrentMemory, LastMemory, and CurrentMemory-LastMemory
LastMemory = CurrentMemory

Based on the doc I read I thought that GetTotalMemory would be a reliable
number to look at for indications of a memory leak.  And it sounded like
Collect would force garbage collection so that the number returned by
GetTotalMemory would be up to date.

The app just displays a file in a customized way.  Roughly, the amount of
memory in use should be porportional to the file size and how it is being
displayed (there are various options).  Generally memory use goes up when I
think it should and down when I think it should.  But telling the app to
display the same small file over and over again, which should result in no
memory growth, results in memory increases of 5544 (on the 2nd display),
then 1392, 1360, 1360.  Displaying a larger file over and over again results
in memory increases of 1232 (on the 2nd display), then 1360, then 1312.

It turned out to be a bit more interesting to keep it on the same file and
turn on and off a  particular display option.  This resulted, as it should
have, in an increase when the option was turned on and a decrease when the
option was turned off.  The increases and decreases were as follows:
6168/-5784, 6192/-5808, 6168/-5784, and 6192/-5808. Notice that the decrease
was always less than the increase - always by 384 bytes.  Also notice that
the increase/decrease pairs oscilate back and forth between two pairs (ofan
increase/decrease)

Well, sorry, I can't expect you to diagnose the problem based on those
numbers.  But maybe you can suggest a debugging approach.  The only thing I
can think of at this point is to try to bypass certain areas of code and to
see if that helps.  The problem of course is that when some areas of code
are bypassed other areas of code can't be expected to execute correctly.

Thanks again for your interest and help - especially on a weekend!

Bob
Click to expand...

Bob, are you seeing these increases consistently after many repeated
executions of the use case (more than just a half dozen). Try it at
least 30,40, or 50 times and see if you're still seeing the
increases. The GC is pretty aggressive in allocating memory from the
OS so it may be that you're seeing large increases at first as the GC
tunes itself that application's memory requirements. Though I will
admit that something does seem unusual.
 
Hi, I face a same problem as you, how I know the memory leak as the OOM
exception thrown.
My case is like that: My app will open a batch child forms from a main
form, there are combocbox and datagridview in the child form, however,
after I closed all those child forms, the memory doesn't reduce to
expect ... :(

What I confuse is, after closed the child form, it did run to dispose,
after form dispose will the memory released from GC heap?
 
Hi, I face a same problem as you, how I know the memory leak as the OOM
exception thrown.
My case is like that: My app will open a batch child forms from a main
form, there are combocbox and datagridview in the child form, however,
after I closed all those child forms, the memory doesn't reduce to
expect ... :(

What I confuse is, after closed the child form, it did run  to dispose,
after form dispose will the memory released from GC heap?
Click to expand...

Not necessarily. Dispose only releases unmanaged resources. Could it
be possible that you still have references to these objects somewhere
in code?
 
Back
Top