Close vs. Dispose

[Nathan]

I know this has been asked previously, but I've run into a situation where I
need to know the difference between close and dispose, and I can't get the
information I need from msdn help or previous posts.

I have a game form that has a timer, which runs as long as the game is being
played. When the timer reaches zero, the GameOver form is called. On the
game form is a Quit button, in whose click event I have only the command
"Me.Close". However, when I hit Quit before the timer runs out, the form
closes, but the timer still runs. I know this because as I'm working with
other forms in the application, the GameOver form will pop up out of
nowhere. If I use "Me.Dispose" in the Quit button's click event, there is
no problem.

What I want to know is basically what is the difference between close and
dispose? Is msdn library incorrect when it says "When a form is closed, all
resources created within the object are closed and the form is disposed"?

[Herfried K. Wagner [MVP]]

* "Nathan" <nk*********************@softhome.net> scripsit:

I know this has been asked previously, but I've run into a situation where I
need to know the difference between close and dispose, and I can't get the
information I need from msdn help or previous posts.

I have a game form that has a timer, which runs as long as the game is being
played. When the timer reaches zero, the GameOver form is called. On the
game form is a Quit button, in whose click event I have only the command
"Me.Close". However, when I hit Quit before the timer runs out, the form
closes, but the timer still runs. I know this because as I'm working with
other forms in the application, the GameOver form will pop up out of
nowhere. If I use "Me.Dispose" in the Quit button's click event, there is
no problem.

What I want to know is basically what is the difference between close and
dispose? Is msdn library incorrect when it says "When a form is closed, all
resources created within the object are closed and the form is disposed"?

'Close' will dispose the form automatically, if possible. In your case,
you should disable the timer before calling its 'Close' method.
--
Herfried K. Wagner [MVP]
<http://www.mvps.org/dotnet>

[Armin Zingler]

"Nathan" <nk*********************@softhome.net> schrieb

I know this has been asked previously, but I've run into a situation
where I need to know the difference between close and dispose, and I
can't get the information I need from msdn help or previous posts.

I have a game form that has a timer, which runs as long as the game
is being played. When the timer reaches zero, the GameOver form is
called. On the game form is a Quit button, in whose click event I
have only the command "Me.Close". However, when I hit Quit before
the timer runs out, the form closes, but the timer still runs. I
know this because as I'm working with other forms in the application,
the GameOver form will pop up out of nowhere. If I use "Me.Dispose"
in the Quit button's click event, there is no problem.

What I want to know is basically what is the difference between close
and dispose? Is msdn library incorrect when it says "When a form is
closed, all resources created within the object are closed and the
form is disposed"?

In addition to Herfried: If you call the Form's Dispose method, it is
"killed", e.g. no closing and closed events occur. That's why you should
call the Close method.

--
Armin

http://www.plig.net/nnq/nquote.html
http://www.netmeister.org/news/learn2quote.html

[Cor]

Hi Nathan,

In addition to Herfried and Armin,

There is no difference, they are complementary.
Close, prepare everything for ending nice
Dispose, end (kill) it.

Cor

I know this has been asked previously, but I've run into a situation where I need to know the difference between close and dispose, and I can't get the
information I need from msdn help or previous posts.

I have a game form that has a timer, which runs as long as the game is being played. When the timer reaches zero, the GameOver form is called. On the
game form is a Quit button, in whose click event I have only the command
"Me.Close". However, when I hit Quit before the timer runs out, the form
closes, but the timer still runs. I know this because as I'm working with
other forms in the application, the GameOver form will pop up out of
nowhere. If I use "Me.Dispose" in the Quit button's click event, there is
no problem.

What I want to know is basically what is the difference between close and
dispose? Is msdn library incorrect when it says "When a form is closed, all resources created within the object are closed and the form is disposed"?

[Herfried K. Wagner [MVP]]

* "Cor" <no*@non.com> scripsit:

In addition to Herfried and Armin,

There is no difference, they are complementary.
?!?

Is something is not different, how can it be complementary?
Close, prepare everything for ending nice
Dispose, end (kill) it.

Sorry, I don't get the point.

--
Herfried K. Wagner [MVP]
<http://www.mvps.org/dotnet>

[Cor]

Hi Herfried,

Is something is not different, how can it be complementary?

In the letter you are right, but a man and a woman are also not different
and yet they are complementary.
Close, prepare everything for ending nice
Dispose, end (kill) it.

You can (have to) use them both,

Clear?

Cor

[Herfried K. Wagner [MVP]]

* "Cor" <no*@non.com> scripsit:

Is something is not different, how can it be complementary?

In the letter you are right, but a man and a woman are also not different
and yet they are complementary.

Are you sure about that?

:-)

--
Herfried K. Wagner [MVP]
<http://www.mvps.org/dotnet>

[Cor]

Yes

In the letter you are right, but a man and a woman are also not different and yet they are complementary.

Are you sure about that?

:-)

[Joe \Nuke Me Xemu\ Foster]

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message <news:O9**************@TK2MSFTNGP10.phx.gbl>...

* "Cor" <no*@non.com> scripsit:

In addition to Herfried and Armin,

There is no difference, they are complementary.

?!?

Is something is not different, how can it be complementary?

Close, prepare everything for ending nice
Dispose, end (kill) it.

Sorry, I don't get the point.

It's an example of Hejlsberg Syndrome, caused by rampant bad taste
in language and library design. The Close method must be roughly
equivalent to Visual Basic's Unload statement, while in this case
Dispose is something that should be available only to each form's
implementation code or, better yet, be equivalent to Close, had
the CLR actually been designed properly, or indeed designed at all.

--
Joe Foster <mailto:jlfoster%40znet.com> Sign the Check! <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!

[Cor]

Hi Joe,

I have seen so many names in my live, that has been assigned by people to
program functions or whatever, that I think it is not that important, it is
subjective.
Mostly you find the most meaningless words in program languages made at
places like a coffee desk in a restaurant or something. (Fortunately, the
same effect from these languages is that they fast disappear)

But if it is called femme, vrouw, frau, donna, kobieta, mulher, it does not
matter, if you do not know how to handle it in the right way, you always
have problems.

That is the same with this.

Just my thought,

Cor

It's an example of Hejlsberg Syndrome, caused by rampant bad taste
in language and library design. The Close method must be roughly
equivalent to Visual Basic's Unload statement, while in this case
Dispose is something that should be available only to each form's
implementation code or, better yet, be equivalent to Close, had
the CLR actually been designed properly, or indeed designed at all.

[Hexathioorthooxalate]

All, I've been following this thread all day and I'm not really sure what
the long discussion in this thread is really about.

Colloquially as I see it an object (I know we are talking about a form here
but I am talking in a general sense) "Close" method does some tidy up things
ready to be garbage collected (GC'd). The object will be GC'd whenever the
next garbage collection occurs and iff the object is ready to be GC'd - that
is there are no other instances of the object in the app.

The "Dispose" method on the otherhand, implemented through IDisposable, has
a contract to tidy up/release resources and remove itself from the list of
objects to be GC'd now (removal from the objects on the heap to GC by
invoking the method "suppressFinalise").

So the big difference - invoke "Dispose" to explicitly release resource and
remove from the list of objects to GC now; "Close" to implicitly dispose and
release resource whenever the next garbage collection occurs, which may be
next week and take a greedy timeslice.

Yes the online documentation on this topic is scarce; lets get some feedback
here and clean this recurring issue up once and for all.
Regards
Hexathioorthooxalate
"Nathan" <nk*********************@softhome.net> wrote in message
news:uk**************@TK2MSFTNGP10.phx.gbl...

I know this has been asked previously, but I've run into a situation where I need to know the difference between close and dispose, and I can't get the
information I need from msdn help or previous posts.

I have a game form that has a timer, which runs as long as the game is being played. When the timer reaches zero, the GameOver form is called. On the
game form is a Quit button, in whose click event I have only the command
"Me.Close". However, when I hit Quit before the timer runs out, the form
closes, but the timer still runs. I know this because as I'm working with
other forms in the application, the GameOver form will pop up out of
nowhere. If I use "Me.Dispose" in the Quit button's click event, there is
no problem.

What I want to know is basically what is the difference between close and
dispose? Is msdn library incorrect when it says "When a form is closed, all resources created within the object are closed and the form is disposed"?

[Cor]

Hi Hexathioorthooxalate

It is in my eyes the same as "close" the book and "dispose" the book at the
garbage.

Why such a long explanation?

Cor

[Hexathioorthooxalate]

Whenever garbage collection occurs and the system gets around to invoking
the Finalize() method for all the moribund instances of objects I might have
created, as GC occurs outside my immediate control, at seemingly random
times, and occasionally with an antisocial CPU timeslice, I have observed
machines grinding to a halt for several seconds. This is neither good for
the 'user-experience' nor helps me sell the all the other great benefits of
..NET. I have observed that by writing and using a Dispose() method, getting
rid of dying object instances from the managed heap on-the-fly as and if
necessary, gives the impression that my apps are more interactive and less
greedy on system resource than other applications I have written for other
VM's.

So I view the method Destroy(), as opposed to other 'tidy-up' object methods
including Close(), from this perspective. But in answer to your question,
the longish explanation really lies in that I had thought about this a few
months back and had no one to bounce ideas off. If my posting was rubbish, I
was hoping that ensuing discussion would have put me on the right track.
Kind regards
Hexathioorthooxalate


"Cor" <no*@non.com> wrote in message
news:u1**************@TK2MSFTNGP10.phx.gbl...

Hi Hexathioorthooxalate

It is in my eyes the same as "close" the book and "dispose" the book at the garbage.

Why such a long explanation?

Cor

[Joe \Nuke Me Xemu\ Foster]

"Cor" <no*@non.com> wrote in message <news:#M**************@TK2MSFTNGP12.phx.gbl>...

Hi Joe,

I have seen so many names in my live, that has been assigned by people to
program functions or whatever, that I think it is not that important, it is
subjective.
Just don't mix up Close and Dispose when working with forms, eh?
Mostly you find the most meaningless words in program languages made at
places like a coffee desk in a restaurant or something. (Fortunately, the
same effect from these languages is that they fast disappear)
A pub table is exactly where .NyET appears to have been 'designed':

URL:http://www.jaggersoft.com/pubs/Excep...ngInCSharp.htm

URL:http://weblogs.asp.net/ricom/archive.../04/41281.aspx
But if it is called femme, vrouw, frau, donna, kobieta, mulher, it does not
matter, if you do not know how to handle it in the right way, you always
have problems.

That is the same with this.

In real languages, like (unmanaged) C++ and Visual Basic 4/5/6, you
can "handle it" simply by allowing the variable to go out of scope:

URL:http://hackcraft.net/raii/

URL:http://www.research.att.com/~bs/bs_faq2.html#finally considered harmful

Bring me the head of Anders Hejlsberg.

--
Joe Foster <mailto:jlfoster%40znet.com> Wanna buy a Bridge? <http://xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!

[Joe \Nuke Me Xemu\ Foster]

"Hexathioorthooxalate" <ru***@clara.co.uk> wrote in message <news:10****************@echo.uk.clara.net>...

Whenever garbage collection occurs and the system gets around to invoking
the Finalize() method for all the moribund instances of objects I might have
created, as GC occurs outside my immediate control, at seemingly random
times, and occasionally with an antisocial CPU timeslice, I have observed
machines grinding to a halt for several seconds. This is neither good for
the 'user-experience' nor helps me sell the all the other great benefits of
.NET. I have observed that by writing and using a Dispose() method, getting
rid of dying object instances from the managed heap on-the-fly as and if
necessary, gives the impression that my apps are more interactive and less
greedy on system resource than other applications I have written for other
VM's.
This forces details of an object's implementation onto each and
every client using that object, namely, the fact that the object
holds resources that need to be cleaned up promptly. Oh well, I
suppose this doesn't really break encapsulation, supposedly OOP's
compelling advantage along with dynamic polymorphism, any worse
than the ill-considered obsession with implementation inheritance
and resulting fat and fragile base classes and overuse of methods
do already. .NyET has set software development back by 40 years:

URL:http://216.239.57.104/search?q=cache...2/sidebar4.asp
So I view the method Destroy(), as opposed to other 'tidy-up' object methods
including Close(), from this perspective. But in answer to your question,
the longish explanation really lies in that I had thought about this a few
months back and had no one to bounce ideas off. If my posting was rubbish, I
was hoping that ensuing discussion would have put me on the right track.

What then would be the difference between Close() and setting the
reference variable to Nothing or letting it fall out of scope?

--
Joe Foster <mailto:jlfoster%40znet.com> DC8s in Spaace: <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!

[Cor]

I did not change anything only stuffed the beginning and that you can see in
the previous message.

my message

answer from Joe

But if it is called femme, vrouw, frau, donna, kobieta, mulher, it does not matter, if you do not know how to handle it in the right way, you always
have problems.

That is the same with this.

In real languages, like (unmanaged) C++ and Visual Basic 4/5/6, you
can "handle it" simply by allowing the variable to go out of scope:

[Hexathioorthooxalate]

"Joe "Nuke Me Xemu" Foster" <jo*@bftsi0.UUCP> wrote in message
news:O$**************@TK2MSFTNGP12.phx.gbl...

Hi Joe - comments in-line.
Thanks for your reply.

Hexathioorthooxalate

"Hexathioorthooxalate" <ru***@clara.co.uk> wrote in message <news:10****************@echo.uk.clara.net>...

Whenever garbage collection occurs and the system gets around to invoking the Finalize() method for all the moribund instances of objects I might have created, as GC occurs outside my immediate control, at seemingly random
times, and occasionally with an antisocial CPU timeslice, I have observed machines grinding to a halt for several seconds. This is neither good for the 'user-experience' nor helps me sell the all the other great benefits of .NET. I have observed that by writing and using a Dispose() method, getting rid of dying object instances from the managed heap on-the-fly as and if
necessary, gives the impression that my apps are more interactive and less greedy on system resource than other applications I have written for other VM's.
This forces details of an object's implementation onto each and
every client using that object, namely, the fact that the object
holds resources that need to be cleaned up promptly.

Not necessarily \*need\* to be cleaned up promptly, just that judicious
choice of what to explicitly force to clean up can give better
responsiveness and 'user experience'.

Oh well, I
suppose this doesn't really break encapsulation, supposedly OOP's
compelling advantage along with dynamic polymorphism, any worse
than the ill-considered obsession with implementation inheritance
and resulting fat and fragile base classes and overuse of methods
do already. .NyET has set software development back by 40 years:

URL:http://216.239.57.104/search?q=cache...2/sidebar4.asp
Quote from this article: "The loss of deterministic finalization has caused
some controversy lately because programs th... ". Well it's not lost
completely in .NET, that's my point with the Destroy() method rather than
relying on implicit garbage collection. And I'm not convinced that ".NyET
has set software development back by 40 years" is correct either, not even
commenting on the "...back 40 years" bit, to be balanced your statement
should begin ".NyET and other common OO implementations such as Java have
set software development back 40 years ......". The same points apply.

So I view the method Destroy(), as opposed to other 'tidy-up' object methods including Close(), from this perspective. But in answer to your question, the longish explanation really lies in that I had thought about this a few months back and had no one to bounce ideas off. If my posting was rubbish, I was hoping that ensuing discussion would have put me on the right track.

#

What then would be the difference between Close() and setting the
reference variable to Nothing or letting it fall out of scope?
The difference is that the managed heap containing the the objects to be
released won't contain objects released with Destroy() and therefore suffer
the often antisocial CPU expensive penalty of garbage collection when it
decides to run. Setting the class instance to nothing or letting it fall out
of scope means that it would just get popped onto the heap, and released
when garbage collection occurred, and possibly getting thrashed when it
does.

--
Joe Foster <mailto:jlfoster%40znet.com> DC8s in Spaace: <http://www.xenu.net/> WARNING: I cannot be held responsible for the above They're coming to because my cats have apparently learned to type. take me away, ha ha!

[José Manuel Agüero]

Hello, Nathan:

Bypassing your question about Close and Dispose, and going directly to your problem, I think it's related with the fact that timers are components, not controls. I can't go farther in this matter because of lack of knowledge, but I think they are not destroyed when all references to them have disappeared, and they must be stopped before the form is closed or they will keep alive.

I've make a test, but I'm not sure that it's correct:
'\\\
imports system.windows.forms, system.drawing

module StartModule
friend ac as applicationcontext
public sub Main()
ac=new applicationcontext(new form1)
application.run(ac)
end sub
end module

class Form1
inherits form
friend withevents t1 as timer
friend withevents b1 as button

public sub new
mybase.new
me.text="This is Form1"
t1=new timer
t1.enabled=true
t1.interval=500
b1=new button
b1.text="Close"
me.controls.add(b1)
end sub

private sub t1_tick(byval p1 as object, byval p2 as system.eventargs) handles t1.tick
beep
end sub

private sub b1_click(p1 as object, p2 as system.eventargs) handles b1.click
ac.mainform=new form2
ac.mainform.text="This form is Form2"
ac.mainform.visible=true
me.close
'me.dispose 'Will not stop the timer (neither if it's declared private)
't1.enabled=false 'This (or t1.dispose) is the only way of getting rid of the ding, ding, ding, ...
end sub
end class

class Form2
inherits form
end class
'///

Regards.
"Nathan" <nk*********************@softhome.net> escribió en el mensaje news:uk**************@TK2MSFTNGP10.phx.gbl...
| I know this has been asked previously, but I've run into a situation where I
| need to know the difference between close and dispose, and I can't get the
| information I need from msdn help or previous posts.
|
| I have a game form that has a timer, which runs as long as the game is being
| played. When the timer reaches zero, the GameOver form is called. On the
| game form is a Quit button, in whose click event I have only the command
| "Me.Close". However, when I hit Quit before the timer runs out, the form
| closes, but the timer still runs. I know this because as I'm working with
| other forms in the application, the GameOver form will pop up out of
| nowhere. If I use "Me.Dispose" in the Quit button's click event, there is
| no problem.
|
| What I want to know is basically what is the difference between close and
| dispose? Is msdn library incorrect when it says "When a form is closed, all
| resources created within the object are closed and the form is disposed"?

[Joe \Nuke Me Xemu\ Foster]

"Hexathioorthooxalate" <ru***@spameremove.clara.co.uk> wrote in message <news:10****************@iris.uk.clara.net>...

"Joe "Nuke Me Xemu" Foster" <jo*@bftsi0.UUCP> wrote in message
news:O$**************@TK2MSFTNGP12.phx.gbl...

"Hexathioorthooxalate" <ru***@clara.co.uk> wrote in message

<news:10****************@echo.uk.clara.net>...

.NET. I have observed that by writing and using a Dispose() method, getting
rid of dying object instances from the managed heap on-the-fly as and if
necessary, gives the impression that my apps are more interactive and less
greedy on system resource than other applications I have written for other
VM's.

This forces details of an object's implementation onto each and
every client using that object, namely, the fact that the object
holds resources that need to be cleaned up promptly. Not necessarily \*need\* to be cleaned up promptly, just that judicious
choice of what to explicitly force to clean up can give better
responsiveness and 'user experience'.

That depends on just what exactly those objects manage.

URL:http://weblogs.asp.net/ricom/archive.../04/41281.aspx
Oh well, I
suppose this doesn't really break encapsulation, supposedly OOP's
compelling advantage along with dynamic polymorphism, any worse
than the ill-considered obsession with implementation inheritance
and resulting fat and fragile base classes and overuse of methods
do already. .NyET has set software development back by 40 years:

URL:http://216.239.57.104/search?q=cache...2/sidebar4.asp

Quote from this article: "The loss of deterministic finalization has caused
some controversy lately because programs th... ". Well it's not lost
completely in .NET, that's my point with the Destroy() method rather than
relying on implicit garbage collection. And I'm not convinced that ".NyET
has set software development back by 40 years" is correct either, not even
commenting on the "...back 40 years" bit, to be balanced your statement
should begin ".NyET and other common OO implementations such as Java have
set software development back 40 years ......". The same points apply.

The difference is, Smalltalk and Java haven't been shoved down every
developer's throat in quite the same way Micro$haft is doing with .NyET.
It's very interesting how developers are trying to regain the resource
management functionality lost on the trail of tears from VB4/5/6 to B#:

URL:http://www.jaggersoft.com/pubs/Excep...ngInCSharp.htm

It's also very interesting how VB Classic's On Error GoTo achieves
the advantages touted for try/catch:

* Use Err.Source to discover which component raised the error, then
use an enum provided by the component to compare with Err.Number.

* With Err.Source, it doesn't matter if components have overlapping
error numbers.

* Error handling can be separated from the "essential functionality"
in the same way as shown in the "PainLess" example.

Of course, what would be much better is if structs may have real
destructors instead of forcing developers to hink around with using
and try/finally, but Anders Hejlsberg thinks you should be grateful
for try/finally. It took some pressure from within Microsoft to
get him to add "using" to C# at all...

What then would be the difference between Close() and setting the
reference variable to Nothing or letting it fall out of scope?

The difference is that the managed heap containing the the objects to be
released won't contain objects released with Destroy() and therefore suffer
the often antisocial CPU expensive penalty of garbage collection when it
decides to run. Setting the class instance to nothing or letting it fall out
of scope means that it would just get popped onto the heap, and released
when garbage collection occurred, and possibly getting thrashed when it
does.

I'm still confused about how you think Close() and Dispose() should
differ. Even though VB 4/5/6 lacked structs with destructors, (or
even methods for that matter) its classes could do the job just fine:

URL:http://hackcraft.net/raii/

Bring me the head of Anders Hejlsberg.

--
Joe Foster <mailto:jlfoster%40znet.com> DC8s in Spaace: <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!

[Joe \Nuke Me Xemu\ Foster]

"Cor" <no*@non.com> wrote in message <news:u1**************@TK2MSFTNGP09.phx.gbl>...

Nathan,

Why you try to compare different things,

Living has a connection with swimming, but it is very difficult to tell the
difference.

Close and dispose have one equality, they both are at the end of something.

Perhaps more classes should have multiple "cleanup" methods. Files
could have a Close which does the expected thing and also a Dispose
which "kills" the file without first flushing any output buffer. =O
Of course, the finalizers should follow the current "best practice"
du jour from the C# groups and always throw an exception in order
to crash the application, to teach the programmer what "automatic
garbage collection" is /really/ all about...

Feh.

--
Joe Foster <mailto:jlfoster%40znet.com> L. Ron Dullard <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!