Hi Barbara

Thanks for responding.

>I'm unclear on your reasoning for wanting to put these containers into a form class. Why not leave them as containers which can then be dropped onto a page of a pageframe or onto a form for 'single' instanciation.<

The controls in the container represent individual, defined classes. If you take the pageframe out of the equation, I might create and develop a "Client" class, a "Vehicle" class and so on in a .VXC. The properties and methods of the class are contained in the .VCX. Therefore I could subclass the .VCX for more specific behaviour later.

However, the application demands that these classes basically reside on pages in a pageframe. As the framework utilises a reference to a container in which to instantiate the contents of each page in a page frame, I appear to be reduced to developing application "classes" with their associated behaviour in containers and not .VCX's. Do VFP developers routinely develop their application classes in non-form containers ie., a "pucker" container? Would I be right in assuming that by developing application classes in a container, they can be dropped on to a form or a page in a pageframe? If properties and methods of the class are created in the container, if I later subclass the container, I will inherit the container behaviour but the controls will not be subclassed? Is this what happens?

My preconception is that re-usable application based classes are developed in .VCX's whereas now it appears that they should be developed in containers that can be in turn dropped on modal/modeless forms or pages in page frames.

Help !!!

Yes, I am a 2.6'er and relatively new to VFP <g>.