Forms and Memory management question

[rforman1]

Suppose I do this: let's say that in my vb.net app's main/MDI form, I
declare a form-level variable of type Form1, where Form1 is another
form (more technically, I know, another class which itself is inherited
from system.windows.forms.form) defined in my application.

dim mfrmForm1 as Form1

Okay, now let's also say I put two menu items on my MDI form, and code
them something like this

(under MenuItem1's click event)

mfrmForm1 = new form1
mfrmForm1.MDIParent = me
mfrmForm1.show

....okay so far; now let's say at run-time, the user clicks this first
menu item, thereby generating and showing an instance of Form1. (Let's
also assume there's no code behind Form1 except for that generated by
the designer.) Let's further say that the user then closes this first
instance of Form1 using the control-box "X" at its upper right hand
corner. Finally, let's say the user then selects the second menu item
on the MDI parent form, under which, let's say!, we have this code:
(same as the other menu item)

(under MenuItem2's click event:)

mfrmForm1 = new form1
mfrmForm1.MDIParent = me
mfrmForm1.Show

....thereby creating a second instance of Form1. Now, the original,
first instance of Form1 never had its .Close or .Dispose method
explicitly called in code, nor was it set to Nothing anywhere. So
(here's my main question) does it still leave some kind of memory
footprint? Maybe the first Form1 object still exists in some sense
even though it was closed....it is still in scope, because it's
declared as a module-level variable inside the MDI form, so I imagine
the garbage collector not recognize it? (If the instance of Form1 was
declared locally within a procedure, then my guess would be that things
would be different: it would go out of scope, and the GC would get rid
of it for me before too long, whether or not I disposed of it or set it
to Nothing in code.) Could something like this cause a performance
deterioration or memory leak eventually? Could/should/would the
situation be improved by adding this event in the MDI form's code
window:

Private Sub mfrmForm1_Closed(ByVal sender As Object, ByVal e As
System.EventArgs) Handles mfrmForm1.Closed
mfrmForm1.Dispose()
mfrmForm1 = Nothing
End Sub

would this make a difference; is it an improvement,
memory-management-wise?

Thanks very much for reading,

richforman

[Chris Dunaway]

> (under MenuItem1's click event)

mfrmForm1 = new form1
mfrmForm1.MDIParent = me
mfrmForm1.show

the designer.) Let's further say that the user then closes this first
instance of Form1 using the control-box "X" at its upper right hand
When a form is shown by calling the Show method, it is automatically
disposed when it is closed.
(under MenuItem2's click event:)

mfrmForm1 = new form1
mfrmForm1.MDIParent = me
mfrmForm1.Show

...thereby creating a second instance of Form1. Now, the original,
first instance of Form1 never had its .Close or .Dispose method
The mfrmForm1 variable now points at the *new* form instance. Since
nothing points to the first instance anymore, it is eligible for GC.
(here's my main question) does it still leave some kind of memory
footprint? Maybe the first Form1 object still exists in some sense
even though it was closed....it is still in scope, because it's

It does exist, but it has been disposed and is eligible for GC now.

[Chris]

Chris Dunaway wrote:

(under MenuItem1's click event)

mfrmForm1 = new form1
mfrmForm1.MDIParent = me
mfrmForm1.show

the designer.) Let's further say that the user then closes this first
instance of Form1 using the control-box "X" at its upper right hand

When a form is shown by calling the Show method, it is automatically
disposed when it is closed.

(under MenuItem2's click event:)

mfrmForm1 = new form1
mfrmForm1.MDIParent = me
mfrmForm1.Show

...thereby creating a second instance of Form1. Now, the original,
first instance of Form1 never had its .Close or .Dispose method

The mfrmForm1 variable now points at the *new* form instance. Since
nothing points to the first instance anymore, it is eligible for GC.

(here's my main question) does it still leave some kind of memory
footprint? Maybe the first Form1 object still exists in some sense
even though it was closed....it is still in scope, because it's

It does exist, but it has been disposed and is eligible for GC now.

"When a form is shown by calling the Show method, it is automatically
disposed when it is closed."

Is that true? It thought it was only disposed of when their were no
more pointers to the form. If what you were saying were true then I
couldn't do something like:

class XYZ
dim f as form1

sub buttonclick(..) handles button.click
f.show
end sub

end class

click button once, close the form and then click the button again.

Chris

[rforman1]

Thanks so much to both you guys for your responses, let me keep the
discussion going with another question or two:

Chris Dunaway wrote:

(under MenuItem1's click event)

mfrmForm1 = new form1
mfrmForm1.MDIParent = me
mfrmForm1.show

the designer.) Let's further say that the user then closes this first
instance of Form1 using the control-box "X" at its upper right hand

When a form is shown by calling the Show method, it is automatically
disposed when it is closed.

Now, I didn't know this, and to tell you the truth, from my testing,
I'm not really convinced that this is correct. It might be, but I
think it's not the essential point for what I'm trying to find out, so
let me ask about the next point for my own understanding:

(under MenuItem2's click event:)

mfrmForm1 = new form1
mfrmForm1.MDIParent = me
mfrmForm1.Show

...thereby creating a second instance of Form1. Now, the original,
first instance of Form1 never had its .Close or .Dispose method

The mfrmForm1 variable now points at the *new* form instance. Since
nothing points to the first instance anymore, it is eligible for GC.

This is what I really wanted to know, so let me reiterate this and
verify that we're all in agreement on this. I suspected this but
wasn't sure....and this is what you say here, so I just want to make
sure it's true (so I can report back to my boss about this
issue!)....if the object is no longer pointed to by any variable, then
it is will be GC'd, even though if it still "exists"?

If this is the case, then I have to keep looking for the cause of the
performance reduction some users of my app (but not all) are
experiencing over time.

richforman

[Chris]

rf******@optonline.net wrote:

Thanks so much to both you guys for your responses, let me keep the
discussion going with another question or two:

Chris Dunaway wrote:

(under MenuItem1's click event)

mfrmForm1 = new form1
mfrmForm1.MDIParent = me
mfrmForm1.show

the designer.) Let's further say that the user then closes this first
instance of Form1 using the control-box "X" at its upper right hand

When a form is shown by calling the Show method, it is automatically
disposed when it is closed.

Now, I didn't know this, and to tell you the truth, from my testing,
I'm not really convinced that this is correct. It might be, but I
think it's not the essential point for what I'm trying to find out, so
let me ask about the next point for my own understanding:

(under MenuItem2's click event:)

mfrmForm1 = new form1
mfrmForm1.MDIParent = me
mfrmForm1.Show

...thereby creating a second instance of Form1. Now, the original,
first instance of Form1 never had its .Close or .Dispose method

The mfrmForm1 variable now points at the *new* form instance. Since
nothing points to the first instance anymore, it is eligible for GC.

This is what I really wanted to know, so let me reiterate this and
verify that we're all in agreement on this. I suspected this but
wasn't sure....and this is what you say here, so I just want to make
sure it's true (so I can report back to my boss about this
issue!)....if the object is no longer pointed to by any variable, then
it is will be GC'd, even though if it still "exists"?

If this is the case, then I have to keep looking for the cause of the
performance reduction some users of my app (but not all) are
experiencing over time.

richforman

Yes, if nothing has a reference to it, then it will be GC'd whenever the
GC gets around to it... It won't happen right away. There are memory
monitors around for .Net that should help you. You can't rely on
taskmanager for an accurate monitor.

Chris

[ng]

There's a really good way to avoid the possibility of this thing lingering:
Declare in the menu click event your form variable as new form1. While
the form will be usable, the variable is already out of scope, because
we have already exited the menu click event. When the form is closed,
no matter how, there is nothing referencing it anymore. The GC won't be
relied upon so heavily.

Tom
Chris wrote:

rf******@optonline.net wrote:

Thanks so much to both you guys for your responses, let me keep the
discussion going with another question or two:

Chris Dunaway wrote:

(under MenuItem1's click event)

mfrmForm1 = new form1
mfrmForm1.MDIParent = me
mfrmForm1.show

the designer.) Let's further say that the user then closes this first
instance of Form1 using the control-box "X" at its upper right hand
When a form is shown by calling the Show method, it is automatically
disposed when it is closed.

Now, I didn't know this, and to tell you the truth, from my testing,
I'm not really convinced that this is correct. It might be, but I
think it's not the essential point for what I'm trying to find out, so
let me ask about the next point for my own understanding:

(under MenuItem2's click event:)

mfrmForm1 = new form1
mfrmForm1.MDIParent = me
mfrmForm1.Show

...thereby creating a second instance of Form1. Now, the original,
first instance of Form1 never had its .Close or .Dispose method
The mfrmForm1 variable now points at the *new* form instance. Since
nothing points to the first instance anymore, it is eligible for GC.

This is what I really wanted to know, so let me reiterate this and
verify that we're all in agreement on this. I suspected this but
wasn't sure....and this is what you say here, so I just want to make
sure it's true (so I can report back to my boss about this
issue!)....if the object is no longer pointed to by any variable, then
it is will be GC'd, even though if it still "exists"?

If this is the case, then I have to keep looking for the cause of the
performance reduction some users of my app (but not all) are
experiencing over time.

richforman

Yes, if nothing has a reference to it, then it will be GC'd whenever
the GC gets around to it... It won't happen right away. There are
memory monitors around for .Net that should help you. You can't rely
on taskmanager for an accurate monitor.

Chris

[Chris Dunaway]

Your code would not run because f is never instantiated. But I did
test your example and gtt an exception when calling show after the form
was closed:

Cannot access a disposed object named "Form2".

This does not happen when the form is shown using ShowDialog.

From the docs:

"Note When the Close method is called on a Form displayed as a
modeless window, you cannot call the Show method to make the form
visible, because the form's resources have already been released. "

[rforman61]

ng wrote:

There's a really good way to avoid the possibility of this thing lingering:
Declare in the menu click event your form variable as new form1. While
the form will be usable, the variable is already out of scope, because
we have already exited the menu click event. When the form is closed,
no matter how, there is nothing referencing it anymore. The GC won't be
relied upon so heavily.

Tom

Thanks, that won't work for me in this case because I made it a
form-level variable for actual reasons where I might need to look for
or do other things with the form, if it is currently loaded, from other
functions outside the menu-click where it is created. But thanks again
for the response.
richforman

Chris wrote:

rf******@optonline.net wrote:

Thanks so much to both you guys for your responses, let me keep the
discussion going with another question or two:

Chris Dunaway wrote:

> (under MenuItem1's click event)
>
> mfrmForm1 = new form1
> mfrmForm1.MDIParent = me
> mfrmForm1.show
>
> the designer.) Let's further say that the user then closes this first
> instance of Form1 using the control-box "X" at its upper right hand
When a form is shown by calling the Show method, it is automatically
disposed when it is closed.

Now, I didn't know this, and to tell you the truth, from my testing,
I'm not really convinced that this is correct. It might be, but I
think it's not the essential point for what I'm trying to find out, so
let me ask about the next point for my own understanding:
> (under MenuItem2's click event:)
>
> mfrmForm1 = new form1
> mfrmForm1.MDIParent = me
> mfrmForm1.Show
>
> ...thereby creating a second instance of Form1. Now, the original,
> first instance of Form1 never had its .Close or .Dispose method
The mfrmForm1 variable now points at the *new* form instance. Since
nothing points to the first instance anymore, it is eligible for GC.

This is what I really wanted to know, so let me reiterate this and
verify that we're all in agreement on this. I suspected this but
wasn't sure....and this is what you say here, so I just want to make
sure it's true (so I can report back to my boss about this
issue!)....if the object is no longer pointed to by any variable, then
it is will be GC'd, even though if it still "exists"?

If this is the case, then I have to keep looking for the cause of the
performance reduction some users of my app (but not all) are
experiencing over time.

richforman

Yes, if nothing has a reference to it, then it will be GC'd whenever
the GC gets around to it... It won't happen right away. There are
memory monitors around for .Net that should help you. You can't rely
on taskmanager for an accurate monitor.

Chris