I'm using a treeview and it points to a Employee class so I can display info about the employee selected. Here are some code snips.
Classes:
public interface AbstractEmployee
public class Employee : AbstractEmployee
class EmpNode : TreeNode {
private AbstractEmployee _emp;
public EmpNode(AbstractEmployee aemp)
: base(emp.getName()) {
_emp = aemp;
}
public AbstractEmployee getEmployee(){
return _emp;
}
}
When I remove nodes, how do I delete the employee and the empNode objects
Treenode nod ;
AbstractEmployee emp;
EmpNode nodeEmp;
for (int i = 0; i < tv.Nodes.Count; i++){
nod = tv.Nodes
; <--- // get the node
nodeEmp = (EmpNode)nod; // get the empNode
emp=nod.getEmployee; // point to the employee
// Delete emp and empNode
}
I found the original code in "C# Design Patterns" book. I'm not familiar with all the terminology yet.
Thank you,
Mike
Deleting objects
Nagesh_techie
Mitch Kupferman
for (int i = 0; i < tv.Nodes.Count; i++){
nod = tv.Nodes
nodeEmp = (EmpNode)nod; // get the empNode
emp=nod.getEmployee; // point to the employee
// Delete emp and empNode
// Just set it to null
emp=null; // object create using new
nodeEmp=null; // object created using new
nod = null; // object created using new
}
Thanks to all
Mike D
Shimit
In addition to the answers provided consider reading up the following stuff on GC.
To read up on how the garbarge collector works and finalization, read the following post by Chris Brumme http://blogs.msdn.com/cbrumme/archive/2004/02/20/77460.aspx.
Also read:
1. Garbage Collection: Automatic Memory Management in the Microsoft .NET Framework - Part I
http://msdn.microsoft.com/msdnmag/issues/1100/GCI/default.aspx
2. Garbage Collection: Automatic Memory Management in the Microsoft .NET Framework - Part II
http://msdn.microsoft.com/msdnmag/issues/1200/GCI2/default.aspx
Regards,
Vikram
Muthu Arumugam
Hi,
You really can't implicitly delete an object just like in C++. All you have to do is mark it as disposed. The GC or garbage Collector runs non-determinitic. But when it runs, all objects marked as disposed would then be deleted in the memory. So you'll have to put in mind that disposable objects (all objects which has a dispose() method) should be called if you don't need it. You must always do this to prevent resource leaks.
The GC's (garbage collector) job is to collect all unused resources, and its definitely doing its job great. But its the programmers job to tell the GC on which resources or objects that it should collect...
cheers,
Paul June A. Domag
Captain Hook
Hi,
On point to make clear. GC is designed to manage memory, not manage resources.
Here's a link that discusses this deeply.
http://www.bluebytesoftware.com/blog/PermaLink.aspx guid=88e62cdf-5919-4ac7-bc33-20c06ae539ae
cheers,
Paul June A. Domag
MDXXI
Thank you for your response.
The point I'm not sure of is who is holding the reference to the objects. Is it the form Since I can have upwards of 1200 of these employee's depending on the department, the resources consumed may be considerable.
When I add a node to the TreeView, I also add an employee member, using "new". The employee class holds about 20 items of employee information including an array of subordinates and a reference to the parent.
I also add a 'new' EmpNode that is the bridge between the tree node and the employee member and allows me to display the employee information when a node is selected.
I've read a bit about Idispose but not comfortable with it yet.
I am using a mdi child form, but the employee class may persist. I'm just not sure.
Any additional help is appreciated.
Thank you,
Mike Davis
Ranganathan P
I guess my concern is releasing the resource.
Am I doing this correctly, setting the class instance to null as shown in the above code
In my destructor for the employee class, should I dispose and set null the arraylist and _parent. What should the class destructor look like
public class Employee: AbstractEmployee{ protected string _name;
protected AbstractEmployee _parent;
protected ArrayList _subordinates; // array of AbstractEmployee
// several other string and int fields
}
Thanks,
Mike
Rahul Kumar
That is actually not the right way to do things, you should let .net take care of your garbage collection entirely and don't intervene by setting things to null. In your example the nod reference is last accessed at the "nod = null" line, so the nod is only marked as being able to be garbage collected at that line. If you leave the "nod = null" line out altogether then nod is marked as viable for GC at the "emp = nod.getEmployee" line as that is when it is last used.
NewbiePhil
Hi,
If your using native C++, I could say that your statement is correct. But since your using C# I'll have to agree to the previous poster, don't set objects to null for it doesn't release them in memory (although it seems like it). Remember that you cannot explicitly destroy an object in the managed memory. Simply tag it as disposed() and let GC handle its own job.
Some programmers believe on the principle that just GC automatically frees resources for you. GC just manages memories it is you who manages your resources. So to be safe, just place in your mind that if an object has a Dispose method, then you should call it after you consumed the it...
cheers,
Paul June A. Domag
Jim Millar
You may be correct regarding the nod. However in the case of a TreeView, I actually use the method TreeView.Nodes.Clear() which may be a little safer.
This is the exact point that got me going down this trail.
If I want to reuse the Treeview, clear() removes all the nodes from the collection and that consumes far less resources than my employee structure.
Thank you Aidy for pointing this out.
[Edit]
One other thing I wanted to point out. In Excel's first go around with VBA or the macros, (back in the mid 90's) we complained about memory leaks. The culprit was not setting the object to 'nothing' and the script running out of scope.
When MS says "Don't worry, Ill take care of it", from hard found experience, the hair on my neck stands up. Believe me I worry.
Mike D