Garbage collection / clearing objects 1

[1DMF]

Hi,

I have read that VBA doesn't have garbage collection?

I assume it must destroy objects with no references some how?

I was wondering, that if I declare a variable within an event handler of a form such as 'on open', which contains recordset variables and other class objects.

I'm assuming that as they are not in the scope to set them to nothing via the event 'on close'.

Can you confirm if all variables and objects created within a scope of 'form open' are destroyed / garbage collected when the form is closed?

Thanks,
1DMF.




"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"

MIME::Lite TLS Email Encryption - Perl v0.02 beta

 

[MajP]

Yes.

 

[MajP]

Let me say that differently. Yes as long as there are not other pointers to that object. You could instantiate an object in the form but it is assigned to a global variable. So the form closes the global variable still points to that object. You have no control over garbage collection. It happens when it happens, all you can do is decrement the pointers. Some objects in vba provide a close method which does work like a destructor. There are good reasons to close recordsets, some has to do with legacy bugs. But it will close and destroy on its own, but maybe later than you would want.

 

[1DMF]

Thanks MajP.

So is it better practice to create a wider scope for a form object and recordset so it can be manually closed / set to nothing on events such as 'on close'.

Or is it acceptable to let it be handled by access by the fact the form closes and so there are no longer any references to them?

"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"

MIME::Lite TLS Email Encryption - Perl v0.02 beta

 

[MajP]

Not sure if I understand the question, and my guess it is not anything you need to worry about. VB does a fine job at counting references and garbage collection. There is really nothing you can do except speed up the decrementing of the pointers.

Setting a variable to nothing only decrements the number of pointers. Com counts the pointers and once they are zero for an object, at some unknown time COM destroys the object. I hardly ever set anything to nothing. You see a lot of code like this.

public sub someprocedure

'set every object to nothing or the world ends and vb
'might not decrement the counter
end sub

So at the end of the code all object references are set to nothing decrementing the counter, but a billionth of a second later the procedure terminates and all pointers go out of scope and thus decrementing the pointers. Destruction of the actual objects happens when the garbage collecter decides. Any discussion about just making sure that happens, are silly. VB would have some serious problems if that did not always happen.

If you have some code that loops for a long time and holds on to a variable you may want to set it to nothing if the procedure is not terminating for a while, or if it is a variable held outside the method and you are no longer using it.

In vb.net you can actually run the garbage collector, but it is not advised. The garbage collector is optimized and you will hurt performance or get it out of synch. Languages like C++ are unmanaged and you have to worry about things like this.

Objects such as recordsets/connections that provide a close method should normally be closed. My simple understanding is that although the garbage collector is aware of these type of objects, it does not fully manage them. So although it knows there are no pointers it does not know how urgent it is the destroy the object. It will eventually get around to it, but maybe not timely enough.

 

[MajP]

http://msdn.microsoft.com/en-us/magazine/cc188935.aspx

Here is a pretty good article on memory management. I think my terminology is wrong. Garbage collection and Reference Counting are two different types of memory management. So yes vba(COM) does not have Garbage Collection, but uses reference counting to manage memory.

 

[MajP]

You may be interested in this:

http://www.keysound.com/html/ch_15_much_ado_about_nothing.htm

 

[1DMF]

sorry, I'm obviously not explaining myself very well.

Is it better to declare the vars in the scope of the form class and then set them to nothing in 'on close'

or is it fine to simply create them in the scope of the method (event handler) and let the form close and kill them itself.

Or are you saying it makes no difference and don't worry about it?

In my .NET course using MVC they call them fields and they declare them in the scope of the class for any objects such as the model.

Is this approach considered best practice in VBA?

Though the recordset I appreciate is not part of the model, perhaps I should be creating a controller class and then all the event handlers do is call methods in the controller?




"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"

MIME::Lite TLS Email Encryption - Perl v0.02 beta

 

[1DMF]

NB. I can only find the subs dispose and finalize relating to .NET?

"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"

MIME::Lite TLS Email Encryption - Perl v0.02 beta

 

[MajP]

Is it better to declare the vars in the scope of the form class and then set them to nothing in 'on close'
or is it fine to simply create them in the scope of the method (event handler) and let the form close and kill them itself.
Or are you saying it makes no difference and don't worry about it?

Do to persistence (life of a variable) you should always strive to use what the author of the second link calls "Automatic" variables.

Automatic variables: These are always local to a function, and are created and destroyed anew each time the function runs.
Traditional programming wisdom says it's usually preferable to use automatic variables in preference to other kinds, but it's only when we start to store object references in variables that the effects of unexpected persistence become impossible to ignore.

However the author also discusses instance variables

Instance variables: These are variables which are associated with classes, and which persist for the lifetime of the class instance. They are defined at the module level in a Class or Form file, and can be Public or Private.

Variables declared in a form level is an instance variable since a form class is just a special class

In this case what we need to consider is the lifetime of the class instance, because all module-level variables die with the instance. Again this is well-defined behaviour, so setting pointer variables to Nothing willy-nilly in the Terminate event serves no useful purpose.

So it is better practice to use procedure level variables. But as the author points out there is really no need to even do the following

Is it better to declare the vars in the scope of the form class and then set them to nothing in 'on close'

There's also no satisfactory way to do it in a class module, because code in the Terminate event doesn't run until the object's reference count reaches zero! In form modules we can use the Form_Unload event, but this is bad practice because Form_Unload really has nothing to do with the form's lifetime.
[/quote]

 

[1DMF]

Right so the short answer is, "it fine to simply create them in the scope of the method (event handler) and let the form close and kill them itself" -> "automatic variables"

Well that's good to know, but that then means it can't be that causing me my problems :-(

I guess elimination is still progress!

Thanks Majp!

"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"

MIME::Lite TLS Email Encryption - Perl v0.02 beta