I guess there are a million ways to look at it, and just as many ways to do it. I usually try to subclass all the controls that are used on my forms, and in some cases create containers for instances where a group of controls is going to appear on more than one form. I've had a lot of success using this programming style. I still get the dataenviornment, and I think it's eaiser to debug and make enhancements to .scx forms. Plus, you can say USE formname.scx and change all the properties of the controls. If you think about it for a moment, this makes development time really fast. I can put all the necessary tables/views in the dataenvironment, then drag & drop the fields (with lables) that I want onto the form. Then I can say USE Formname.Scx and edit the table so that the default controls I just draged and droped onto the form are the subclassed ones I created, even the form itself is one I've created and subclassed. (It has a few more propertys and methods). As matter of fact, I even wrote an .scx form that allows me to make these changes quickly. I don't know about the run-time performance issues involved in using this logic, but so far my apps seem to run ok. I like using this technique not only becuase it speeds up development time, but when the next guy comes in behind me to try to make changes to the code it's not that difficult to follow.

Just my two cents worth.

>>Hello,
>>
>>We are using Visual Foxpro 5.0 and we are making a framework.
>>We want to use forms like 'login' and 'security'.
>>
>>Now we would like to know if it is better to use classes for these forms and use
>>the 'createobject' command or that we only use forms and use the
>>'do form' command.
>>
>>Greetings,
>>
>>Afier Appelman
>>Using the account of Koos Veel
>

---

>
>DO Form vs CreatObject is already a large discussion.
>
>I would ask ppl to start with DO FORM version as there are some benefits:
>
>- Easy setting on Data Env.
>- Easy Trace in Design Mode
>
>But I will suggest ppl to 'promote' their successful form into Class.
>it can reduce some similar tasks...
>
>E.g. a Form carry simple 1-M relation, if you put the general thing into form class, it will save time to handling on similar cases. You only need to assign the corresponding value on new property.
>
>MasterTable(MasterKey, ...) & DetailTable(MasterKey, DetailKey2,..)
>
>i.e. Form1_M has following new properties:
> cMasterTable > carry Master Table Name
> cDetailTable > carry Detail Table Name
> cMasterKey > carry Master Table Key
> cDetailKey2 > carry Detail Remain Key2
>
>So, if there is a simple grid to show detail table information....
>Most of the code can reduce as they just call the Class coding....
>
>Anyway, it is surely that Do Form is a fast development but Createobject need to study well and divide the cases into general part and special part....
>that is the decision on C++ object.
>
>

---

>another way is use DO FORM version with using John suggestion.
>Create a Form Class, then create a new form with simple add the new form class and delete the "form1" default form and then delete the formset "formset1"
>Then, all the Form class thing can work as if DO FORM.
>That can reduce most part of duplicate coding and you can more easy to maintain!