Thanks everyone for all of your ideas. I decided to go with the class David recommended. It is working quite well and I don't have to define it in a prg so the vcx is visible in the project with the other classes and it is easy to work with.

Tracy



>Tracy,
>
>For these types of classes I derive them from a general purpose cObject class which is actually a container class. This allows me to easily put together composite classes at design time by just dropping classes into each other as needed.
>
>Most folks recommend lightweight classes derived from something like Line but you can't aggregate them very well because they don't allow containership ie have an AddObject() method.
>
>>I have a function that is called that does ONE of two possible things based on how it is called:
>>
>>1. Creates a table with required basic 'core' records.
>>2. Adds additional 'detail' records based on the values passed.
>>
>>I pass the below values to the function:
>>
>>

>>*:          Usage: =SysInfo(tcgroup, tcsubgroup, tcitem, tcsubitem, tcvalue, tlcreate)
>>*:     Parameters: tcgroup      c65   - group value i.e. Agency Name/Site Name
>>*:                 tcsubgroup   c65   - subgroup value i.e. Workstation Name
>>*:                 tcitem       c65   - item value i.e. User Settings
>>*:                 tcsubitem    c65   - subitem value i.e. Deleted
>>*:                 tcvalue      M     - detail value i.e. ON or OFF, etc.
>>*:                 tlcreate     L     - logical create groups/subgroups/etc or not
>>

>>
>>If tlcreate is passed, then the table is created with certain basic records which allow it to be viewable easily in a treeview. The record is populated based on the values passed in the other parameters.
>>
>>If tlcreate is not passed (or passed as false), then the values are being passed which then creates a detail record or overwrites one if the settings have changed for that subitem.
>>
>>The table stores system settings such as set deleted, set near, login id, workstation name, hard disk space, memory, etc and is broken down by agency name and workstation.
>>
>>It works fine as is, but:
>>
>>I want to change this program to a class. Which type of class is best to use for one that will never be visual except when creating the properties during development?
>>
>>My idea is to set the value of properties on the class with the values passed to the function now, and then call a method of the class to process those values.