Quote:
Originally Posted by
Daniel Duta
Actually I am looking for a theoretical explanation.
Excerpted from the Life Cycle of Visual Basic Forms:
Returning to the Created, But Not Loaded State
When the form is unloaded, Visual Basic removes it from the Forms collection. Unless you've kept a variable around with a reference to the form in it, the form will be destroyed, and its memory and resources will be reclaimed by Visual Basic.
If you kept a reference to the form in a variable somewhere, such as the hidden global variable described in "Customizing Form Classes," then the form returns to the Created, But Not Loaded state. The form no longer has a window, and its controls no longer exist.
The object is still holding on to resources and memory. All of the data in the module-level variables in the form's code part are still there. (Static variables in event procedures, however, are gone.)
You can use that reference you've been keeping to call the methods and properties that you added to the form, but if you invoke the form's built-in members, or access its controls, the form will load again, and Form_Load will execute.
Memory and Resources Completely Reclaimed
The only way to release all memory and resources is to unload the form and then set all references to Nothing. The reference most commonly overlooked when doing this is the hidden global variable mentioned earlier. If at any time you have referred to the form by its class name (as shown in the Properties Window by the Name property), you've used the hidden global variable. To free the form's memory, you must set this variable to Nothing. For example:
Set Form1 = Nothing
Your form will receive its Terminate event just before it is destroyed.
Tip Many professional programmers avoid the use of the hidden global variable, preferring to declare their own form variables (for example, Dim dlgAbout As New frmAboutBox) to manage form lifetime.
Note Executing the End statement unloads all forms and sets all object variables in your program to Nothing. However, this is a very abrupt way to terminate your program. None of your forms will get their QueryUnload, Unload, or Terminate events, and objects you've created will not get their Terminate events.
Extracted from Customizing Form Classes:
Me and My Hidden Global Variable
You may be wondering how it is that you can refer to Form1 in code, as if it were an object variable. There's no magic involved. Visual Basic creates a hidden global object variable for every form class. It's as if Visual Basic had added the following declaration to your project:
Public Form1 As New Form1
When you select Form1 as your startup object, or type Form1.Show in code, you're referring to this hidden global object variable. Because it's declared As New, an instance of the Form1 class is created the first time you use this predeclared variable in code.
The reason this declaration is hidden is that Visual Basic changes it every time you change the Name property of a form. In this way, the hidden variable always has the same name as the form class.
Tip After you unload a form, you should always set any references to the form to Nothing in order to free the memory and resources the form was using. The reference most often overlooked is the hidden global form variable.
Quoted from Basic Forms of Madness:
Forms are essentially classes - 'essentially', because they're also a little bit more than classes. We can mostly use a form anywhere we can use a class (see Chapter 1 for some exceptions), but obviously a form can have visible attributes too. It doesn't have to be visible: for example, we might use a form in place of a regular class module because we need a class that uses a timer control. When working with forms we also need to appreciate that the visual part of a form can be in a 'loaded' or 'unloaded' state; as we'll see, most of the problems with forms revolve around these two states.
If, as is the case with classes, we were compelled to define instances of our forms before using them, one of the most confusing form issues would cease to be an issue. This would mean that we'd always need code like this to use any form in our program:
Dim oMyForm As New Form1
oMyForm.Show vbModal
Unfortunately, whether or not we define any instances of a form, Visual Basic creates one for us. We reference this object via an implicitly-defined global variable that has the same name as the class. That last sentence deserves to be printed in bold in Chapter 1 (or perhaps Chapter 6!) of every Visual Basic book and to be taught on the first morning of every Visual Basic training course, since it explains unambiguously why we can use the identifier 'Form1' to mean two entirely different things in two different contexts:
Form1.Show
Dim oNewForm As New Form1 |
' Form1 is an object name
' Form1 is a class name |
Sadly, VB books and programming courses almost inevitably teach programmers to use VB's implicitly-defined forms without explaining what's going on. Creating explicit instances of forms is usually taught as a minor 'advanced' topic, to be glossed over hurriedly when MDI applications are considered. The unfortunate consequence is that many intermediate and 'advanced' VB programmers just don't understand what they're doing. You can program without ever touching VB's implicitly-defined forms, and I suggest that you do (see Chapter 1 if you need to be persuaded).
