Barb & Trey:

I was aware that there were issues with composite classes. I have the Advisor issue and I will read the article. I note that the article relates to 5.0/3.0 & Fox 2.x. I don't suppose that 6.0 makes his comments moot?

The goal of our designers, is to create a container with the same label prompt that is used in 6 different, but similar apps (that we know of at this time). Changing the text in the class, gets to all of the instances. Another consideration is that we intend to have non-programmers build many of the UI forms, with a programmer coming in after to hook up control sources and write any additional validation code or what ever needs to be done.

I know that I could add properties to "generalize" the class, but it doesn't help the non-programmers much. We considered creating a control with an array of possible values for the label prompt and a property set to an index into the array of possible label values. IMO, this added complexity without positively reducing testing or maintenance.

I've already created a cboYesNo class that can map to a Y or N in the table and with setting a startpos property and a "fieldName" property, I use access/assign to map to a single character in a field that may be up to 50 characters. This system started in dBASE II and many of the tables were built 15 years ago, when the number of tables open at the same time was 2.

Steven Black mentioned at FoxTeach in Toronto (1999), that he didn't feel there was any serious impact with sub-classing to 6 levels and maybe little impact with even more levels.

Thanks for your input!