Code clean up question

[vbajock]

A question for the MS gurus here, when a form or other object is passed as a formal parameter to a function, does one need to add the object to the clean up code or is the cleanup automatically handled when one exits the function? For example

Function SomeFunction(byref frm as Form)
dim rs as adodb.recordset

blah blah etc


Exit_SomeFunction:

rs.close
set rs=Nothing

-->>> set frm=nothing 'is this needed?


End Function

Thanks,

Kirk

 

[PHV]

I'd don't cleanup an object passed by reference !

Hope This Helps, PH.
FAQ219-2884
FAQ181-2886

 

[vbajock]

I didn't think you could pass a form any other way.

 

[HarleyQuinn]

Yeah, you can pass them ByVal just fine.

As PHV said, definitely not the best plan disposing of objects passed by reference.

HarleyQuinn
---------------------------------
The most overlooked advantage to owning a computer is that if they foul up there's no law against wacking them around a little. - Joe Martin

Get the most out of Tek-Tips, read FAQ222-2244 before posting.

 

[MajP]

Yes you can pass byref and byval, but in truth the object is always passed by reference, it is the reference to the object that is passed byref or byval. This is a good discussion from the web:

Passing Objects ByRef And ByVal

Objects are always passed by reference. The ByRef and ByVal modifers indicate how the reference is passed to the called procedure. When you pass an object type variable to a procedure, the reference or address to the object is passed -- you never really pass the object itself.

When you pass an object ByRef the reference is passed by reference and the called procedure can change the object to which that reference refers to. When an object is passed ByVal a copy of the reference (address) of the object is passed.

As is so often the case, an example will serve well to illustrate this

Sub CallingProcedure()
Dim Range1 As Range
Dim Range2 As Range
Set Range1 = Range("A1")
Set Range2 = Range("A2")
Range1.Value = 123
Range2.Value = 456
'''''''''''''''
' Debug Group 1
'''''''''''''''
Debug.Print "BEFORE CALL::Range1: " & Range1.Address(False, False) & " = " & Range1.Value
Debug.Print "BEFORE CALL::Range2: " & Range2.Address(False, False) & " = " & Range2.Value
CalledProcedure R1:=Range1, R2:=Range2
'''''''''''''''
' Debug Group 2
'''''''''''''''
Debug.Print "AFTER CALL::Range1: " & Range1.Address(False, False) & " = " & Range1.Value
Debug.Print "AFTER CALL::Range2: " & Range2.Address(False, False) & " = " & Range2.Value
End Sub

Sub CalledProcedure(ByRef R1 As Range, ByVal R2 As Range)
R1.Value = 321
R2.Value = 654

Set R1 = Range("A3")
Set R2 = Range("A4")
End Sub

In the CallingProcedure, the variable Range1 is set to Range("A1") and the variable Range2 is set to Range("A2"). Then CalledProcedure is called, passing ByRef R1 and ByVal R2. The CalledProcedure sets the values of these ranges to new values and then changes the ranges to which R1 and R2 refer. Since R1 was passed ByRef, the CalledProcedure can change the cell to which Range1 in CallingProcedure refers to. As is confirmed by the second group of Debug.Print statements, the variable Range1 now refers to (points to) Range("A3"), not Range("A1"). However, since R2 was passed ByVal, the CalledProcedure cannot change the range to which Range2 refers to in CallingProcedure.

 

[vbajock]

So it looks like the general consensus is that any object passed to a procedure should not be included in the clean up code....

 

[MajP]

I think what most people are saying if you pass an object by ref and set it to nothing it will set your original obj to nothing. You probably would not want to do that and there really is no need to because the reference goes out of lifetime anyways. Here is an example of how you would get in trouble.

Public Sub test()
Dim obj As Access.Form
Set obj = Forms("form1")
MsgBox obj.Name
cleanUp obj
MsgBox obj.Name
End Sub

Public Function cleanUp(ByRef frm As Access.Form)
Set frm = Nothing
End Function

If you do the above ByVal you will have no problem. If you do the above by val the second Msgbox will give you a "object not set error", and you could no longer use the obj variable in the original procedure.

It would be equivalent to setting your object to nothing in the original procedure right after your call to the cleanup code.

 

[PHV]

vbajock, I'd say that a cleanup code should deal with objects set at the same scope.

Hope This Helps, PH.
FAQ219-2884
FAQ181-2886

 

[vbajock]

That's how I am currently doing it, whatever I create within a procedure is cleaned up in that procedure. MajP's point that any action on an object passed in by reference will affect the object as it exists in the calling procedure as well makes it pretty clear that in my coding style, which is to pass all objects by reference, that the way I am currently doing it is the correct way.

The reason it came up is because I have written a calendar program where each day of the month is a seperate form sub formed onto a form representing the month, and I'm passing all these little forms around to be acted on, and I don't want to be building up garbage somewhere when this app is already putting big demands on client memory resources, but it's pretty clear now that I am not. Thanks to all for a good discussion on this.

 

[MajP]

Not that it matters but if you pass a form by ref you can set it to nothing with no issue. There will always be a pointer from the the Forms collection. You will often see this done with custom collections where you create an object, add it to the collection, and then set the object to nothing. The only way to get to the object is through the collection

Although this is a debateable subject, I rarely set anything to nothing. This is a very good article,

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