do local variables always release automatically? even the object referencies too?

[ultra2]

private sub routine1 ()
dim i as integer
dim obj as imagelist

set obj = new imagelist
...
...

end sub

will the "i" release after routine1 runs?
will the "obj" release after routine1 runs?
if not how to release them?

[Joacim Andersson]

Both variables (including the object reference) will fall out of scoop when the Sub ends so the answer is Yes they are destroyed and the memory is released.

[Pradeep1210]

One more question..
When do we need to do this with local objects?
Set obj = Nothing

Or is this just a waste of time?

[Jacob Roman]

When you are done with it, like when you exit the program for example. This is to help eliminate it from memory.

[Joacim Andersson]

You should set an object to Nothing when you don't want to use it anymore. But for a local object it isn't necassary to do so since they will fall out of scope anyway, however there is never a bad habit to set objects you don't want to use anymore to Nothing. This could of course also be long before a procedure is done.

[RobDog888]

Not exactly true guys. When you automate Office apps the object variables do fall out of scope but under certain
circumstances they hold the reference to the object and you will end up still having an instance of Excel, for ex, still open
if you look in your taskmanager.

[Joacim Andersson]

Well Rob, the object reference in this case is actually released. That however doesn't mean you have exited the out of process application you automate. You should close that first, but that is not done by setting the object reference to nothing since it's done via a method call.

[RobDog888]

Just pointing out that its always a good idea to clean up your object variables. Writting a few short lines of code to clean
up is not very hard or time consuming and is good insurance in case your app is resource sensitive or something.

[Pradeep1210]

Just pointing out that its always a good idea to clean up your object variables. Writting a few short lines of code to clean
up is not very hard or time consuming and is good insurance in case your app is resource sensitive or something.

But is this fruitful at all to do for local objects?

Does it affect the speed of our program if there are too many such objects?
Which one would be faster:
Expictly destroyed using set=nothing
or automatically destroyed by moving out of scope?

[penagate]

Neither is faster it is just good practice to explicitly destroy your objects. It also makes the code clearer and easier to maintain in the future. What is actually slower is using loose binding (Dim xxx As New yyy).

[Joacim Andersson]

I mentioned that it's always a good idea to get into the habit of setting the objects to Nothing when you don't need them anymore. However I can for example get a reference to an instance of Word by using the GetObject function, I can then set this object reference to Nothing but that will not close the running session of Word. I need to call the Quit method to do so. This has nothing to do with the object reference and if the memory it takes up is cleaned up when a procedure ends, so let's not confuse the different aspects.

[RobDog888]

I dont think there would be any measureable difference but just makes good programming practice to clean up after yourself.

What is actually slower is using loose binding (Dim xxx As New yyy).

Ok, now you opened a can of worms.

I cant stand using that syntax and I do know its slower when your concerned with performance since it has to go back to the definition
each and every line where the object var is used to check if its instanciated or not. Arrg.

[penagate]

I mentioned that it's always a good idea to get into the habit of setting the objects to Nothing when you don't need them anymore. However I can for example get a reference to an instance of Word by using the GetObject function, I can then set this object reference to Nothing but that will not close the running session of Word. I need to call the Quit method to do so. This has nothing to do with the object reference and if the memory it takes up is cleaned up when a procedure ends, so let's not confuse the different aspects.

That would be the difference between instantiation and referencing Which is why you use two lines to create an object, Dim to allocate a reference and then Set to instantiate it.

[penagate]

I cant stand using that syntax and I do know its slower when your concerned with performance since it has to go back to the definition each and every line where the object var is used to check if its instanciated or not. Arrg.

Isn't that the syntax you have to use in .NET though?

[RobDog888]

I mentioned that it's always a good idea to get into the habit of setting the objects to Nothing when you don't need them anymore. However I can for example get a reference to an instance of Word by using the GetObject function, I can then set this object reference to Nothing but that will not close the running session of Word. I need to call the Quit method to do so. This has nothing to do with the object reference and if the memory it takes up is cleaned up when a procedure ends, so let's not confuse the different aspects.

In that scenerio, yes, but when you create the object and it goes out of scope you get all kinds of issues like the infamous 429 Server Object error.

[RobDog888]

Isn't that the syntax you have to use in .NET though?

Yes but .NET is all about OOP and you can do a ...

Dim oApp as word.application
oapp = new word.application

[Joacim Andersson]

That would be the difference between instantiation and referencing Which is why you use two lines to create an object, Dim to allocate a reference and then Set to instantiate it.

There is actually no difference between an object reference and an object instance, same thing different names (not 100% true but almost). But GetObject doesn't create a new instance of Word (in this case), but you still get the reference or currently running instance reference to it.

The difference between using the one liner and two lines to set a reference:

Dim obj As New SomeObject
'compared to:
Dim obj As SomeObject
Set obj = New SomeObject

is that the first creates a loosly bound object while the second use strong binding.

[penagate]

There is actually no difference between an object reference and an object instance, same thing different names (not 100% true but almost).

Depends what point of view you are looking at it from. But referencing and instantiation are strictly not the same thing. As you say GetObject returns a reference without creating any instances. If on the other hand you use CreateObject then you are both instantiating and referencing (as it also returns a reference).

[Joacim Andersson]

That's true. However I think you're missing my point. Regardless if I use GetObject, CreateObject, or setting a reference to the library and then use the New keyword to get a reference to, for example, a Word.Application object I will not close the application just by setting the object reference to Nothing.

[penagate]

Indeed I got that part , as you say you are only setting the reference to Nothing, not the instance itself. I'm not sure of the correct terminology but what actaully destroys the object is to do with who controls the object or something like that.

[Pradeep1210]

Do form level objects also get destroyed automatically when the form is unloaded, if I don't set set them to nothing?


Pradeep

[Joacim Andersson]

Do form level objects also get destroyed automatically when the form is unloaded, if I don't set set them to nothing?

If you mean controls then yes. A Form can't be destroyed until all objects are destroyed first.

[Pradeep1210]

If you mean controls then yes. A Form can't be destroyed until all objects are destroyed first.

I meant the objects I have declared at form level. e.g. recordsets etc.

I have experienced problems with recordsets, if I don't destroy them explicitly in form_unload. When I want to open this form again and open the recordset, I get a message that recordset is already open..

[Joacim Andersson]

That's probably because you haven't closed the recordset. Not that you haven't set it to Nothing. When a Form is destroyed all visual interface is destroyed with it, however since VB uses loose binding with Form objects (unless you declare the Form object yourself and create it using hard binding) the code itself will not be unloaded.

[Pradeep1210]

That's probably because you haven't closed the recordset. Not that you haven't set it to Nothing. When a Form is destroyed all visual interface is destroyed with it, however since VB uses loose binding with Form objects (unless you declare the Form object yourself and create it using hard binding) the code itself will not be unloaded.

Then this code should not work because I didn't close it here either??

Dim rs As ADODB.Recordset
Set rs = New ADODB.Recordset
rs.Open ...
 
Set rs = Nothing    'I didn't close the recordset
Set rs = New ADODB.Recordset
rs.Open ...

[RobDog888]

Destroying your rs object before closing it can cause corruption in an Access DB. Always close your rs before destroying it.

[szlamany]

I meant the objects I have declared at form level. e.g. recordsets etc.

I have experienced problems with recordsets, if I don't destroy them explicitly in form_unload. When I want to open this form again and open the recordset, I get a message that recordset is already open..

I was going to comment on all this in regard to RECORDSETS - but didn't until I just read this.

The whole point of cleaning up - closing and releasing objects - is just a good programming habit to get into.

Of course you want to close a RECORDSET as soon as possible. Of course you want to follow that immediately with setting it to nothing.

That object connects to a database with the potential to hold locks and memory on another server - against other users!

So that habit should extend to all objects.

As they have debated in circles about WORD automation already in this thread.

[Joacim Andersson]

Then this code should not work because I didn't close it here either??

What do you mean? Of course it works since you're pointing your recordset variable to a new reference. But before you do so you should always close the first recordset. I could for example use this code:

Dim cmd As CommandButton
Set cmd = Me.Controls.Add("VB.CommandButton", "MyBtn")
cmd.Visible = True
Set cmd = Command1
cmd.Caption = "Hello"

This will create a new command button on the form and let cmd reference it. I then switch so cmd points to an existing object, but that doesn't mean the earlier created commandbutton is destroyed.

[Pradeep1210]

What do you mean? Of course it works since you're pointing your recordset variable to a new reference. But before you do so you should always close the first recordset. I could for example use this code:

Dim cmd As CommandButton
Set cmd = Me.Controls.Add("VB.CommandButton", "MyBtn")
cmd.Visible = True
Set cmd = Command1
cmd.Caption = "Hello"

This will create a new command button on the form and let cmd reference it. I then switch so cmd points to an existing object, but that doesn't mean the earlier created commandbutton is destroyed.

Oh got it now..
It means that though I have lost the reference to my first recordset, it still exists. And now my object variables has started pointing to something else.
So that first recordset, though it exists, is useless for me as I can't regain control over it..

Pradeep

[szlamany]

It means that though I have lost the reference to my first recordset, it still exists. And now my object variables has started pointing to something else.
So that first recordset, though it exists, is useless for me as I can't regain control over it..

The term useless doesn't begin to talk about the evils of this situation.

As RD mentioned - with ACCESS, that's going to lead to possible corrupt DB issues.

In MS SQL Server you have the potential of MB-size chunks of memory on the server held up, and lock manager services held up, maintaining a dead recordset.

Do that in lots of your programs with lots of users and the application and database will not function at all.

[Pradeep1210]

From all this talk can we conclude that Set obj = Nothing doesnot eleminate objects from memory?
We must do rs.Close, wdApp.Quit etc. to eleminate them from memory.

Pradeep

[Joacim Andersson]

Oh got it now..
It means that though I have lost the reference to my first recordset, it still exists. And now my object variables has started pointing to something else.
So that first recordset, though it exists, is useless for me as I can't regain control over it..

Well, actually no. My example isn't really the same thing, I just wanted to make a point.

Since there is so much confusion about this let's try to explain this from the beginning. First of all we must understand the difference between an object and an object reference. You can create COM objects in VB but you can only refer to these objects using an object reference. Take this simple code:

Dim obj As MyLib.MyClass
Set obj = New MyLib.MyClass

The first line declares a variable as MyLib.MyClass which means that this variable can point to an object (or have a reference to an object) of the type MyLib.MyClass. The second line creates a new instance of this object and we then have a reference to this object in the obj variable.

COM objects has an internal reference counter so this code:

Dim obj1 As MyLib.MyClass, obj2 As MyLib.MyClass
Set obj1 = New MyLib.MyClass
Set obj2 = obj1

will only create one instance of the object but we have two different references to it, but they both point to the same object (or to the same memory location). The COM object (MyLib.MyClass) reference counter is now up to 2, so even if I then set obj1 to nothing the object itself is not destroyed since there is still one reference to it (obj2).

So setting an object reference to Nothing does not destroy an object, it decrese the reference counter in the object itself. The object will be destroyed when the reference counter is down to zero.

The reference counter in the code above would also change if I would let obj2 point to another object instance of MyLib.MyClass. So setting an object reference to Nothing just to set it to point to another object on the next line is a bit unnecassary since the reference counter will decrease as soon as the object reference isn't pointing to the object. An object reference is also destroyed when it falls out of scope, which again causes the reference counter to be decreased and the object will be destroyed if (and only if) the reference counter is down to 0.

Now there has also been a discussion about Recordset objects. In the code provided earlier the first recordset object will be destroyed since the reference counter will be decreased when you point the rs reference to a new recordset object. But as already mentioned destroying an open recordset without first closing it can cause errors in the database.

If we would stop talking about object references for a while and have a look at this code:

Public Sub OpenFile(ByVal sFileName As String)
    Dim hFile As Integer
    hFile = FreeFile
    Open sFileName For Output As #hFile
End Sub

This code has a local Integer variable called hFile. That variable is destroyed when the sub ends since it falls out of scope, but that doesn't mean that the file I opened using this variable is closed. Same thing with an opened recordset.

[dee-u]

Just wanna ask, if an object is declared in a Form (module-wide?), could it be destroyed in one of the procedures/functions within that Form?

Option Explicit
Private DeeU As adodb.Recordset
 
Private Sub Form_Load()
    Set DeeU = New adodb.Recordset
End Sub
 
Public Sub Destroy()
    Set DeeU = Nothing
End Sub

[Joacim Andersson]

Yes!

[brucevde]

I meant the objects I have declared at form level. e.g. recordsets etc.

I have experienced problems with recordsets, if I don't destroy them explicitly in form_unload. When I want to open this form again and open the recordset, I get a message that recordset is already open..

.

Variables with module scope are not released until the module is removed from memory. A Form instance is not completely removed from memory until it is explicitly set to nothing (and there are no other references) or its last reference goes out of scope. Calling Unload Form is not enough.