An Object variable is very cheap in terms of resources. It's just a pointer
to the address in memory where the actual object exists. The main thing to
be careful of is to ensure any object variable is released once the object
no longer exists (no need to do anything if the variable is about to loose
its scope).

In passing, though it's a matter of style "Types" are generally appropriate
for a number of closely associated variables, eg name, age, address. I get
the impression you are using a Type merely as a means of consolidating a
number of variable to avoid passing them all in one go.
Since 16-bit has all but disappeared best to change those As Integer to As
Long

Regards,
Peter T


"Neal Zimm" wrote in message
...
Hi All,

Am developing an App where user's Wbk references an AddIn.

Data in AddIn sheets control options available to users.

Some of this data becomes arrays in a User record and I use the
AddIn object a lot for lookups.

Record is updated in a bunch of different Sub's and Functions.

Public Type uOptRec 'there are more fields, about 20. a few to
illustrate

iMthDaysAy(12) as integer 'Qty of days in month

iMidMthDay(12) as integer 'day of midpoint in month

bExpenseAuth as boolean 'expense authorization yes/no

AAscAddIn as workbook 'where the data is stored
End Type

I'm not a super techie and don't know the "cost" of putting a
workbook object in a user record.

It seems easy to put the AddIn in the record versus:

Sub UpdateA(AAscAddIn as workbook, uOptRec as uOptRec, ..........

to minimize the arguments in the sub/function statement.
Bullen's book says "keep them to no more than 5, usually ... "

But, is it efficient ???
Does a workbook object in a record take up a lot of computer resources?
Is it anything like a "copy" of the .xla file IN the record ?

What are the Pro's and Con's ?.

Thanks, Neal Z


--
Neal Z