Dmitry,

No, even though my base cObject is derived from an object that could be visible on a form, these objects never contain UI components. These bizobjects are never intended to be visible themselves.

By designtime containership I mean something like: I have a cParse object that is designed to read files to be imported into a system. Each cParse object contains a cParseFile object whose job it is to convert a textfile into a cursor. Some file imports we run require 6 cParseFile objects the cParse object controls the calling he methods of the aggregated cParseFile objects. The cParseFile object gets dropped into a cImport object which also contains instances of cImportTable objects.

These objects just rely on datasessions provided by the "host" that is running the object.

cObject has a couple of properties that that are used to hook these objects to a host GUI. Like nPercentComplete and cDisplasStatus. Each object that needs to display a message or % status sets it's own property. cObject contains assign methods that propogate these properties up to the parent and ultimately calls a Display...() method which provides some appropriate UI for the enduser to know how the process is running.

>I think I understand but I am not 100% sure what you mean by "design time containership of composite classes." Is it that you can drop other controls/classes into a Container? How is it important for using the class as a base for a Business Object? For my needs, the DataSession property is very important for BO since it allows to keep the data of the BO private. As I am designing a new program I have used Custom class but then realized that it does not keep the data private. So I started to look of what else I can use. Session has DataSession but you can work with it visually. I will probably still use Custom and then use a method of isolating it inside a small SessionBase.prg class, as described in another message.