App don't stop when closing the form

  • Thread starter Thread starter ThunderMusic
  • Start date Start date
T

ThunderMusic

Hi,
My app does not stop whan I click on the form. I mean, the form is
closing, but the process keeps running in the task manager. So I figured
there are memory leaks or some object's process stuck at some point. Is
there an easy way to know where it comes from other than putting breakpoints
all over the code? 'cause it's huge and I would have to set breakpoints for
at least a day or two

thanks
 
Obviously you have wrong approach on creating and destroying objects
instances.
For all objects that have implemented IDisposable, i suggest you to call
obj.Dispose and set it to obj = Nothing (or null) when you dont need him any
more.

.... it is also possible that you did not exit some loop !?

Regards,
Josip Habjan
URL: http://www.habjansoftware.com
 
ThunderMusic,

What do you mean with keeps running, all day long or a short time?

Cor
 
Josip,
For all objects that have implemented IDisposable, i suggest you to call
obj.Dispose and set it to obj = Nothing (or null) when you dont need him
any more.
Click to expand...

All textboxes, panels, forms, comboboxes and other controls and datasets
etc, which are on the forms, which have IDisposable implemented?

Cor
 
Josip,

In your first by you supported link I did not see what you wrote, as well
not on the other from Microsoft. Adviced is that when you use unmanaged
resources to implement Idisposable.

This is already implemented in any class that inherits from component. Which
is 80% of the in my opinion in general most used. And as Jon Skeet ones has
checked 20 % of the actual ones. Disposing is mostly done in the higher
class itself. See for that the part in the hidden part of a form or a
component. This you find back in almost all samples from Microsoft about
dispose.

On the blog page there is an explanation that is for me the same as: "What
does it harm to set all integers that you have created in your procedure to
zero". If you don't understand what I want to say with that. Just leave it,
however this tells for me only something about the knowledge from the
writers of this kind of sentences.

I hope this helps,

Cor
 
Cor,

From my point of view, MS should keep C++ concept on creating and destroying
objects. If you create new object instance, then you are responsible to
destroy it. In framework, GC may implicate on preformances since he decides
when he will call suppressfinalize. ( I know that he is waiting for best
time, but anyway )....

I have habit to call object.dispose (and =nothing) for every object instance
that i create (except: Usercontrols, string, integer and related types).
This way, i'm shure that my application will close immediate when i close
it, and will not stay in memory for next 5 minutes (waiting for GC to do his
work) ...

Regards,
Josip Habjan
URL: http://www.habjansoftware.com
 
Josip,

I think that we both have a different idea. I keep it by managed code.

However, that from the GC in your application is strange. My experience is
that the GC starts direct as soon as there is a kind of idle time in the
application. Even when the Graphical processor takes over the painting on
screen.

Cor
 
Josip Habjan said:
I have habit to call object.dispose (and =nothing) for every object instance
that i create (except: Usercontrols, string, integer and related types).
Click to expand...

You can't call Dispose on most types though - there are plenty of types
which don't implement IDisposable.

Also note that setting a variable to nothing is rarely useful, IME.
This way, i'm shure that my application will close immediate when i close
it, and will not stay in memory for next 5 minutes (waiting for GC to do his
work) ...
Click to expand...

Disposing of an object doesn't garbage collect it.
 
I mean forever... I must end the task using the task manager...

Someone told something about being stuck un a loop, I'll look into this and
look in all my always running loops.... maybe one does not stop...

thanks
 
Thundermusic,

Are you using Visual Studio Net. Than just try with setting some breakpoints
if the program is still running. It should not stop in the way you describe
it in my opinion in your debugger too.

I hope this helps,

Cor
 
Jon Skeet said:
You can't call Dispose on most types though - there are plenty of types
which don't implement IDisposable.
Click to expand...

I agree, but aso there are planty of types that does implements IDisposable.
Also note that setting a variable to nothing is rarely useful, IME.
Click to expand...

May be, and may be not. Why?
Uisng FileStream .. i created new file, write something to it and then i
close it. I next step i tryed to open this same file to append something to
it, but this file was 'locked' from first step where i created it... Why?
Obviously some reference to this file is still hanginge somewhere in the
air!? I can only tell you that i tryed this fiew times and only thing that
helped is setting 'FileStream = Nothing' after I dont need it any more
(first step), and then i could reopen this same file and append something to
it. (When file was locked, restarting PC helps :o)) ...
You give me some reasonable explanation for this and then i will belive you
that setting a variable to nothing is rarely useful.
Disposing of an object doesn't garbage collect it.
Click to expand...

Yes, but as i readed somewhere GC will have less work.

Regards,
Josip Habjan
URL: http://www.habjansoftware.com
 
Josib,
May be, and may be not. Why?
Uisng FileStream .. i created new file, write something to it and then i
close it. I next step i tryed to open this same file to append something
to it, but this file was 'locked' from first step where i created it...
Why? Obviously some reference to this file is still hanginge somewhere in
the air!? I can only tell you that i tryed this fiew times and only thing
that helped is setting 'FileStream = Nothing' after I dont need it any
more (first step), and then i could reopen this same file and append
something to it. (When file was locked, restarting PC helps :o)) ...
Click to expand...

Did you try this instead
http://msdn.microsoft.com/library/d.../frlrfsystemiostreamwriterclassflushtopic.asp

You can also use the autoflush.

I hope this helps,

Cor
 
Josip Habjan said:
I agree, but aso there are planty of types that does implements IDisposable.
Click to expand...

Sure, but you said that you called Dispose on *every* object you create
except user controls, string, integer and related types.
May be, and may be not. Why?
Uisng FileStream .. i created new file, write something to it and then i
close it. I next step i tryed to open this same file to append something to
it, but this file was 'locked' from first step where i created it... Why?
Click to expand...

I'd have to see the code, but it certainly sounds like you weren't
actually closing it properly.
Obviously some reference to this file is still hanginge somewhere in the
air!? I can only tell you that i tryed this fiew times and only thing that
helped is setting 'FileStream = Nothing' after I dont need it any more
(first step), and then i could reopen this same file and append something to
it. (When file was locked, restarting PC helps :o)) ...
You give me some reasonable explanation for this and then i will belive you
that setting a variable to nothing is rarely useful.
Click to expand...

Under the debugger, it makes a difference in situations where you
aren't disposing properly. The correct solution is to call Dispose
appropriately.

The time it *does* make a difference is when it's a static or instance
variable, and you don't need the FileStream any more despite the rest
of the object living on. This tends to be a sign of poor design, IME.
Yes, but as i readed somewhere GC will have less work.
Click to expand...

It means the finalizer doesn't need to be called, yes.
 
Back
Top