>
>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.
Dragan,
thanks for your input. I have created two prgs that create containers in the form. Prg 1 handles form procedures. Prg 2 does the SQL stuff returning data in cursors. So far it works great. It's really cool to be able to use Thisform in a prg.
One more question if I may. I am calling both of these in the Data Enviornment Load Tables event. If I don't I get errors because the control source for the text boxes, etc. do not exist. Calling the prgs from there has me a bit worried although it seems to work ok so far. Any thoughts?
Beer is proof that God loves man, and wants him to be happy. - Benjamin Franklin
John J. Henn