>
>Unless the container is defined in a .prg, that is.
>
>I've worked with an in-house framework where all the code for the form was in its DE-like object, which in turn instantiated any number of bizobjects it needed, all of which were defined in prg files. This also made a few things simpler, as the code required fewer parameters (having one oSQL object for all things SQL logically led to the handle being its property etc) and the design was proper 3-tier. And there was almost no code in the forms themselves, maybe just in some grids an occasional "return .f." in a column's .when(). All the form code was either class level (in a vcx) or local to the form - ergo, handled by the .de object and its bizobjects.

Dragan,
thanks for the idea. I tried calling a prg from the form init. The prg creates a new container in the form. To test it I put one procedure in the container to create a cursor and it all works. This solves a number of problems for me and I think it might even be OOP compliant though I'm sure some will disagree. It works with the form set to both modal and modeless and with the private data session each form will be entirely self contained.

Questions: Does this sound like a good way to go to you? Is the init the best place to create the container from. Is a container the best object to use?

Thanks again.