"Turn" the difference between Dispose, Close, =null

I wanted to make a small example of a simple single-piece design pattern (Singleton) in the morning, and there were some unexpected problems. My intention is to set up two form classes Form1 and Form2, put a button named Button1 on Form2, click Button1 will bring up the Form1 window case, and ensure that when you click Button1, no longer the second Form1 instance, Unless you turn off the Form1 instance and click Button1 again, it is guaranteed that only one Form1 instance will pop up (not in modal mode, of course). The code looks like this:  form1 class        public class form1       {                   Private Static Form1 frm;              Private Form1 ()// This constructor allows only intra-class calls, so it is private               {                       InitializeComponent ();             }                public static Form1 CreateForm1 ()//The function can take parameters, think about how to implement              {                      if (frm = = null)                        {                             frm = new Form1 ();                              return frm;                     }                      else                      {                              Return frm;                     }             }       } form2 class                public class form2       {                   .....                private void Button1_Click (object sender, System.EventArgs e)                {                      Form1 Frm1 = Form1.CreateForm1 ();                       Frm1. Show ();             }               .....      } So the question arose: I clicked a window called Button1 on the Form2 form to eject the Form1 (function as above), the first time it could be ejected, and to ensure that the Form1 window would not pop up again when the button1 was clicked, but after closing the Form1 window instance, Clicking the Button1 button again makes an error, explaining that the disposed object named "Form1" cannot be accessed. What is the reason for this? After careful observation and inquiry to the master, finally made clear the truth of the problem. This is the difference between Dispose and null. Dispose and close are the same, which is said to be because some classes have open methods, so a close method is developed for correspondence. The Dispose () method actually destroys an instance of the object, but the object variable still points to this destroyed memory address! And as long as it's pointing, it's never equal to null!. and Jolaraev frm = new Form1 (); then frm = null; This means that the frm no longer points to the new object, the relationship between them is "cut off", and the frm becomes a non-pointing variable, but the new object also occupies a memory, it is not killed! I later discovered that the form fires the closing event after the close () method is executed, and the Dispose () method does not fire the event. In singleton mode, the closing event of the singleton form is added "frm=null;" so don't use dis.Pose () Closes the singleton form and closes it with the close () method. By extension, all classes that have the close () method are best closed with the close () method instead of the Dispose () method. So, in the above example, when the Frm1 is turned off, the address of the object that it was new comes out of dispose of, but the variable frm1 still points to the address that was dropped! So it's not equal to null!. So when you click Button1 again, it goes directly to the Else section, causing the error. How to solve it? In this case, the FRM1 is set to NULL in the closed event of Form1. Because the form is closed and dispose is executed, the other code in the window does not stop until the execution is complete, so you can set the FRM1 to null, no problem at all. There is another problem here. If an object (an instance of a custom class) is not dispose of, set it to null, what about this memory? The garbage collection mechanism will automatically pack it up. But the garbage collection mechanism doesn't guarantee when it will be recycled, so you don't know when it's going to be recycled, which can affect the efficiency of the system. The workaround is to make the class inherit the IDisposable interface and then implement his Dispose () method. The function writes gc.suppressfinalize (this) so that if the Dispose () method is called manually, the GC will not destroy the object again through the destructor. This is necessary especially when the object is a local variable. A better way to write Dispose () into a finally{} statement is to use the Using keyword to load the code into {}. For example: Using (Class1 cls1 = new Class ()) {.... The parameters in the}using must be the object that implements the Dispose method. When the program runs out of {}, the CLS1 is automatically destroyed (but cls1! =null, this has been repeated several times). When the real implementation is realized, there may be many problems such as multithreading.

Go to Dispose, Close, =null the difference between the three