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.
