>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?

Most of the time these objects have no visual representation whatsoever, yet they may have member objects, so my choice is Custom. Not necessarily the best choice for every situation, but using Custom as the base class for my prg-based classes has saved me a lot of grief (IOW, I tried others and always ran into something).

Container may be a good choice, too, if you're sure it will never become visible :). Just as long as you're using your prg files to Define Class / EndDefine, you're doing it OOP. It's just a tad easier on your exe if you don't pack all the extra fields a vcx has into it.

BTW, I've found it easier at times to define my grids, columns and headers in .prg. The only visual stuff you need is the outside sizing, for which I have a placeholder object (see message #1282689 for details), and the rest is for the user to adjust to their liking and for the app to save in .ini files for the next time.