DOCUMENT:Q138068 11-JAN-2001 [vbwin] TITLE :Explanation of the States in Which Forms Can Exist PRODUCT :Microsoft Visual Basic for Windows PROD/VER: OPER/SYS: KEYWORDS: ====================================================================== ------------------------------------------------------------------------------- The information in this article applies to: - Microsoft Visual Basic Standard Edition, 32-bit, for Windows, version 4.0 - Microsoft Visual Basic Professional Edition, 16-bit, for Windows, version 4.0 - Microsoft Visual Basic Professional Edition, 32-bit, for Windows, version 4.0 - Microsoft Visual Basic Enterprise Edition, 16-bit, for Windows, version 4.0 - Microsoft Visual Basic Enterprise Edition, 32-bit, for Windows, version 4.0 ------------------------------------------------------------------------------- SUMMARY ======= A Visual Basic 4.0 form object can exist in five possible states: 1. Unloaded 2. Created but not loaded 3. Invisible but loaded (hidden) 4. Visible 5. Unloaded but control is loaded Four of these states (1, 3, 4, and 5) existed in Visual Basic version 3.0 also. The new state in Visual Basic version 4.0 is the "Created but not loaded" state. MORE INFORMATION ================ Unloaded -------- In this state the form hasn't been loaded yet. It does not exist. Created But Not Loaded ---------------------- This is new in Visual Basic version 4.0. To explain this state, it is beneficial to think of the form as having two parts: a code part and a visual part. Think of the code part as including all the methods and properties that may be defined in the form module (this part is new in Visual Basic version 4.0). Think of the visual part as all the rest such as the form properties in the Property window (this part is same for Visual Basic version 3.0 and Visual Basic version 4.0). In Visual Basic version 4.0, forms are objects. When you use an auto- instantiating variable to refer to a user-defined property or method (that is, any member in the code part), the Form object is created but not loaded (that is, only the code part of it is loaded). This means that the Initialize and Terminate Events for the form are invoked. Say there is a Sub procedure called MyMethod defined in the form module. Then the following code illustrates the semi-loaded state of a form: Dim x As New Form1 x.MyMethod Invisible But Loaded (Hidden) ----------------------------- In this state, the form is loaded and then its Visible property is set to False. The line of demarcation for this state is the execution of the Form_Load() event. Visible ------- The normal state of the form being loaded and then shown. Unloaded But Control is Loaded ------------------------------ You get into this state by loading the form, setting a reference to a control on the form, and then unloading the form. The reference to the control still stays alive. This can be a very dangerous state to leave your form in because on unloading the form, the code in the Form_Unload() event is executed, yet the form and its controls are not destroyed. The Form object and all the objects it contains still exist. What's more, they will be loaded back into memory, with all their current property values and states, the moment your code uses that control reference, even if its just to query a property of the "loaded" control. The dangerous part is that the Form_Load() event will not be executed. It is as if you just made the form visible again. Additional query words: 4.00 vb4win vb4all ====================================================================== Keywords : Technology : kbVBSearch kbAudDeveloper kbVB400Search kbVB400 kbVB16bitSearch ============================================================================= THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY. Copyright Microsoft Corporation 2001.