>When would the form object do its thing? In its Init? If so, is there an issue in that the DS has already been created? The only problem I could see is that if you have already pulled data, the data might not be correct (like if ANSI=.F. for the DS, and the form object tries to set it to .T., then it might be too late).
>
>
>>Another way is to have two environment type objects. One object is global and has the settings for all the VFP set commands. The other would be scoped to your form and part of your form base class. When this object instantiated it would gather the private settings (the subset that is affected by a private data session) from the global class and reissue the set statements. The form object uses the global object to determine values, or it can have the global values overriden.


Yes, in the init of the object it would call a method that would issue all of the appropriate set commands. This is essentially the method used by the Codebook (although the original code did not use settings from a global object to set the session objects).

If you find a problem with this approach, in that you need settings before the object is created, what you may want is to have your data environment created after this object is. This is the way the codebook works. It does not use the data environment of the form but creates one (or more for that matter) from subclasses of the data environment. These are instantiated AFTER the session environment object is created. Therefore the settings are correct when the data environment is loaded. I guess this is another good reason to use subclasses of the data environment.

In my applications, I NEVER use the data environment of the form and always use one created from a coded subclass.

You may want to consider a codebook framework that 'does' all of this stuff for you.