Michiel,

I'm afraid I'm closer to your opponents on this one. Composing the form class with a DE (which stands for Data Environment) originally had one major reason: to avoid the necessecity to program in the form designer which is a pain. More I can do in straight prgs, albeit under an object definition, the better I feel. Assigning the reference of the DE to a property works for me.

With time I have seen myself add more and more functionality to the form, but in a base class form, so that I do not have to recode this each time. And leave current programming aspects for the DE. Without knowing it I must have implemented a kind of a fractal tier architecture :).

Code that can be shared by multiple DE's are wrapped in what I call Business Objects.

Marc







>Hi Jim!
>
>>Changing data sessions can be a dangerous thing to do if you do not restore the data session properly. A better design might be to build your Methods class to be a light weight object and then in your form class put one them in the form. Then make your calls THISFORM.oMethods.SetSets().
>
>Perfect! As always a great answer! It's working like a charm now. We just added the Methods class to our form and we call the methods. This way they are in the correct datasession without any hassles.
>
>However: we are in a discussion here. One party wants to switch to a procedure file altogether. So dump the oMethod class and use one big procedure file with all the procedures which are in the oMethod class.
>
>And another party (me :-)) wants to keep the current way of working. So use the oMethod class as a subclass of the Formclass.
>
>We would like your opinion about this matter. What would be better? We know both ways work perfect. But what is good programming? Or is it just a matter of taste?
>
>Thanks for your time!