Geoff Callaghan
This depends on the object, but in general it's a good idea to call the
object's 'Dispose' method. It's not necessary to set the variables to
'Nothing' at the end of the method because the references will be deleted
automatically when execution exits the method.
--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>
It is different (see below).
> Is there somewhere I can go for more info on VB Memory management?
.NET Framework Developer's Guide -- Programming for Garbage Collection
<URL:http://msdn.microsoft.com/library/en-us/cpguide/html/cpconprogrammingessentialsforgarbagecollection.asp>
In general it is a bad idea to call dispose because it is there especially
in a form or a component. The same as it is in general to call ToString.
Dispose is standard implemented in componentbase which 20% of the classes
are inheriting from.
There are however classes that use unmanaged resources. That are not much.
Have a look under the table in this page for the nicest description I have
seen so far on MSDN. .
It can as well be a good idea for memory consuming classes. The dispose
gives a sign to the gc that it is ready to release. The dispose itself does
not release anything. However to dispose every label or is really very much
overdone. (Which is done by the implementation of the Idisposable in your
form by the way, see that page for this and open than your form. That is the
reason that I often use a component if I dont use a form where this is part
of the code already in)
I hope this helps,
Cor
I'm not really sure how ToString relates, but if there is a Dispose
method then call it. It's there for a reason.
>
> There are however classes that use unmanaged resources. That are not much.
>
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemidisposableclasstopic.asp
>
> Have a look under the table in this page for the nicest description I have
> seen so far on MSDN. .
>
> It can as well be a good idea for memory consuming classes. The dispose
> gives a sign to the gc that it is ready to release. The dispose itself does
> not release anything. However to dispose every label or is really very much
> overdone. (Which is done by the implementation of the Idisposable in your
> form by the way, see that page for this and open than your form. That is the
> reason that I often use a component if I dont use a form where this is part
> of the code already in)
>
The only sign the Dispose method gives to the GC is telling it not to
run the finalizer. It does not tell the GC that resources consumed by
the class are ready to be released. However, it will, itself, release
unmanaged resources.
1)I am using a sound player object (OPENNETCF). In order to make the code
work, I have a global PLAYER object which is assigned as a NEW PLAYER
every time it is used. I'm concerned that, since I'm doing a new and not a
dispose (there is no dispose method), I'm cluttering the memory with
"orphan" player objects.
2) The main purpose of my program is to show a set of screens. I have one
main screen that controls all the others. The others show in a
sequence...when one is finished, control returns to the main form, and the
main form then displays the next form in the sequence. I'm doing this using
SHOWDIALOG and CLOSE, rather than SHOW and HIDE, because when the new form
displays I want it to be in control. It's working fine. However, from what
I've read, every time I close the form, it disposes of the whole object. If
that's the case, how am I able to show it again without causing an error? Am
I creating a new form every time I do the SHOWDIALOG? It doesn't seem to be
doing that.
"Geoff Callaghan" <gcall...@trakeng.com> wrote in message
news:uor58Mz3...@tk2msftngp13.phx.gbl...
You're fine. If there is no Dispose method then you have nothing to
worry about. The GC will eventually recognize that the player objects
are no longer referenced anywhere and release the memory they consume
eventually. And as others have pointed out setting object references
to Nothing at the ends of methods has no effect.
> 2) The main purpose of my program is to show a set of screens. I have one
> main screen that controls all the others. The others show in a
> sequence...when one is finished, control returns to the main form, and the
> main form then displays the next form in the sequence. I'm doing this using
> SHOWDIALOG and CLOSE, rather than SHOW and HIDE, because when the new form
> displays I want it to be in control. It's working fine. However, from what
> I've read, every time I close the form, it disposes of the whole object. If
> that's the case, how am I able to show it again without causing an error? Am
> I creating a new form every time I do the SHOWDIALOG? It doesn't seem to be
> doing that.
>
ShowDialog does not create a new form. A form is only created by using
the New keyword. Closing a form does not dispose the object. Though,
I'm sure it does releases some unmanaged resources. If you were to
call Dispose on the form then you would get an error the next time you
called ShowDialog.
When to call Dispose?
* Call Dispose when the type itself implements IDisposable
* Call Dispose when the type or one of its base classes *overrides*
Dispose(Boolean) if the class inherits from System.ComponentModel.Component
or System.ComponentModel.MarshalByValueComponent
* Do not explicitly call Dispose on classes deriving from
System.Windows.Forms.Control for instances placed on a
System.Windows.Forms.Form as Form will implicitly dispose of them when the
form is Disposed
* Call Dispose on System.Windows.Forms.Form objects when Form.ShowDialog is
used.
* Do not explicitly call Dispose on System.Windows.Forms.Form objects if
Form.Show is used as Dispose will be implicitly called when the form is
closed
* Do not explicitly call Dispose on classes deriving from
System.Web.UI.Control as it will be implicitly called as part of the normal
ASP.NET page processing
I consider the second rule controversial as it relies on using ILDASM or
Reflector to find out implementation details of a class. Its meant for
classes such as DataSet, that have an inherited Dispose, but Dispose doesn't
really do anything.
These rules are based on private discussions with other MVPs & discussions
held in the newsgroups earlier in 2005.
VB 2005 (.NET 2.0) introduces the Using statement that simplifies calling
Dispose.
' VB 2005 syntax
Using dialog As New OptionsDialog
dialog.ShowDialog(Me)
End Using
' VB 2002 & 2003 syntax
Dim dialog As New OptionsDialog
Try
dialog.ShowDialog(Me)
Finally
' assuming that dialog is not nothing...
dialog.Dispose()
End Finally
--
Hope this helps
Jay [MVP - Outlook]
.NET Application Architect, Enthusiast, & Evangelist
T.S. Bradley - http://www.tsbradley.net
"Geoff Callaghan" <gcall...@trakeng.com> wrote in message
news:uor58Mz3...@tk2msftngp13.phx.gbl...
If you are using Form.ShowDialog, when you call Form.Close the form is
simply hidden. You can then call Form.ShowDialog any number of times you
want. Be certain to call Form.Dispose on the form variable when you are done
with it.
If you are using Form.Show, when you call Form.Close, Form.Dispose is
automatically called for you. You cannot use Form.Show a second time without
creating a new instance of the Form.
--
Hope this helps
Jay [MVP - Outlook]
.NET Application Architect, Enthusiast, & Evangelist
T.S. Bradley - http://www.tsbradley.net
"Geoff Callaghan" <gcall...@trakeng.com> wrote in message
news:Osz5Yp73...@TK2MSFTNGP09.phx.gbl...
In addition to Jay.
What he write about the designer created form is the same for the designer
created Component.
Just a little addition what can be a reason to use that if you create a
class from zero.
Cor
Disposable Objects that are passed to you as a parameter of a method (such
as the Graphics object on the Paint event) should not have their disposed
method call, as the system calls it as part of the method that raises the
event.
Objects that something else "owns" should normally be disposed of by the
"owning" object.
Thanks Cor, I need to add designed Components to my list.
--
Hope this helps
Jay [MVP - Outlook]
.NET Application Architect, Enthusiast, & Evangelist
T.S. Bradley - http://www.tsbradley.net
"Jay B. Harlow [MVP - Outlook]" <Jay_Har...@tsbradley.net> wrote in
message news:%236Xa998...@TK2MSFTNGP12.phx.gbl...
"Geoff Callaghan" <gcall...@trakeng.com> wrote in message
news:uor58Mz3...@tk2msftngp13.phx.gbl...