3

How can I get all instances from a certain class or kill all instances of certain class?

For Example, I've a Class MyClass which I intantiate three times as m1, m2 and m3.

Is there a way to get or kill all these instances?

more clarification : when I've a "settings form" class. When the user click Settings button the application makes instance from this class. When he clicks the same button again it makes new instance. I want it show the 1st instance only and not making new instance

EgyEast
  • 1,542
  • 6
  • 28
  • 44
  • What do you mean, "kill"? The concept doesn't exist, in general. What are these instances? – John Saunders May 29 '10 at 14:41
  • What problem are you trying to solve? – ChrisF May 29 '10 at 14:43
  • Ok, i'll clarify more: when I've a "settings form" class. When the user click Settings button the application makes instance from this class. When he clicks the same button again it makes new instance. I want it show the 1st instance only and not making new instance. – EgyEast May 29 '10 at 14:49
  • I don't think you want to "kill" the existing instance - you seem to want to reuse it. The simplest way to achieve this would be to make the reference to the settings class a private variable in your form. – David_001 May 29 '10 at 14:59

3 Answers3

4

Not that i'm aware, but you can save the instance when constructing the object on some sort of collection so you can access all instances later:

public class MyClass {
    public static List<MyClass> instances = new List<MyClass>();
    public MyClass() {
        instances.Add(this);
    }
}

EDIT:

Save the settings class as a field for the form, and when clicking button, check if that field is null; if so, instantiate

public class Form1 : Form {
    private SettingsClass settings;

    ...
    ...

    private void btnSettings_Click(object sender, EventArgs e) {
        if (settings == null) {
            settings = new SettingsClass();
        } else {
            // do nothing, already exists
        }

        // use settings object
    }
}
Jhonny D. Cano -Leftware-
  • 17,663
  • 14
  • 81
  • 103
  • Ok that's great but there is still another problem: when the settings form is opened and closed by user from control box (disposed) it doesn't return null. and in the same time the application wouldn't open it again because it is not null. – EgyEast May 29 '10 at 15:00
  • Post some code about how you're closing it? (to the original question) – s_hewitt May 29 '10 at 15:04
  • Thank you, After modification to your code the problem has benn solved. the code after modification is public void LoadFrmSettings() { if (Sett != null) { if (Sett.Visible == true) { Sett.Activate(); return; } } Sett = new FrmSett(); Sett.Show(); } – EgyEast May 29 '10 at 15:15
1

For your form example, you can keep the form as a variable in your main program. This way you only have one instance of the settings form.

private SettingsForm settingsForm = null;

SettingsButton_Click()
{
    if(settingsForm == null)
    {
         settingsForm = new SettingsForm();
    }
    settingsForm.Show();
}
s_hewitt
  • 4,252
  • 24
  • 24
  • but when it is disposed from control box by user when clicking the button it shows error "Cannot access a disposed object." – EgyEast May 29 '10 at 15:03
0

When you instantiate them, put them into a higher-scoped generic list:

List<MyClass> myObjects = new List<NyClass>();

Then, when you make the objects inside a function:

m1 = new MyClass();
m2 = new MyClass();
m3 = new MyClass();

myObjects.add(m1);
myObjects.add(m2);
myObjects.add(m3);

then, at a later stage:

foreach(MyClass m in myObjects)
{
    m.do_whatever_you_want();
    m = null; // SEE EDIT BELOW
}

--------Edit----------- As discussed with John Saunders in the comments below, this is not possible. My apologies.

Martin Eve
  • 2,703
  • 1
  • 23
  • 23
  • @John Sauders: I assumed that he asked how to "kill" a class because the class was persisting in some way or another. Setting to null will mark the class for garbage collection. How is this "unnecessary" given the context of the question? (which implies that the object is being persisted) – Martin Eve May 29 '10 at 14:50
  • 2
    @Martin: in .NET, setting to null doesn't dispose of any resources. This is especially true since the next iteration will assign a new value to m. – John Saunders May 29 '10 at 14:58
  • @John: My apologies; I was getting confused with the by-reference nature of foreach. Seems that (http://stackoverflow.com/questions/1538301/c-does-foreach-iterate-by-reference) foreach statements are by-reference (so setting null would dererence the object) but are also read-only, so this isn't possible. – Martin Eve May 29 '10 at 15:07
  • 2
    @Martin: you _still_ don't _ever_ need to set to null in .NET, at least not for the purpose of freeing resources. This is not VB6. – John Saunders May 29 '10 at 15:15
  • @John: I'm sorry, but to state that there is *never* any need to set to null is just wrong. See: http://weblogs.asp.net/pwilson/archive/2004/02/20/77422.aspx (written by Paul Wilson, a highly respected .NET developer -- http://paul.wilsondotnet.com/ -- top result for ".NET set to null" on Google.) If an object goes out of scope, then yes, it will be automatically cleaned by GC. If you want to force that to happen manually, for instance because the object is persisting for a long time, then setting the object to null is a perfectly valid solution to force GC. – Martin Eve May 29 '10 at 15:40
  • @John - this last comment was the point I was trying to make too. However, as the question's been updated and the answer I would have posted accepted I just deleted my answer. – ChrisF May 29 '10 at 16:00
  • @Martin: what year is this? What year was that? I'm pretty sure the CLR doesn't depend on lexical scope - it knows when the reference is no longer used, as the JIT is what wrote the code to begin with. – John Saunders May 29 '10 at 19:18
  • @Martin: See "CLR Via C#", Ch 21.3, "Garbage Collections and Debugging" for a similar example. The JIT compiler (part of the CLR) wrote the machine instructions and knows over what span of machine instructions a particular register or memory location is a root. After it is no longer referenced (not "out of scope"), the CLR knows it is no longer a root. The fact that it may be null isn't relevant. – John Saunders May 29 '10 at 19:35