When must I set a variable to “Nothing” in VB6?

Question

In one of my VB6 forms, I create several other Form objects and store them in member variables.

Private m_frm1 as MyForm
Private m_frm2 as MyForm

// Later...
Se         


        

Answer 1

I had a problem similar to this a while back. I seem to think it would also prevent the app from closing, but it may be applicable here.

I pulled up the old code and it looks something like:

Dim y As Long
For y = 0 To Forms.Count -1
    Unload Forms(x)
Next

It may be safer to Unload the m_frm1. and not just set it to nothing.

Answer 2

Objects in VB have reference counting. This means that an object keeps a count of how many other object variables hold a reference to it. When there are no references to the object, the object is garbage collected (eventually). This process is part of the COM specification.

Usually, when a locally instantiated object goes out of scope (i.e. exits the sub), its reference count goes down by one, in other words the variable referencing the object is destroyed. So in most instances you won't need to explicitly set an object equal to Nothing on exiting a Sub.

In all other instances you must explicitly set an object variable to Nothing, in order to decrease its reference count (by one). Setting an object variable to Nothing, will not necessarily destroy the object, you must set ALL references to Nothing. This problem can become particularly acute with recursive data structures.

Another gotcha, is when using the New keyword in an object variable declaration. An object is only created on first use, not at the point where the New keyword is used. Using the New keyword in the declaration will re-create the object on first use every time its reference count goes to zero. So setting an object to Nothing may destroy it, but the object will automatically be recreated if referenced again. Ideally you should not declare using the New keyword, but by using the New operator which doesn't have this resurrection behaviour.

Answer 3

@Matt Dillard - Did setting these to nothing fix your memory leak?

VB6 doesn't have a formal garbage collector, more along the lines of what @Konrad Rudolph said.

Actually calling unload on your forms seems to me to be the best way to ensure that the main form is cleaned up and that each subform cleans up their actions.

I tested this with a blank project and two blank forms.

Private Sub Form_Load()
  Dim frm As Form2
  Set frm = New Form2
  frm.Show
  Set frm = Nothing
End Sub

After running both forms are left visible. setting frm to nothing did well... nothing.

After settign frm to nothing, the only handle open to this form is via the reference.

Unload Forms(1)

Am I seeing the problem correctly?

• Josh

Answer 4

Actually, VB6 implements RAII just like C++ meaning that locally declared references automatically get set to Nothing at the end of a block. Similarly, it should automatically reset member class variables after executing Class_Terminate. However, there have been several reports that this is not done reliably. I don't remember any rigorous test but it has always been best practice to reset member variables manually.

Answer 5

Strictly speaking never, but it gives the garbage collector a strong hint to clean things up.

As a rule: do it every time you're done with an object that you've created.

Answer 6

Setting a VB6 reference to Nothing, decreases the refecences count that VB has for that object. If and only if the count is zero, then the object will be destroyed.

Don't think that just because you set to Nothing it will be "garbage collected" like in .NET

VB6 uses a reference counter.

You are encouraged to set to "Nothing" instanciated objects that make referece to C/C++ code and stuff like that. It's been a long time since I touched VB6, but I remember setting files and resources to nothing.

In either case it won't hurt (if it was Nothing already), but that doesn't mean that the object will be destroyed.

VB6 had a "With/End With" statement that worked "like" the Using() statement in C#.NET. And of course, the less global things you have, the better for you.

Remember that, in either case, sometimes creating a large object is more expensive than keeping a reference alive and reusing it.