Closing a form with the X Button does not destroy Private Variables

I've just stumbled across this little beauty. Is it a bug with VB6 or do other version of VB do this?

It will take about 5 mins for you to reproduce this, but believe you me, it has far reaching consequences...

Scenario 1:

Two Forms (Form1, Form2)

Form1 - Two command buttons (Command1, Command2)

Sub Comand1_Click

    Form2.Show 'show form2

End Sub

Sub Command2_Click

    Unload Form2

    Set Form2=Nothing 'the "correct" method of closing a form

End Sub

Form2 - One Label (Label1), One Command Button (Command1) and a Privately declared Module level variable (strTest)

Private strTest as String

Sub Command1_Click

    strTest = strTest & "X"

    Label1=strTest

End Sub

Problem:

1. Run the app.

2. Click Command1 on Form1 (Displays Form2)

3. Click the Command1 on Form2 (Appends 'X' to the end of private string and display it in Label1)

4. Close form2 with the 'X' button on Form2 (Closes form2)

5. Click Command1 on Form1 (Displays Form2 again)

6. Click Command1 on Form2 (Appends 'X' to the end of private string and displays in Label1)

What's wrong with this picture?

Even though the form instance was destroyed, (it no longer exists in the Forms collection) my Private variable wasn't! The only place I can reference the variable (Form2) has been destroyed. So the variable just sits there in limbo somewhere until I launch Form2 again.

What's the point of the Close button if it doesn't destroy the form instance and all its local variables? - It's really just a Form2.Hide that kills of the Form instance and its controls, but not its private variables!

OK, lets try the "preferred" method of closing the form.

Go trough steps 1 to 6 again, but for step 4 close Form2 using Command2 on Form1 (Unload Form2, Set Form2=Nothing)

This works fine. The form AND the private variable are destroyed.

Can anyone tell me if this is a "design feature" and if so why?

Doug.

Because theyre visible to the user, forms and controls have a different life
cycle than other objects. For example, a form will not close just because youve
released all your references to it. Visual Basic maintains a global collection
of all forms in your project, and only removes a form from that collection when
you unload the form.
In similar fashion, Visual Basic maintains a collection of controls on each
form. You can load and unload controls from control arrays, but simply releasing
all references to a control is not sufficient to destroy it.
For More Information   The Forms and Controls collections are discussed in
Collections in Visual Basic earlier in this chapter.

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), youve used the hidden global variable. To free the forms
memory, you must set this variable to Nothing. For example:
Set Form1 = Nothing

(Put in the Form_Unload event to insure it gets called no matter how the form is
closed)

[VB5]
Robb
Remove autospam deterrent from address before emailing

On Wed, 14 Oct 1998 09:48:41 +0100, "Richard Allsebrook"

Use "Set Form1 = Nothing" to clear form variables.

Bruno Paris
Ameba
to reply via email, remove nospam_

I disagree. Someone should be able to create new instances of your form class with the new operator without code in te form changing global variables. It's the code outside of the form that creates the form object that should set it to nothing.

If you do:

Dim frmForm as Form1

Set frmForm = New Form1
frmForm.show vbModal
Set frmForm = Nothing

then you don't want the unload event to set the global Form1 variable to nothing. (If it already was nothing then this will create a new Form1 object and then immidetaly destroy it, I think). This means that if you use the global variable then you also have to clear it:

Form1.Show vbModal
Set Form1 = Nothing

I was atempted at first to test in Form_Unload if Form1 is Me, but this also instantieates Form1. Using Debug.Assert to verify that Form1 is Nothing also instantiates it.

I hope future versions of VB will have a design time property that disable the automatic global form variables and that new forms will have them disabled by default!

    Christer Romson

Kevin Sehl:

I think that this is not a problem because:  (1) Set Form1 = Nothing doesn't create Form1 when it doesn't already exist; and (2) Set form1 = Nothing in the unload event of frmForm won't kill any other existing instance of Form1 because there will still be a reference to it (in the Forms collection).

Certainly, if you create a new frmForm of type Form1 in your procedure, you can set the variable (frmForm) to nothing, but that will happen when your procedure ends anyway, due to the variable's local scope.

This whole subject is so darn complicated, it always gives me a headache!

    I disagree. Someone should be able to create new instances of your form class with the new operator without code in te form changing global variables. It's the code outside of the form that creates the form object that should set it to nothing.

    If you do:

    Dim frmForm as Form1

    Set frmForm = New Form1
    frmForm.show vbModal
    Set frmForm = Nothing

    then you don't want the unload event to set the global Form1 variable to nothing. (If it already was nothing then this will create a new Form1 object and then immidetaly destroy it, I think). This means that if you use the global variable then you also have to clear it:

    Form1.Show vbModal
    Set Form1 = Nothing

    I was atempted at first to test in Form_Unload if Form1 is Me, but this also instantieates Form1. Using Debug.Assert to verify that Form1 is Nothing also instantiates it.

    I hope future versions of VB will have a design time property that disable the automatic global form variables and that new forms will have them disabled by default!

        Christer Romson

    Kevin Sehl:
    > Try putting the Set FormX=Nothing in the Form_Unload event.
    > THAT is the preferred method.  The Unload gets called
    > regardless of how you try to destroy the form.

Paul Hickey:

Yes, you're right and I was wrong. I confused it with:

  if not Form1 is Nothing then Set Form1 = Nothing.

You may have code that reference these instances through the Form1 variable.
You might break that code if you set Form1 to Nothing in frmForm's unload
event.

I think the morale to the story is that any given form class should either
be refernced through explicitly declared variables always or through the
automagic global variable. Code in the form class should use Me to refer to
itself as that will work with both ways of referencing it.

Christer Romson:

Kevin Sehl: