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

On Jul 24, 10:40*am, "eBob.com" <eBob....@totallybogus.com> wrote:
> 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

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

"eBob.com" <(E-Mail Removed)> wrote in message
news:%(E-Mail Removed)...
> 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

On Jul 24, 9:40*am, "eBob.com" <eBob....@totallybogus.com> wrote:
> 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

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....


--
Tom Shelton

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


"Tom Shelton" <(E-Mail Removed)> wrote in message
news:bf36c923-6f71-4ee4-a4f4-(E-Mail Removed)...
On Jul 24, 9:40 am, "eBob.com" <eBob....@totallybogus.com> wrote:
> 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

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....


--
Tom Shelton

On 2009-07-24, eBob.com <(E-Mail Removed)> wrote:
> 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!
>

Are you interacting with any legacy com objects/controls?

--
Tom Shelton

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 Shelton" <(E-Mail Removed)> wrote in message
news:%(E-Mail Removed)...
> On 2009-07-24, eBob.com <(E-Mail Removed)> wrote:
>> 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!
>>
>
> Are you interacting with any legacy com objects/controls?
>
> --
> Tom Shelton

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

On 2009-07-25, eBob.com <(E-Mail Removed)> wrote:
>
> 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

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

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.
>

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.

--
Tom Shelton

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

"Tom Shelton" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> On 2009-07-25, eBob.com <(E-Mail Removed)> wrote:
>>
>> 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
>
> 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
>
> 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.
>>
>
> 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.
>
> --
> Tom Shelton