>>>>>I have made an .SCX based on my class, run with a DO FORM. I could make a subclass for this specific use, with my table build in, but it seems like I shouldn't have to do that.
>>>>
>>>>Bret,
>>>>
>>>>You can pass parameters to the fomr's Init to tell what tables to open. If you open the table in the Init then you'll need to make all of the controlsources blank to prevent errors as the controls instantiate. They get created before the Form's Init runs so in the Init after you open your table you will neeed to set the controlsources for the objects in the form.
>>>That should work fine for my task. I'm still interested in the general problem of how you use data environments when you instantiate a form from a class not intended for any specific table. I would also like to know if a form instantiated from a class has to be modal in order to stay on the screen. That doesn't sound right.
>>
>>
>>Of all the things I like and dislike about the CodeBook Framework, one of the really good ideas it has is the subclassing of the dataenvironment and the loading of tables and or views through a 'data loader' object. This is necessary for forms that are saved as classes because such forms have no data environment. The base class of these forms includes the data loader object which has a parameter which is passed the name of the class to load which in turn is a list of all the cursors to load. All views are defined as lv_ or rv_ and the loader determines whether the system uses local data (lv_) or remote data(rv_) so you can switch between data sources without changing code!
>>
>>The advantage to this method is that since the data loader is part of the base form class, this object will be instantiated first before any objects that reside on the form. This means all the views, tables, etc are opened before the first control is created and it also means that you CAN set the controlsource of your controls, grids etc in the form designer. The downside is that you cannot use the controlsource dropdown list to pick your fields (you must key them in) because the source for the list is the dataenvironment and there isn't one!
>>
>>Forms instantiated from a class do not have to be modal. However, these forms do not do an implicit thisform.show() that occurs when you execute DO FORM so after you create your form with CreateObject you must show it:
>>
>>loform = CreateObject('myformclass')
>>loform.show()
>>
>>Bob
>
>I guess that until I get my hands on a sophisticated framework, I have to do without data environments in this case.
>
>I did loform.show(). But it doesn't stay on the screen. And, as I said in the part of this thread that got snipped, my class has no CLEAR EVENTS. It seems to be unloading without provocation.

If your form flashes like that there is probably a problem in one of the methods that is causing it to unload. Use the debugger to trace through the init code line by line. One of the problems I have found is typing in the wrong field name for controlsources (because I have no drop down list to choose from) In 3.0 this sometimes caused a GPF but in a lot of cases the form won't load.

Here is a simple method to open the tables.
Create a custom class with a method like opentables and one for closetables. (No default code in these methods).
Add this class to your baseform or create a new class based on your baseform. When you use this new class as your baseform it will have this custom object available. For new forms, go into the the opentables code and open all your tables. Put code to close them in the closetables. Now you can reference fields for any of the tables you have opened in any control on your form. Why? because the custom class that is part of your base form class will be instantiated first, and will open all the tables, making their field names available as control sources for any controls added to this base class. As Jim Booth pointed out, opening tables in the init of the form is too late to use the field names as controlsources on the form.

Bob